I've tried posting to several different groups, but I'm not able to
find the info I'm looking for just yet.

I'm not sure if this is the right group for this query.  Maybe someone
can at least direct me to a better place if not.

I'm looking to take the graphical output of a 3D rendered program (i.e.
a game), and make if available for real-time processing by another
program.

To be more specific, I want to use readily available 3D game
programming tools to create environments that I can use to train neural
networks to respond to visual stimuli.  The problem I am running into
is how to get the final product of a 3D rendered program into main
memory for random access by another program in addition to (or instead
of) displaying directly onto the monitor.

How much of the graphics processing is done in the graphics card?  What
would it take to have a continuously updated map of the drawn pixels of
a game in main memory?

Any relevant help or references would be greatly appreciated.

Jason

Jason <rhesus.monk@gmail.com> writes:

> How much of the graphics processing is done in the graphics card?

Quite a bit.

> What would it take to have a continuously updated map of the drawn
> pixels of a game in main memory?

The easiest solution is probably to hook up the output of the graphics
card to a framegrabber.

Jacob
-- 
�USA fights for the right of the individual.�
�Yes.  Those of the individual George W. Bush.�
                                     -- with thanks to Olfax

rhesus.monk@gmail.com wrote:

> To be more specific, I want to use readily available 3D game
> programming tools to create environments that I can use to train neural
> networks to respond to visual stimuli.  The problem I am running into
> is how to get the final product of a 3D rendered program into main
> memory for random access by another program in addition to (or instead
> of) displaying directly onto the monitor.

This is very API specific (OpenGL/DIrectX/Software).
I'm familiar with OpenGL and I can think of ~3 ways to do this.
Could you be more precise on what frameworks you will be using?
Also c.g.api.opengl would be a good group to ask more technical
questions about this topic.

-- 
For�email,�remove�my�socks.

T. Nitschke wrote:
> rhesus.monk@gmail.com wrote:
>
>
> This is very API specific (OpenGL/DIrectX/Software).
> I'm familiar with OpenGL and I can think of ~3 ways to do this.
> Could you be more precise on what frameworks you will be using?
> Also c.g.api.opengl would be a good group to ask more technical
> questions about this topic.
>

Very good.  OpenGL is precisely the framework I was intending to use,
if I could swing it.

So you know of ways that this can be done?  Please do share.

Thanks,
Jason

rhesus.monk@gmail.com wrote:
> So you know of ways that this can be done?

Ok, how-to-get-my-rendered-image-in-opengl:

1:

Use glReadPixels, this will always work no matter what
OpenGL-Version/Extensions you have available.
It simply gives you a memorybuffer with the screendata you wanted.
Besides from color values you can read depth values and stencil
values. Unfortunatly this method is the slowest
(causes mutiple bufferflushes in the driver).


2 & 3 (because there a multiple ways to do this):

Rendering your scene to a texture and get the texturedata.
This may look like a detour at first but combined with the
GL_ARB_pixel_buffer_object extension you gain perfomance
and flexibility. 

Here is a small extract of the GL_ARB_pixel_buffer_object  specification
which explains the advantage over the normal glReadPixels method:

Asynchronous glReadPixels:  If an application needs to read back a
      number of images and process them with the CPU, the existing GL
      interface makes it nearly impossible to pipeline this operation.
      The driver will typically send the hardware a readback command
      when glReadPixels is called, and then wait for all of the data to
      be available before returning control to the application.  Then,
      the application can either process the data immediately or call
      glReadPixels again; in neither case will the readback overlap with
      the processing.  If the application issues several readbacks
      into several buffer objects, however, and then maps each one to
      process its data, then the readbacks can proceed in parallel with
      the data processing.

Storing  the scenedata in a texture
makes it possible to apply imagemanipulations (sharpening, edgedetection,
brightness, converting to greyscale etc)  with OpenGL before you read the
data. This would give the CPU more time to handle your networks.

Sry for my english :)

-- 
For�email,�remove�my�socks.