Hi, 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.
On Monday, December 05, 2011 09:26:09 thorsten.i.r...@jyu.fi wrote: > Since according to the newsletter Stuart's current ongoing quest is to get > better performance for 3d clouds, here are some of my observation: > > * I've noticed that when I use the relatively lowres Altocumulus texture > sheet (3x3 on one sheet) I can basically use a ridiculous number of > sprites without performance deterioration, whereas when I use the hires > Cumulus sheets (1x2 plus 1x3) the number of sprites I can show before > performance takes a nosedive goes down substantially. > > The high resolution is however only needed for the small amount of clouds > which are relatively close, but what makes a real difference is the amount > of distant clouds, because there are so much more. So my guess is that > using lowres textures for distant clouds would do just fine and improve > performance. I've been wondering if dds sheets with the mipmaps would not > automatically address that problem. > > The other option to test would be to scale down the resolution of the Cu > cloud textures and see if the result is still acceptable (I know it isn't > perfect, there was a reason I went to high resolution in the first place, > but maybe the flaws can be hidden by the right mixture with other texture > types). I assume that you have a few textures that is used very often? Or do these textures really have a different content? 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. > * There seems still to be stuff computed in the shaders per vertex that is > actually an uniform per frame - eyepos for instance. I wonder if the > computations could be speeded up significantly by consequently pulling > all things that are really uniforms out of the shaders. While it is always better to do as little things as possible in an inner loop, but in this case: It really does not matter at all for a GPU. The geometry setup, which wires together the shaders from the different stages and connects uniforms is about the same amount of CPU work in the driver if you connect an external uniform or if you connect a varying from the vertex stage. It is getting complicated for the driver once you hit the maximum number if varyings for a hardware. May be some other corner cases also ... The work that the vertex shader does is really minimal. You would probably be able to mesure this effect when you have *huge* amounts of vertices. But huge means in the order of 1e6-1e8 vertices what you can get in CAD tools. 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. May be you can also look into osg's fast geometry. If you use index arrays in osg, the draw stage will resort to glVertex3f calls which is slow in any driver. Make sure that the geometry is drawn by glDrawElements and the like. Greetings Mathias ------------------------------------------------------------------------------ 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
