Hi Paul,
[email protected] wrote:
I'm attempt to develop a Multiple Render Target (MRT) program and
have a few questions..
First, I see this in the osgstereomatch example: Two textures are
needed, because shaders cannot read and write to the same texture
during calculation. One texture is used as input and the other as
output. After a calculation, the input and output textures are
swapped. The technique is known as ping-ponging or flip-flopping the
textures.
What does this mean? Can I have the same texture defined as input
(assigned to the StateSet) and still have it attached (but not used)
as a render target?
I'm not sure if it will work. If the current output depends on the
previous output you need to fill a single of two targets (the current
output) while reading from the other (the previous output). If the
targets are attached to the same RTT camera I'm not sure how you can
write to one but not write to the other one.
In short, I see how I can ping-pong the input by
changing the texture uniform but how do I ping-pong the "attached"
render buffer? Can I "attach" all my render targets but then not use
them (if it's an input)?
In all the code that I've made, I've ping-ponged the attached textures
by swapping between two osg RTT cameras. The simplest example of this is
osggameoflife.
There are other ways to swap, but they are not easy to do with base osg
(I think, but am not sure, that osgPPU might help). For the options,
have a look at this:
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html
search for "ping pong".
The disadvantage of the two camera approach is that we are wasting FBOs.
An easier way to change attachments would help.
What happens if you do read and write to the same texture each frame?
Craziness. Try it. Think of multiple processes reading and writing to
the same memory in parallel. If there is any dependency between in/out
the data will get corrupted.
Also, does this clear all my render targets (between frames):
_Camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
I think so, but write out the buffers to check.
What I'm trying to do is calculate a temporal averaging of a specific
number of consecutive frames. I assume I need to keep a running
average of frames as well as well as save each of the frames. Then
each frame: SUM = (SUM - oldestFrame + newFrame) and Output =
SUM/numberOfFrames;
You might be able to get away with just storing a running average. You
can do something like:
time_constant = 10;
avg = ((time_constant-1)*avg + new_image)/time_constant;
This in effect creates a low-pass filter.
I think I'm done asking questions for now :-).
Thanks for any help you can provide...
Paul
cheers
jp
_______________________________________________ osg-users mailing
list [email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
