I am working on a UAV simulation program and I do all of the rendering
in OpenGL. I want to simulate video from a camera and pipe it to
another application. I did this by rendering to the window and then
using glReadPixel(). It worked fine on NVidia hardware but ran VERY
slow on ATI harware. I tried using PFD_DRAW_TO_BITMAP and got it
working but only to find out that all rendering is not hardware
accelerated in this configuration. Is there some way that I can
retrieve the hardware accelerated rendered frames into main memory in
efficient way on all hardware. I have done quite a bit of research on
pbuffers and framebuffer_objects, but it seems that they are primarily
for rendering views to existing textures for reflection and other
techniques. Where can I find information on the best way to do this?
Thanks,
Dave Johansen

"Dave Johansen" <davejohansen@gmail.com> wrote in message
news:1123813127.020834.282040@g43g2000cwa.googlegroups.com...
> I am working on a UAV simulation program and I do all of the rendering
> in OpenGL. I want to simulate video from a camera and pipe it to
> another application. I did this by rendering to the window and then
> using glReadPixel(). It worked fine on NVidia hardware but ran VERY
> slow on ATI harware. I tried using PFD_DRAW_TO_BITMAP and got it
> working but only to find out that all rendering is not hardware
> accelerated in this configuration. Is there some way that I can
> retrieve the hardware accelerated rendered frames into main memory in
> efficient way on all hardware. I have done quite a bit of research on
> pbuffers and framebuffer_objects, but it seems that they are primarily
> for rendering views to existing textures for reflection and other
> techniques. Where can I find information on the best way to do this?
> Thanks,
> Dave Johansen
>

Render to a window or P-buffer is it. Readback is usually in the range of
20-60 frames/sec for 1 meg windows. Be careful about readback format.
Ati drivers have got much better about this a year or so ago, verify that
you have a new one.

See also Chromium and glAnywhere, they do this sort of readback "for a
living".

-jbw

Yes, I have the newest avaialble drivers. I only want a 640 x480 at 30
fps, so hopefully I can get it to work. Is a p-buffer the better way to
go and if so is there some documentation that says how to do this?
Thanks,
Dave

<davejohansen@gmail.com> wrote in message
news:1123822429.568625.39700@o13g2000cwo.googlegroups.com...
> Yes, I have the newest avaialble drivers. I only want a 640 x480 at 30
> fps, so hopefully I can get it to work. Is a p-buffer the better way to
> go and if so is there some documentation that says how to do this?
> Thanks,
> Dave
>

If a window works for you then a p-buffer has no special advantage,
use GL_BGRA_EXT and unsigned byte format to read back.

if you search the web for pbuffer opengl I'm sure you'll find lots.

davejohansen@gmail.com wrote:
> Yes, I have the newest avaialble drivers. I only want a 640 x480 at 30
> fps, so hopefully I can get it to work. Is a p-buffer the better way to
> go and if so is there some documentation that says how to do this?
> 

A pbuffer will make no difference. The most
important thing is to match the source and
destination pixel formats. On Windows this
is normally BGRA_EXT, not RGBA. Try doing
your readpixels using this format.



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

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

I finally got it to work at a decent speed and just for anyone in the
future that reads this thread here's what I was doing originally (which
was ridicuously slow) and what I finally did that worked just fine
(wasn't blazing fast but ran at 640 x 480 at over 30 fps with only
minor CPU usuage, which is to be expected).

Need:
I needed a 640 x 480 view of the world from a virtual camera that could
be streamed to another application.

Original Scheme:
Initially the program set glViewport() to 640 x 480 (no matter what the
actually window size was). I then read the view using glReadPixel() and
it ran horridly slow.

Final Scheme:
I created a second window that rendered the same scene by sharing lists
and it's size was set to 640 x 480. I then called glReadPixel() on this
window and it worked just fine.

On NVidia hardware both of the schemes ran just fine, but on ATI
hardware the original ate up TONS of CPU and only ran at like 2-3 fps.
I guess that the ATI implementation of glReadPixel doesn't like reading
just a small segment of the rendered scene.
Thanks for all of the help,
Dave Johansen

davejohansen@gmail.com wrote:
> Need:
> I needed a 640 x 480 view of the world from a virtual camera that could
> be streamed to another application.
> 
> Original Scheme:
> Initially the program set glViewport() to 640 x 480 (no matter what the
> actually window size was). I then read the view using glReadPixel() and
> it ran horridly slow.
> 
> Final Scheme:
> I created a second window that rendered the same scene by sharing lists
> and it's size was set to 640 x 480. I then called glReadPixel() on this
> window and it worked just fine.

This seems to be an odd solution, as your window needs to be displayed 
(and in front of all other windows) to be actually valid. I would 
definately suggest taking a look at pbuffers or fbo instead.


Kind regards,
\\Mikkel Gjoel

It is a little bit of a funky solution but it works totally fine and
from all of the reading I did it sounded like pbuffers were a HUGE pain
and framebuffer_objects weren't available on most drivers, but if this
isn't the case then please let me know.
Thanks,
Dave

davejohansen@gmail.com wrote:
> It is a little bit of a funky solution but it works totally fine and
> from all of the reading I did it sounded like pbuffers were a HUGE pain
> and framebuffer_objects weren't available on most drivers, but if this
> isn't the case then please let me know.
> 

pbuffers work on almost all cards.

framebuffer_objects  are available on ATI and
NVIDIA for cards made in the last couple of
years.


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

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

It turns out that the way that I had done it didn't work on NVidia
cards unless you were running in dual monitor mode (not working I would
understand but then suddenly working in dual monitor mode is just
weird). I actually found a really good example of using pbuffers at
http://www.codesampler.com/oglsrc/oglsrc_7.htm and I now use that and
it works great.
Thanks for all of the help,
Dave