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?
Paul ----- Original Message ---- From: J.P. Delport <jpdelp...@csir.co.za> To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org> Sent: Tuesday, January 27, 2009 11:27:45 PM Subject: Re: [osg-users] Multiple Render Target Question Hi Paul, paul1...@yahoo.com 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 osg-users@lists.openscenegraph.org > 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
