I am working on a computer vision problem of tracking points in 3D. My program determines the 3D position of tracked points in a scene, which I would like to display in an OpenGL window.

I have spent the past few hours looking for a way to accomplish this. Originally, I thought I might make a program using MEX and OpenGL that Matlab could call, but I cannot set up even a basic program to do that. I was attempting to follow this advice:
http://tech.groups.yahoo.com/group/psychtoolbox/message/11067
Is it possible to create an OpenGL MEX program? I don't know how to point Matlab to my OpenGL libraries and headers to make that work.

Another option I have looked into is communicating between programs using TCP/IP. I found these two links:
http://www.mathworks.com/matlabcentral/fileexchange/345
http://www.mathworks.com/matlabcentral/fileexchange/11802-matlab-tcpip-code-example
The second link is an example of the TCP/IP functionality built-in to Matlab. I can type in a web address on the appropriate line in the example file, but I don't know how to expand on that to sending and receiving data.

Before I research this too heavily, is TCP/IP a waste of time for what I want? What I want is a way to send position data from Matlab to an OpenGL routine that renders balls at those positions in real time. Doing this with MEX files would be idea, since they seem simple to me. I don't know anything at all about networking beyond the fact that TCP/IP is something to send and receive data.

On 11/12/10 6:48 PM, Evan Sullivan wrote:
> I am working on a computer vision problem of tracking points in 3D. My
> program determines the 3D position of tracked points in a scene, which I
> would like to display in an OpenGL window.

> Before I research this too heavily, is TCP/IP a waste of time for what I
> want? What I want is a way to send position data from Matlab to an
> OpenGL routine that renders balls at those positions in real time.

You need to define "real time" for your purposes. How quickly are you 
calculating data, how many data points are you tracking, is there a 
natural "frame" of data that you want to update the display after or are 
the points tagged and you want to update the display of each one ASAP 
after the data is available?

I suspect that _likely_ you could get away with building a patch object 
representing a ball centered at (0,0), make a copy of its vertex 
position information, copyobj() it as many times as needed to account 
for all the objects you are tracking; then for each object being 
tracked, add the new x and y coordinates of its centroid to the saved 
ball coordinates and set() those as the new coordinates for the patch 
object. When you have done a pass through the complete video frame, 
drawnow() to trigger an actual screen update. If you have a reasonable 
number of objects then especially if you are not using transparency and 
special lighting, that would probably be "real-time" enough.

Walter Roberson <roberson@hushmail.com> wrote in message <cKWMo.1301$Qi5.344@newsfe01.iad>...
> You need to define "real time" for your purposes. How quickly are you 
> calculating data, how many data points are you tracking, is there a 
> natural "frame" of data that you want to update the display after or are 
> the points tagged and you want to update the display of each one ASAP 
> after the data is available?
> 
> I suspect that _likely_ you could get away with building a patch object 
> representing a ball centered at (0,0), make a copy of its vertex 
> position information, copyobj() it as many times as needed to account 
> for all the objects you are tracking; then for each object being 
> tracked, add the new x and y coordinates of its centroid to the saved 
> ball coordinates and set() those as the new coordinates for the patch 
> object. When you have done a pass through the complete video frame, 
> drawnow() to trigger an actual screen update. If you have a reasonable 
> number of objects then especially if you are not using transparency and 
> special lighting, that would probably be "real-time" enough.

Thank you for the reply, Walter. Your advice is just what I was looking for. In my case, "real-time" means as soon as the data is available from the rest of the program. I am working with two other people and we don't have the whole 3D reconstruction part done yet, so I can't say the exact time, but if the program runs ten times per second, I would like the graphic to update close to that rate. I was really just using "real-time" to differentiate between updating on the fly as soon as possible and collecting data that can be saved and rendered all at once later. We are tracking three points and will process maybe ten out of thirty frames per second.

From your suggestions, it does seem like I might just be able to do this all in Matlab; that would be great. It's the interface between Matlab and external programs that's getting me down. A crude visualization of the 3D reconstruction is all I'm after; I'll see what I can do using Matlab's 3D plotting tools tomorrow. Thank you.