I’m looking for information on direct rendering on Linux. I’d like to do this in Perl or Python, but C/C++ (or something else is fine too).
An example of what I’d like to is: draw something into the framebuffer and save it as, e.g., a JPG, but without opening up a window. I need to do this without a local connection.
Thanks
What do you mean by a local connection? You have to have a connection to an X server to do hardware-accelerated OpenGL rendering. If running an X server is out of the question, use OSMesa (Off-screen Rendering — The Mesa 3D Graphics Library latest documentation) for software rendering.
If you have a connection to an X server, you can use a normal window and just not show it (e.g. with GLUT, create the window, but never call glutMainLoop). Or you can use a pbuffer. Either of these can get you a direct, hardware-accelerated GL context without a visible window.
It is probably impossible to render something to the framebuffer but at the same time preventing that it is visible. When using linux, when you copy things from the framebuffer to a texture with glCopyTexSubImage(…), only the parts of the image that are visible (i.e. not covered by other windows, or a screensaver) are looking right, at least with nivida boards. And if you want to render something harware accelerated, you have to use X, and you certainly need a window as well to get an OpenGL context established. Maybe there is a completely different solution for your problem. Why do you want to do that anyway?
Originally posted by Jesse Hall:
[b]What do you mean by a local connection? You have to have a connection to an X server to do hardware-accelerated OpenGL rendering. If running an X server is out of the question, use OSMesa (Off-screen Rendering — The Mesa 3D Graphics Library latest documentation) for software rendering.
If you have a connection to an X server, you can use a normal window and just not show it (e.g. with GLUT, create the window, but never call glutMainLoop). Or you can use a pbuffer. Either of these can get you a direct, hardware-accelerated GL context without a visible window.[/b]
The idea is to do server-side rendering and display the results via the web (so no X server connection). I can think of a few uses for this, e.g., running a GL program from a really slow machine without GL support (nothing with interactive frame rates, of course). It might also be interesting to use GL to dynamically generate web page graphics.
Mesa seems to be the way to go, though just quickly browsing through the FAQ I can’t tell whether it supports vertex/fragment programs (which I’d like to have).
Thanks,
Keenan
P.S. Are you the Jesse Hall from UIUC? If so, I may see you at nVidia (I’m also a UIUC student and am an intern at nVidia this summer).
If the situation is that you want OpenGL scenes displayed on clients and rendering takes place on the server, and this should happen on the internet, I would suggest the following:
The server renders the scene and captures it to an image, and on the client, there’s a java applet running which receives theses images in a compressed graphics format (for example, .jpeg) and displayes them. The bottleneck of doing something like that will obvioulsy be the speed of the internet connection, so a java applet which displays images would be sufficient.
Another way would be to do the rendering on the client computer, as high frame rates seem not to be possible anyway, you can do this in software as well. For this, you might use a java applet, with gl4java, you can even do OpenGL rendering (hardware accelerated) on a client computer through the internet, or simply in software.
Rendering directly into a client’s framebuffer through the internet sounds quite exotic and restricted to very special solutions, but as you have to send image data anyway, you might also simply use a more generel solution like displaying images or a stream via a java appet or something like that.
Regards
Jan
Originally posted by JanHH:
[b]If the situation is that you want OpenGL scenes displayed on clients and rendering takes place on the server, and this should happen on the internet, I would suggest the following:
The server renders the scene and captures it to an image, and on the client, there’s a java applet running which receives theses images in a compressed graphics format (for example, .jpeg) and displayes them. The bottleneck of doing something like that will obvioulsy be the speed of the internet connection, so a java applet which displays images would be sufficient.
Another way would be to do the rendering on the client computer, as high frame rates seem not to be possible anyway, you can do this in software as well. For this, you might use a java applet, with gl4java, you can even do OpenGL rendering (hardware accelerated) on a client computer through the internet, or simply in software.
Rendering directly into a client’s framebuffer through the internet sounds quite exotic and restricted to very special solutions, but as you have to send image data anyway, you might also simply use a more generel solution like displaying images or a stream via a java appet or something like that.
Regards
Jan[/b]
The .jpg solution is where I’m headed.
One reason I don’t want to use gl4java is a typical reason things are done server side - I don’t want to worry about things working correctly on the client end (namely OpenGL and Java). I’m looking for a “works anywhere with any crappy machine/any crappy web browser” solution. I don’t think a java applet is even necessary to receive the images; I can refresh a webpage when a form is submitted. Really I just want to render static images, but allow them to change based on context (e.g., time of day) or occasional user input.
Thanks for the suggestions,
Keenan
well, it looks like you a) already know what you want to do, and how to do this and b) this has nothing to do with the original topic - direct rendering. Or do you want to render directly to fhe framebuffer, without any window, on the server?
Or do you want to render directly to fhe framebuffer, without any window, on the server?[/QB]
Yeah, that’s what I’m really after. Why do you need a connection to the X server?
Originally posted by DarkenedFetus:
The idea is to do server-side rendering and display the results via the web (so no X server connection). I can think of a few uses for this, e.g., running a GL program from a really slow machine without GL support (nothing with interactive frame rates, of course). It might also be interesting to use GL to dynamically generate web page graphics.
Mesa seems to be the way to go, though just quickly browsing through the FAQ I can’t tell whether it supports vertex/fragment programs (which I’d like to have).
Mesa 6 supports the ARB VS/FS extensions, I think. No GLSL yet, but you can use Cg.
If the server has a graphics card and an X server running (even if it’s headless) you can still get accelerated rendering, then capture the results and ship them to the client as an image as other people have mentioned.
P.S. Are you the Jesse Hall from UIUC? If so, I may see you at nVidia (I’m also a UIUC student and am an intern at nVidia this summer).
That’s me! Small world, huh? Look me up when you get there. Were you at the dinner when Jamie & Co. visited in Feb.?