2011/12/6 Mathias Fröhlich wrote: > As usual, I did not take the time to really look into the code. So please > excuse more or less obvious questions about the current implementation.
The relevant code is newcloud.[c|h]xx and CloudShaderGeometry.[c|h]xx in simgear/scene/sky/ It's entirely possible that there are some inefficiencies there. The only people who have done anything with it are Tim and myself, and I'm certainly not a good graphics programmer. > I assume that you have a few textures that is used very often? > Or do these textures really have a different content? For the global clouds we typically use a single texture for all the clouds in the layer, and there are usually between 1 and 3 layers. > If they are the same content wise, you can help at first osg and then also the > GL driver if these are also the same on osg level. That means the > osg::Texture* state attribute must be the same for all uses of the same > texture picture. > > May be you already know this, but the description pretty much sounds like an > effect originating from this. We use the Effects code to pick up the Texture (see newcloud.cxx line 108). I guess it's possible that is not doing the right thing. <snip> > Really what matters much more are state changes and geometry setup. > I still assume that you have very small bunches of geometry that the clouds > are made of. This really hurts both osg and the driver. > Sure to get transparency right they must be distinct. But I guess the problem > to be solved is how to get maximum sized bunches of geometry with as little > state changes as possible ahd still have the transparency right ... > > For osg this means that there must be relatively huge atomic > Geometry/PrimitiveSets that are probably pre sorted to order the draw in the > depth. Probably an octree like structure holding the cloud subscene helps > here. We sort all the sprites within a cloud to minimize the state changes, and then use heuristics to minimize the amount of re-sorting (see CloudShaderGeometry.cxx line 97 Is that what you mean? > There is also a technicque called 'pre integration' available for clouds. I'll look into this. > Together I still think that the amount of draws and state changes must be cut > down. > In terms of state changes, an exact depth sorted draw order causes may be a > huge amount of texture state changes. May be it is possible to collapse the > different textures into one and pick out the appropriate subrange of the > texture? May be an array texture, may be a 3d texture with different layers in > each discrete z dimension? We already use array textures so we have multiple different textures in a single image file. Is that what you mean? Thanks very much for the explanations - very useful as always. If you have the time to take a look at the code and see if there are any really obvious mistakes, I would be very grateful. -Stuart ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
