What I want to do is:
I’m creating a OpenGL 3D desktop, and now I’m facing a problem… How I can load an executable (application) that contain other OpenGL code and make it run on my 3D Desktop without creating another window? What I would like to do is simply integrate the OpenGL code to the main render loop and execute it as another thread… Is it possible?
Any idea someone?
Maybe you can pass a window ID on the command line - if you’re using Windows?
And I guess you’d also somehow need to share the render context with another process. Hmmm.
Might be difficult to achieve.
Come to think of it, it’s probably better to somehow wrap the apps’ OpenGL calls so you can pipe them back to your main render loop.
Hummm… ok how can I do that!?
btw, I’m on Linux using SDL
It’s a long time ago, but I think you can use the socket calls to create a pipe between the “server” (i.e. the program that does the actual rendering) and the “client” (the application).
You’d have to come up with a command set for the client to use. You can’t expect the render code of the client to cooperate nicely with the desktop if you leave the client to perform the actual OpenGL calls - it may change the perspective, it may clear buffers, it may want to refresh at different times than the desktop.
Some basic commands could be:
The server would have to keep a list of geometry to be rendered, and when the screen is about to be redrawn, execute the corresponding GL commands on the desktop window.
Basically, the sky’s the limit - but you’ll have to do it yourself.
The alternative is of course NOT to directly let the applications render 3D to the desktop, but have them render to texture and then draw that texture to the desktop window.
Hmm, I’m not really shure if I got everything right, but it looks like you’re speaking about forwarding opengl calls from an application to another one, so that the context of the second one will be used.
If it’s so, you can define the rendering code in shared procedures and export them in your application. The server will be then able to call them in his own thread.
If I got you wrong, just ignore 
You cannot do this within an OpenGL application.
Other applications need their own 3D context.
To do what you need you would have to wrap the OpenGL ABI and do something like intercept the swap call. Intercepting their swap call in their thread you could then send their image to your thread and display in on your 3D desktop.
To do a good job if this it should be clear that it would really need some driver level & OpenGL implementation work, and hopefully some really fast context switching support in hardware.
Some suggestions here are ridiculous, if you were to do something like OpenGL within OpenGL you’d need somthing like a context save & restore system, and that means everything including textures. It’s non trivial and probably the wrong thing to do. The thing to do is wrap the ABI and swap their backbuffer to a texture in your application (this would cover most applications).
Initially you’d do this with a thin layer that just did a read and transmit through shared memory, then you’d optimize this so your swap in their contest shared a texture with your desktop 3D context and your swap would be a glcopyteximage. Ultimately you’d want their application rendering directly to that shared swap texture (PBO).
Just keep at the forefront of your mind the fact that OpenGL applications have their own contexts & persistent state and operate on that assumption.
Errr… Dorbie?
I know you’re the moderator and all, and no doubt a very busy person, but maybe a statement such as “Some suggestions here are ridiculous” isn’t the most diplomatic way of getting your point across?
Funny thing is, as far as I can see, the suggestions are all pretty similar to yours.