Robert, Yes, mastery of a new technology certainly is a long term investment ;-)
Thanks for this explanation, it is a valuable insight. As I continue to grok more of the OSG "philosophy", I'm sure more of this will become more intuitive to me. I have now found three different solutions to my original problem that all work, so I feel I have moved another rung or two up the ladder ;-) I will also look at the examples you recommended for further insights. Richard On Dec 18, 2007, at 4:16 AM, Robert Osfield wrote: > Hi Richard, > > The OSG supports high level and low control over draw order via the > StateSet::RenderBinDetails. Basically the rendering backend is > constructed as a graph of what is called RenderStage(s) and > RenderBin(s), the StateSet::RenderBinDetails tells the cull traversal > how to build this graph, both the type of RenderBin to create/use and > what order it should drawn in. Its a very powerful feature, but its > is one of the more advanced and complex to understand ones so you'll > need to be patient and steadily bite into rather than diving straight > in the deep end and expect understand it all right away. > > To learn about making a subgraph draw first have a look at the > osghangglide example - it has a skydome that it renders first, and you > can switch off depth testing for it. The osgvertexprogram example > also has a skybox that is view dependant. > > For general rendering order control have a browse through the > osgreflect example. > > The osgprerender example also provides another example, this time > using render to texture cameras. > > Robert. > > On Dec 17, 2007 11:22 PM, Richard S. Wright Jr. > <[EMAIL PROTECTED]> wrote: >> Robert, >> >> Thanks, yes I have used the Fog approach before, it is especially >> effective for underwater scenes. >> >> However, I need to be able to see quite a ways distant (flight sim). >> If I was NOT using a scene graph, I would draw the sky dome as a unit >> sphere, and just rotate it by the camera transform, but not translate >> it (thus, appearing infinitely distant). I would draw it first, and >> not write to the depth buffer. >> >> Here's where the OSG newbie kicks in... doesn't the scene graph >> reorder the nodes at will (ok, I know it's not random, but you get my >> point)? Is there a way I have missed to say "this node must always be >> drawn first"? If so, I can easily manipulate the matrix of the sky >> dome to get the effect I want, and I bet I can turn off depth writing >> using the state mechanism. I have however, missed the " draw me >> first" >> flag ;-) >> >> Richard >> >> >> >> On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: >> >>> Hi Richard, >>> >>> You could play multi-pass tricks like done in the osgdepthpartion >>> example, or just manage the visible distance so that the furthest >>> distance is never too far away. For instance a common trick is to >>> use >>> Fog to make far objects fade away until eventually nothing beyond a >>> certain distance can be seen - so you simply cull it and this pull >>> in >>> the far plane. The skydome could also be computed dynamically to >>> just >>> fits the size of the scene required for that frame instead of the >>> whole model. >>> >>> Robert. >>> >>> On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. >>> <[EMAIL PROTECTED]> wrote: >>>> I'm working on my first OSG project (so be gentle ;-) I'm using OSG >>>> 2.2 on >>>> OS X (Leopard). >>>> >>>> I have a terrain in a .osga file, a skydome, and some .3ds models. >>>> Everything loads fine, and I have a flight sequence working that >>>> takes off >>>> and lands on an aircraft carrier. >>>> >>>> There are lots of samples that made this part pretty easy to figure >>>> out >>>> (just load and move objects around). I'm a little lost however as >>>> to how OSG >>>> is handling the near and far clipping planes, and object scale. >>>> Actually, >>>> OSG seems to be monkeying with these settings in a manner that is >>>> probably a >>>> nice feature once I understand how to best make use of it. >>>> >>>> The terrain is really big, the skybox is really big, and the models >>>> are >>>> really small in comparison. OSG seems to recomputing the near and >>>> far >>>> clipping planes depending on the objects in view. For example, on >>>> the deck >>>> of the carrier, all is well. If I turn so that the terrain is also >>>> in view >>>> (off in the distance), the near clipping plane seems to be changed >>>> and parts >>>> of the carrier disappear (the same happens with the large >>>> skydome...) >>>> apparently to accommodate the display of the much larger model that >>>> is now >>>> in view. >>>> >>>> I did find an old message that says this: >>>> >>>> >>>> Camera- >>>>> >>>> setComputeNearFarMode >>>> (osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); >>>> >>>> prevents this... however, then I need a giant frustum to hold >>>> everything and >>>> we all know what a bucket of z-fighting joy that brings. It is not >>>> clear to >>>> me how to arrange these objects correctly to make this "rescaling" >>>> of the >>>> scenes objects work correctly. Currently, the terrain database, the >>>> skydome, >>>> and the ship models are all hanging off the root of the scene graph >>>> with >>>> just a transform that scales, translates and rotates them as >>>> necessary. >>>> >>>> Is there a 'standardized' technique for this (it can't be that >>>> unusual), >>>> none of the example programs seem to have this kind of >>>> configuration. >>>> >>>> Richard >>>> >>>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> [email protected] >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
