2011/12/8 Mathias Fröhlich wrote: > 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.
Good point, and one I'd not thought about before. > 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' ... So it sounds like I should create a single geometry per cloud, rather than per-sprite? If I'm doing that I might as well scale the geometry when I create it, rather than relying on the shader to do so for me. The major problem I can see with this is performing the billboard rotation. To do that in the vertex shader, I'll need to pass in the center of each sprite. However, I wonder if I can make this more efficient by doing it outside of the shader, and a) performing the same rotation on each sprite within the cloud b) only performing rotation when required, rather than per-frame. Presumably I could retain the manual sorting we do at present, and simply sort the geometry itself. Or is that better left to OSG? In fact, this may remove most of the function from the shader itself! > 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? I need to check, but I'm fairly sure we use an initial seed already. > 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. We already have export/import methods, though I've never used them in anger! Certainly using fgviewer would be an excellent idea. > 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 ... Thanks for the offer. Will do. -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
