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
