Hi, On Wednesday, December 07, 2011 23:05:06 Stuart Buchanan wrote: > 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.
Still just a quick look from my side: The cloud code changes its internal data structures in the draw call? Or are these lists per context data structures? This is kind of proboblematic for two reasons: 1. draw happens in paralell in all configured multi viewer contexts. So I fear concurrent modifications on a shared datastructure. 2. The eyepoint on different cameras can be different which might give different results in sorting I guess? While the second point might not happen in current flightgear implementations, I still think that we should try to keep this in mind. And, more performance related. I see that single quad that is used to draw the clouds. Then we have this loop over all the sprites. So what the driver does is on every new quad there is a new geometry setup that happens. And this is one of the expensive things in a driver. Mostly this is the best optimized code path since this happens often, but still it is relatively much work on the CPU to teach the GPU that there is a new bunch of geometry to render. A rule of thumb that really depends on the kind of shaders that are used and how much fragments are renderd, but for our average models, including the clouds I think, It will take about the same time to render one quad or a single bunch of 1000 quads. It's just the GPU is so fast and the geometry setup on the CPU dominates. So having a huger array of vertex attributes done with one draw command consisting of only one osg::PrimitiveSet could improove rendering speeds. Sure this needs some more infrastructure to change this at the right time in the frame. Also this is concurrent with the depth sorting we have discussed before. So the question is what is the right compromise then? Having relatively huge bunches of geometry helps rendering and osg's sorting speed. But huge bunches might give problems with the sort order blending in the wrong order. Which is BTW the kind of artefact that somebody pointed out on a recent X-Plane screenshot. So we are currently better, but still, we need to get back to 'real time' ... How much ShaderGeometry's do we have? One per cloud? For me this also raises the question of reproducible clouds. If we have multiple independent viewers in the future, we need to draw the same clouds on each with a bare minimum of communication. So, what is needed to generate the exactly same cloud. May be an initial seed for the random number generator, a position and a size? We may need to identify such a set of parameters and may be we should have a peudo loader for osg producing this kind of clouds from these parameters. The you would be able to load and use these clouds from fgviewer and see isolated statistics about the draw/cull whatever steps. This might also help in understanding what is going on. Also Integrating this all with atmospheric scattering would be nice. I guess we really need to move the clouds into a post processing step doing all the athmospheric computations. But that also raises the idea of having the scattering at a completely different place which should improove maintainability and execution speed ... > 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. Ok, Don't know off hand. But at least we have no state change in between the distinct quads. > 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? Well, kind of yes. Sorting happens due to depth but there is no state change at all. Which is good. > We already use array textures so we have multiple different textures in a > single image file. Is that what you mean? Yes. Good! > 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. Thanks for your work in doing this all! If I do not respond to list mails when you need some response, fell free to contact me directly. I just miss some mails every now and then ... 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
