Hi,
[email protected] wrote:
Thanks for your help...
One more question, I've been given approval to implement temporal
averaging using the OpenGL accumulator buffer like what is done for
osgmotionblur. However, that example adds an "operation" to each
window of the viewer to do this. In my case, I have a two pass
rendering approach and want to do the accumation "average" when
rendering to the texture (i.e. the first pass) and not on the second
pass output (i.e. so it can be used for the second pass). Therefore,
I assume adding it as a window operation to the viewer would mean it
would get done after all the rendering. Can I add this to the first
pass camera?
sorry, I've never actually looked at osgmotionblur or ever used the
accumulation buffer or "operations".
We do temporal processing by just passing a list of textures (ordered in
time) to an RTT camera and then accumulating using a shader. One can
connect the RTT camera anywhere in the processing pipeline to get the
processing order right. The display camera basically just maps the final
RTT camera output to a quad.
jp
Paul
----- Original Message ---- From: J.P. Delport <[email protected]>
To: OpenSceneGraph Users <[email protected]> Sent:
Tuesday, January 27, 2009 11:27:45 PM Subject: Re: [osg-users]
Multiple Render Target Question
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
--
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
