Hi Miika, OK, i was able to run this. Yes, I can see the issue you are speaking about. And I think, I understand where the problem is...
> > To fix this problem, we can try to add firstProcessor as a child of > slaveCamera instead of root, as explained in my previous posts. However, this > somehow breaks stage 3, which refuses to render to a texture anymore. > This is also a correct step. If you do so, then you get the correct rendering order of PPUs. So the slave camera is rendered first and the master camera afterwards. However, as you already pointed out, the frame buffer of the main camera is not bound anymore. I think the problem is, that osgppu uses FBOs without cameras and hence forces osg to reset its states, incl. FBOs back, after rendering of PPUs. Now, using the scene graph you have in your example application we would get this structure: mainCamera->FBO | root | +--- scene | +--- slaveCamera->FBO -- 1st Processor --- scene | +--- 2nd Processor Although the traverser is rendering the objects in correct order, but it also always restores the previous states of the parent after the rendering a subgraph. For example if you render objects in the main camera and one of this objects uses FBO in its stateset, then after rendering of this object, the FBO will be restored back. However, currently in OSG there is no restore mechanism to restore to the correct FBO. So it just restores to FBO 0. I already claimed about that problem around year or two ago, because I also wasn't able to solve that issue. I have discusse dabout that issue already on hte mailing list, however this was just about DrawBuffers. I do not remember how that discussions ended, so maybe we ended up either in "not needed feature" or "do not know how to patch OSG to support this". The problem is, that one assumes that FBOs are only used for Cameras, therefor there is only a special treatment for that case. The problem would arrive with any other type of graph, where a node set an FBO to something. Because the RenderStage traces which state changes there were done, it will also trace that FBO was changed. Hence it will change FBO to its global default, when the corresponding node is not rendered anymore. So in order to solve that issue, one has to patch OSG to support to restore FBO to its previous state and not just to something default. However this seems to be harder than its sounds. In deed, as I have stated already previously on the mailing list: Restoring to something "baseline specific" (default value) of an StateAttribute is not a right way to do it. In most cases this works well, however in complex cases it breaks down. Maybe I can try to write a patch to oslve it, however this require big changes of current scene graph implementation, so that it may introduce just much more bugs. cheers, art P.S. > > Anyway, this is my problem of course and I'm not demanding that anyone fix it > for me, but I think that having the ability to do this would be very > benefical for osgPPU in general. As I mentioned before, osgPPU would be > perfectly suited for things such as processing shadow maps or any number of > other advanced algorithms, aside for this one little detail. > In deed, I have used PPU not only for post processing, but also for inbetween processing. Take a look into this video: http://www.tevs.eu/project_sigasia08.html from 3:30 you see a TV screen with some video running on it. This video texture was processed by osgPPU to look little bit blueish like in real TVs. However none of my porjects realy depends on frame coherency, hence I haven't took a lot of effort to correct this issue :( ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16044#16044 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
