Heiko wrote: > And especially in FGFS not really Vertices is one of the big problems, > but .xml's and nasal-scripts.
No, you can't say that in general. It quite depends on what you do and what options you use. Whatever you compute, it costs some amount of resource, and how long your frame takes is determined by the slowest element. I used to develop in a situation in which I was completely driven by the speed at which Nasal scripts executed, i.e. I saw quite drastically the effect of switching certain Nasal scripts on or off. Handing more and more work over to the GPU means that in general things speeded up and I now see the execution speed of the Nasal scripts no longer, but rather I am now completely driven by the speed at which the GPU can do the rendering, and I actually see improvements in framerate by handing computations elsewhere, e.g. to (to be slightly provocative) Nasal. Basically, you want a situation in which all available processing pipelines are equally filled for best performance. Also, if you notice vertex count or not is a question of visibility range. If you're happy with 16 km default visibility, then it's probably not an issue. I used to think 30 km is a hell of a lot, but after having seen how 120 km look from cruise altitude and actually start to compare with real life, I actually want something like 120 km if I can get it. And since terrain vertex count goes with the square of the visibility, this becomes the determining factor rather sooner than later, and scenery models factor into that in a major way. So you can also pretend it's my fault and I'm asking too much visibility range, while all others are happier with 16 km visibility range and hires high-vertex count models (which is probably better for helicopter people :-) ). But for instance, you told in the forum that you are running a lower than 1 value of cloud density because of performance reasons. Which means that you are seeing the impact of the 3dcloud vertex shader as limiting factor, not some Nasal or xml, because what the cloud density slider does is reduce cloudlet (=vertex) count. I guess my bottomline is that any code running on a per-frame basis should be made more efficient when it can be made more efficient, regardless if it is currently the limiting factor for someone or not, simply because it may be the limiting element for someone else. @Stuart: > That's very interesting. Do you have any suggestions for what > information we could push onto the fragment shader? I'm still not sure how well my experiences generalize, but the obvious thing to try bothering the fragment shader with would probably be the bottom and away side shading computation. It probably also depends on what other shaders are running - for me, my terrain-haze is the major player, followed by the 3dcloud whereas skydome uses far less resources. I don't know how the balance is changing if water or urban are on. If any of those makes use of the fragment part more heavily, then shifting more things into there might not be as good. Cheers, * Thorsten ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
