On Sun, 2011-09-11 at 23:18 +0100, Stuart Buchanan wrote: > On Sun, Sep 11, 2011 at 7:47 AM, Thorsten Renk wrote: > >> I'd really like the 3D cloud infrastructure to be used for all the > >> clouds, so > >> if there are features missing we should address them. > >> > >> Would it be possible to modify the 3D clouds so that they can be used for > >> the rain texture as well? For example, I could provide a sprite > >> distribution > >> on the surface of a cylinder rather than a sphere if that would help. > > > > Just a short answer to this part: All these objects (rain textures, Cirrus > > clouds,...) do not use the 3d cloud infrastructure because they are not 3d > > clouds. > > Thanks for the explanation. Doesn't look like there's much benefit from > hacking the 3D clouds system to do something it's not intended to. > > So... that leaves fixing the underlying problem. > > The problem definitely seems to be that any other objects in the scenery with > an alpha layer are rendered after the clouds, so are rendered in front of > them, > irrespective of the viewpoint and their relative positions. By > removing the alpha > layer from the texture of the stratosphere-tower in Las Vegas, I was > able to work > around the problem. > > Unfortunately, fixing this is going to require someone with more knowledge of > OSG than I have. The problem is that the 3D clouds are in an earlier > rendering bin > from the scenery models with transparent textures, which means that the > clouds > are rendered first in their entirety, and then the scenery models, with no > consideration of the relative position (i.e. depth) compare with the clouds. > This was done for perf reasons. Putting the clouds in the same rendering bin > (i.e. TRANSPARENT_BIN) halves the framerate on my system. > > I'm not sure there is a fix for this that doesn't massively impact > performance, unless > we add some of these objects to the CLOUDS_BIN and then depth-sort them within > the cloud code itself which depth-sorts slowly across multiple frames > to avoid exactly > the performance hit from depth sorting the entire TRANSPARENT_BIN in > each frame. > > Tim/Matthias - care to comment?
I've once applied a patch someone came up with that fixed a number of alpha blending problems but unfortunately can't find where it applied. In the mean time I found this: http://www.palomino3d.com/pal_com/openscenegraph/ Blending Blending in OSG is similar to OpenGL, with the addition of using OSG's transparent bin (essentially another rendering pass) for transparent primitives. // Enable blending, select transparent bin. stateSet->setMode( GL_BLEND, osg::StateAttribute::ON ); stateSet->setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); // Enable depth test so that an opaque polygon will occlude a transparent one behind it. stateSet->setMode( GL_DEPTH_TEST, osg::StateAttribute::ON ); // Conversely, disable writing to depth buffer so that // a transparent polygon will allow polygons behind it to shine thru. // OSG renders transparent polygons after opaque ones. osg::Depth* depth = new osg::Depth; depth->setWriteMask( false ); stateSet->setAttributeAndModes( depth, osg::StateAttribute::ON ); // Disable conflicting modes. stateSet->setMode( GL_LIGHTING, osg::StateAttribute::OFF ); Erik ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
