Hello-
I'm working on a project that involves rendering a 3D scene to an
image (just as it would appear on the screen), which needs to end up
in main memory. The end result should ideally be cross-platform, and
able to run either with a GUI (showing the scene that is being copied
to the image), or headless with multiple instances.
We've looked at several approaches to doing this, and I'm looking for
feedback about the efficiency / usefulness of them (we're not graphics
experts). Originally, the system used PBuffers, which worked, but it's
looking like that isn't going to be a good solution in the future (ATI
seems to have dropped sup****t for those in their latest Linux
drivers). It looks like those have been superseded by Framebuffer
Objects, but the libraries we are using don't sup****t those yet. I
recently took another look at the problem, since the ATI drivers quit
working, and ended up with a simpler system that just uses
glCopyTexImage2D and glGetTexImage to read the pixels back.
So I need to know what the downside to this simpler approach is. We're
not doing render-to-texture (except as a means to getting our pixels
out), which seems to be the common case these things were designed
for. PBuffers and FBOs are for "offscreen rendering", which sounds
like what we want, but I'm not certain exactly what that functionally
means, since the system I have now works fine when the window is moved
off screen and even before the window is created.
So am I going to run into problems down the road when I try to make
the system completely headless and run multiple instances? Am I
relying on behavior that is a quirk of my Linux 3D system that won't
work in Windows? And are any of these approaches significantly more
efficient than the others if the pixels have to end up in main memory?
Thanks for any help.
-Sam Wintermute
|
