Hi,

is there any way to render a scene without openning a window
(glutCreateWindow)?

I have a program, that opens a window, saves the rendered scene to
disk and exits.
I run my program from a console and there is *no way* for me to use X.
I am only interested in the image-file that the program saves to disk,
so I dont need this window anyway.

The second problem: I use glReadPixels to read the frame buffer (the
rendered scene), but sometimes I get parts of my desktop (like the
toolbar) saved in the image-file. What I need is a way to render a big
image (e.g. 2000x3000) and save the result to disk...all this on the
command line and no windows.

Can someone help, please?
Hristo

starlight wrote:
> is there any way to render a scene without openning a window
> (glutCreateWindow)?
[snip]
> The second problem: I use glReadPixels to read the frame buffer (the
> rendered scene), but sometimes I get parts of my desktop (like the
> toolbar) saved in the image-file. What I need is a way to render a big
> image (e.g. 2000x3000) and save the result to disk...all this on the
> command line and no windows.

If you want hardware-acceleration for your 3D rendering on Linux, there 
is no way around X that I know of. I think the preferred way of doing 
OpenGL without opening a window is using pbuffers, which essentially 
create a frame buffer in graphics card memory, let you associate a GL 
context with that frame buffer and render into it, and then read back 
the buffer's contents using glReadPixels. Since there is no associated 
window on the screen, your image won't get clobbered by other windows. 
The problem is: You still need to open a connection to the X server to 
get access to the graphics card. This is possible from a console, *if* 
the X server on the console host is set up to allow local X connections 
- essentially, if "xhost +localhost" has been issued. We use this to do 
cluster-based HW accelerated rendering all the time, but some sysadmins 
frown on it, since it is a potential security hole.

If that is not an option for you, the other way might be to use a 
software-only OpenGL implementation such as Mesa. Mesa offers an 
off-screen rendering buffer that needs no X whatsoever, IIRC.

Hope this helps,

   Oliver

-- 
Email: kreylos@cs.ucdavis.edu
WWW:   http://graphics.cs.ucdavis.edu/~okreylos/ResDev

starlight wrote:
> Hi,
> 
> is there any way to render a scene without openning a window
> (glutCreateWindow)?
> 
> I run my program from a console and there is *no way* for me to use X.
> I am only interested in the image-file that the program saves to disk,
> so I dont need this window anyway.
> 

I think you need to go with MESA for this.
Yes, it's software, but you're asking for
unusual things.

> The second problem: I use glReadPixels to read the frame buffer (the
> rendered scene), but sometimes I get parts of my desktop (like the
> toolbar) saved in the image-file.

That's just the way it is...


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

Hi Oliver,

slow down a bit.. first of all I'm not low tech graphic geek. I did
some Java3D programming for a while but OpenGL isnt my area of
expertise.
Having said that.. I didnt knew til 2 hours ago what pbuffers and mesa
are. (:-|

> - essentially, if "xhost +localhost" has been issued. We use this to
do
> cluster-based HW accelerated rendering all the time, but some
sysadmins
> frown on it, since it is a potential security hole.

this is almost exactly what i want to do. I use MPI for parallel
rendering and only one process calls the OpenGL functions (all the
others do something else).
Because the job is scheduled by PBS, I cant actually tell where (on
which machine) the master (that does OpenGL calls) will be scheduled..
so I cant tell on which node the window will need to be opened and I
cant use xhost (tell me I'm wrong).
This is another very anoying issue. Normally MPI can be used across
different architectures, but using OpenGL with MPI somehow kills the
portability. This is really bugging me for the moment, because I fear
that if PBS schedule my master (which was compiled on Linux) to a
Sparc-node, then the whole application will fail. Is there something I
can do about it?

And about mesa: I replaced the glut calls with the mesa ones, that i
found on the Web.
It seems to work now, but I dont know if it is a good programming
practice.

Thank you guys! (both of you :-))
Hristo

starlight wrote:
> slow down a bit.. first of all I'm not low tech graphic geek. I did
> some Java3D programming for a while but OpenGL isnt my area of
> expertise.
> Having said that.. I didnt knew til 2 hours ago what pbuffers and mesa
> are. (:-|

Well, now you do, and that's all that matters. :)

>>- essentially, if "xhost +localhost" has been issued. We use this to
> do
>>cluster-based HW accelerated rendering all the time, but some
> sysadmins
>>frown on it, since it is a potential security hole.

> this is almost exactly what i want to do. I use MPI for parallel
> rendering and only one process calls the OpenGL functions (all the
> others do something else).

OK, this is not exactly what I'm doing, but similar - the opposite, in 
fact. In my case, all the MPI nodes use OpenGL to render (large volume 
data), and the master node only collects the rendering results and 
writes them to a TCP socket for a remote visualization frontend.

> Because the job is scheduled by PBS, I cant actually tell where (on
> which machine) the master (that does OpenGL calls) will be scheduled..
> so I cant tell on which node the window will need to be opened and I
> cant use xhost (tell me I'm wrong).

Yep, this is a tricky issue. The best way to resolve this is to work 
together with your sysadmin, and tell her that for your app to work, you 
really need to know beforehand which node the master is going to run on, 
and it better be a node with OpenGL. If you are the only one doing 
graphics with MPI, that's gonna be tough.

> This is another very anoying issue. Normally MPI can be used across
> different architectures, but using OpenGL with MPI somehow kills the
> portability. This is really bugging me for the moment, because I fear
> that if PBS schedule my master (which was compiled on Linux) to a
> Sparc-node, then the whole application will fail. Is there something I
> can do about it?

I don't think there's a very good solution without cooperation from the 
sysadmin.

> And about mesa: I replaced the glut calls with the mesa ones, that i
> found on the Web.
> It seems to work now, but I dont know if it is a good programming
> practice.

If it works - go for it. Mesa and "true" OpenGL are the same from an 
app's point of view, so no penalty for bad style. :)

Cheers,

   Oliver

-- 
Email: kreylos@cs.ucdavis.edu
WWW:   http://graphics.cs.ucdavis.edu/~okreylos/ResDev