Having another program control rendering

[amoskoh]

I have some standalone C++ code that decides does some calculations and decide a dynamic flightpath of some airplanes.

What I would like to do is have those flightpaths displayed though opengl.

However, in my previous programming with OpenGL, I use the glutDisplayFunc and glutIdleFunc to display.
But how would I integrate my C++ code with the rendering code because my C++ code decides the coordinates of the code and passes it to my opengl code, but since rendering functions registerd through glutDisplayFunc and glutIdleFunc are always running.. how do I move program control to my program?
Ie I want to start rendering. then go back to my C++ code that does its own stuff and updates the coordinates whenever it wants to.

I suppose using shared data structures is a solution but.. that might involve mutexes since I add and delete new objects.. so that list has to be locked.

Right now a hack is to have my opengl code being called by my c++ code and in the display code, I ask for new coordinates every now and then.

But this will not be sufficient if I want to send data to 3 diff rendering codes that draw difff scenes.

So how can I better control the whole rendering process if I'm always stuck in the loop for the display and idle functions.

[shinpaughp]

semaphores, shared memory, sockets, signals...

I've had some success using glut to do rendering outside of any callback functions. Like this:

-glutSetWindow( someWindow ); // focus on a window
-perform OpenGL drawing: glBegin..glEnd()
for instance
-glutPostRedisplay();

-in the display callback:
glFlush();
glutSwapBuffers();

I've had some of the experts on this forum object to this method but it works.

I'm a relative newbie so take my advice with a
large grain of salt.

Forgot to mention - I'm not stuck in a loop. I use glutMainEventLoop() which exits and lets you get back to doing other stuff. glutMainEventLoop() is from the OpenGLUT library. Your executive could look like:

- initialize your window(s)

while
{
- call you flight calculations

glutSetWindow( your window );
- invoke OpenGL stuff to draw
glutPostRedisplay();

glutMainEventLoop();

// returned from glutMainEventLoop

}!done;

[amoskoh]

hmm glutMainEventLoop(); looks promising but I cant find any documentation for it.
Only 2 links for it came up in google. and those were extensions to the OpenGL library.

[amoskoh]

Perhaps my description of my problem wasnt clear enough.
I basically have some decision code that decides to draw planes from point A to B in t seconds. And it can add new planes to draw whenever it wants. And I cant put this update code as my idle function.

At the same time, I want to display the airplane flying on a textured background.
I also want to display the events in a different display.

How do I integrate this?
The only idea I have is to start my decision code that spawns two threads to display.
And the two display codes will be the normal glut application that draws planes using shared memory with my decision code.
Does this sound right?
Or is there a simpler way

[amoskoh]

If the program werent threaded.. how would i start my decision code, start my display.
and every now and then send new inputs to be drawn to my display?
Problem1: glutmainloop keeps looping, i cant return to my decision code.
Problem2: if problem 1 is solved, how do I signal something new to be drawn by my display?

[bubbaJr]

OpenGLUT:

http://openglut.sourceforge.net/

[bubbaJr]

I am currently working on a Windows/OpenGLUT/OpenGL program that has 4 windows and 2 subwindows. We're drawing 2-dimensional symbols that move on 3 of the displays while drawing bitmapped text to a 4th display. We're doing all of that in 1 (one) thread. We've considered making the leap to multitasking but so far it has not been necessary.

When you want to draw to one of the displays:

glutSetDisplay( display1 );
-draw some stuff
glutPostRedisplay();

and then to the other display:

glutSetDisplay( display2 );
-draw some stuff
glutPostRedisplay();

Better check this out with an expert. However, it's working very well for us.