Hi Art and J.P., thanks for the quick replies. :)
art wrote: > Is it possible that you provide me with a simple test case implementation to > test it. Because then maybe I would be able to find an answer how to correct > it. > I'll probably put some simple test case together at the beginning of next week, that should help me isolate it too. I'll get back to you with that, unless I've managed to fix the problem otherwise by then. Who knows, maybe the problem is somehow specific to the bigger program I'm working on now. > > I think osgViewer's camera is binded to FBO 0, because this is a main camera > which suppose to render to the screen. > I've set it to render to a separate texture (viewer->getCamera()->attach() etc.) so it should do it, and normally it does it too. It's only when I try to alter the rendering order that it starts making that command for no apparent reason. It actually binds to the correct FBO just before it makes the call to FBO 0, so the call doesn't come from the regular source. It almost makes me think that OSG is somehow handling this incorrectly, though probably I'm just trying to feed it with a badly constructed graph. > You could try to add a second camera below the osgviewer's, which renders > your scene into FBO. Then use the output of this camera for further > processing. So the graph could look like this: > > osgViewer > | > +--- depthCamera (with PRE_RENDER, to an FBO) ------- (stuff) > | > +--- colorCamera (with PRE_RENDER, to an FBO) --- (stuff) > | > +--- PPU-Graph > | > +--- (same stuff) > > > This will cause your rendering to be performed into FBOs and processed by > osgPPU. The ppu graph will have just no output to the screen, so no UnitOut > at the end. It will just process your renderings and the output textures > should be then used in the rendering of the main scene. > > The ppu graph will look similar to this: > > Processor > | | > UnitCamera UnitCamera > \ / > UnitInOut > > > I am not exactly sure, but here it still can happen that osgPPU will be > executed after your main scene is rendered, so that you get this one frame > delay. > I'll probably end up trying things like that if I can't come up with a clean solution. I'm kind of hesitant to make the osgViewer camera into just some "post-hack" stage, because I guess it's in principle supposed to be somehow special. Also the problem seems to be quite persistent no matter how I try to arrange everything. But I'll look into that. > > If you want to change the render bin number of processor, you do not have to > put it under a group and change the group's bin number. you can try to do it > directly by getting processor's stateset and change the rende rbin number > there (processor is derived from Group). > This is just for convenience - I think Processor::init() sets the bin number to 100, and it's run at the first traversal so it would overwrite my value and I'd have to re-overwrite it later. Perhaps there could be a function to specify the default bin number? J.P. Delport wrote: > > I'm not sure if this is different from what you tried with the group, > but have you tried adding the processor as a sibling of the depthcamera, > i.e. not a child of depthcam, but child of viewer? We have some > algorithms with multiple passes where we just add a bunch of prerender > cameras to a group and they execute in the order they were added (no > need to fiddle with bins). I know this works with RTT cameras and FBOs > (see e.g. osgstereomatch example), not sure of osgPPU interaction though. > This is pretty much the usual way to use osgPPU, so it should result in a typical last-stage processing. I think the "problem" is that osgPPU works basically by adding a bunch of screen-sized quad Geodes with a large renderbin number to the scene, whichever camera it is under (if I've understood it correctly). So in this case it will be under the osgViewer's camera and it'll render last. With that -1 group thing I tried to change the ordering such that the ppu-Geodes will render first thing in the main pass, but for some reason it causes that mystical FBO 0 problem. Anyway, I'll probably get back at Monday and I'll try to put together some example code then. - Miika ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15951#15951 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
