Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a "painters algorithm" and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc.
Richard On Dec 17, 2007, at 6:41 PM, Thrall, Bryan wrote: > Richard S. Wright Jr. wrote on Monday, December 17, 2007 5:22 PM: >> 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 ;-) > > To have the skydome always rendered last, give it a StateSet and call > setRenderBinMode(USE_RENDERBIN_DETAILS) and setRenderBinNumber(3). > Most > stuff uses RenderBin 0, (or 1 and 2 if there's transparent stuff), so > this should force it to be last (you can certainly set a higher number > if needed). Nested cameras and anywhere else you don't use the default > StateSet RenderBinMode will complicate things, though (RenderBins can > nest, and the numbers are relative order within the current > RenderBin). > > HTH! > >> 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. > > -- > Bryan Thrall > FlightSafety International > [EMAIL PROTECTED] > _______________________________________________ > 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
