PDA

View Full Version : Control OpenGL program from another program



03-27-2004, 03:39 AM
Hello,
I have a problem. I am using Linux and I want to visualize a shape which is moving in the space. For this I have a calculation program which gives me the coordinates of the shape to a special time. Now it shall run real time. That means I want to start my calculation in a function. From there I want to call my OpenGL program and in a time loop I want to send my new coordinates to the visualization. These coordinates shall be displayed immediately. Is it possible? And when it is possible how can I realize this?

I am grateful for every answer.

Chrispi

john
03-28-2004, 09:35 PM
Hello,

you need to sort out some concurrent programming, which you can either do with posix threads (lightweigth processes) or real concurrent processes. Which is easier for you? Hmm... I use both. I liek the idea of a process forking and opening a connection to its parent, so I'd be more inclined to do that...

cheers,
John

nutball
03-29-2004, 04:11 AM
I guess MPI might be another alternative.

04-01-2004, 05:22 AM
Hello John,
thank's a lot for your reply. I think to work with the forking command is the right solution for me. I also worked with this kind of programming one year ago, but I didn't come to this idea.

Kind regards,

Christoph

zen
04-03-2004, 04:55 AM
Is this sort of complexity absolutely necessary? What I mean is that if you don't have the source of the programm that calculates the coordinates (or for some other reason don't want to mess with this programm) then you'll have to write a renderer and setup some kind of interface between the two programs as has allready been suggested. The easiest by far way to do it though is to modify your coordinate calculator to write these coordinates to vertex arrays (or much better stream it to VBOs) and then simply render this. This can all go in one loop. I can't see reason to use multithreading here (but I'm possibly mistaken as I don't exactly know what this is all about) and believe me, you don't want to use multithreading unless absolutely necessary.

john
04-03-2004, 05:25 PM
Meh, multithreading isn't that hard. I once did a practical much like what the original poster described, except I *did* use MPI (because it was a requirement of the prac). My assignment was to compute and render a fluid simulation; the otuput was displayed on an Onyx2 and the structure was computed on the SGI cluster downstairs.
... so, it's not always possible nor desirable to tightly couple the renderer with the thing that computes the data.

tonnes of fun for all the family!

zen
04-07-2004, 09:03 AM
Meh, multithreading isn't that hard. I once did a practical much like what the original poster described, except I *did* use MPI (because it was a requirement of the prac). My assignment was to compute and render a fluid simulation; the otuput was displayed on an Onyx2 and the structure was computed on the SGI cluster downstairs.
... so, it's not always possible nor desirable to tightly couple the renderer with the thing that computes the data. Well I did say that I'm not familiar with chris' particular situation so multithreading might well be the only way. I also didn't want to imply that multithreading is pure evil that should be avoided at all costs unless there's absolutely no way around it, I just meant that it will complicate things and make debugging harder so you should only use it if the benefits are worth it (e.g. on multicpu/hyperthreading/cluster systems where pefromance is really important, not on single cpu systems)