Hi Alexej, On 15 May 2012 09:58, Alexej Fink <[email protected]> wrote: > The problem is not the re-rendering of a single tile. The job is to re-render > a tile subset from a collection of tiles (each tile has an unique texture > object bound to it).
So why are you re-rendering tiles? Shadows? Other effects? You'll need to provide some context for others to understand what you are trying to do. A single sentence doesn't cut it when you are talking about a very custom technique that you have in your head. > Assuming I will do it this way. > > 1. Will I have to enable/disable cameras in relation with the dirty state of > the tile? (otherwise all cameras will re-render the tiles, even these, with > no changes). NodeMask's, osg::Switch or custom Node callbacks that override the traversal all can be used to toggle on/off the RTT Camera's at runtime. > 2. What about the rendering context for each camera? Does it not produce > extra costs? E.g. the depth RenderBuffer (which could be shared using > render-target exchange approach) and other meta data (as I understand from > RenderStage::runCameraSetUp(..)) When your use FBO's each Camera shares the main graphics context that they are assigned to, so there is no context switching. The only state changes that are made when reusing Camera is what you'll have when rendering any RTT Camera, there is no additional overhead. > It may be wrong: osg is not easy to understand, especially since the most > classes do not even describe their main purpose (in doxygen). Advanced scene graphs with lots of functionality won't always be easy to understand. The lower level and more custom usage the more you'll need to understand the internal complexities. This isn't easy to master, more/better documentation will help but in the end it's still pretty complicated, especially if you are trying to come up with unusual and non standard techniques. This is why I'm trying to push you to explain what and why you are trying to do, often users come up with overly complicated ways to solve problems they are easy to solve if only they stop premature deciding what the best solution is to their problem. > But for me, the approach with changing the render color target looks still > more efficient, assuming I can change the color binding in a fast and > light-way manner. Um.... I know the scene graph better than you, and perhaps you know your problem better than I, but without you telling us what you are trying to achieve rather than how we have no way to judge this. > Because all camera parameters stay constant all the time except the position > and color-target. Otherwise it requires one frame() call per tile > re-rendering, here I don't know, how expensive that is compared to hundreds > of possible cameras approach (but usually only few tiles needs to be > re-rendered). > > The main question remains: is there a light-way possibility to change the > color binding in an already existing RenderStage/FBO context ? That's your question, as I said the RTT Camera/FBO support hasn't been written specifically for you usage model, changing the FBO might be possible, but you'd need to look at the internals. The main question I have, and I'm sure others have is, what are you trying to do and why. Providing low level advice when one doesn't know the high level context is likely to be mis-directed and mis-informed. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
