> What's the a / b performance impact? All to be taken with some caution, since it seems to be very hardware dependent how expensive certain options are. For my new GTX 670M, I can't measure performance without external tools because any terrain is always rendered with vsync of 60 fps, and only the presence/absence of cloud layers in the scene decides my in-sim framerate. All performance benchmarks I have done are thus with my old 8600M.
Here, the classic suite of effects had some incredibly expensive candidates - landmass drove me consistently from 50 to ~10 fps, so I never used it. I think there's a geometry shader somewhere... Apart from that, I'd say that the costs of a) and b) are approximately comparable (which might look a bit surprising at first). For instance, in the classic effects, snow is done loading a noise and a snow texture. On the 8600M, a texture2D() lookup was very expensive, each taking about 10% of the base framerate. On this machine, creating snow procedurally (i.e. doing noise and texel by function rather than texture) is about twice as fast than in the classic scheme by texture. Also, a texture _has_ to be loaded regardless if you actually need it for a pixel or not, so you pay the price for looking up the snow texture regardless if you have any snow in the scene or not. A function can be evaluated conditionally, i.e. you pay only if you actually have snow in the scene - you can condition on a trivial snow pixel 500 m below the snowline. So despite the fact that the procedural snow offers more options (non-tiling distribution, user-controlled layer thickness) it turns out to be slightly faster than the classic option even in completely snow-covered scenes. Similarly, the terrain roughness is based on a very cheap technique creating an optical illusion rather than a proper heightmap (which is probably ~50 times faster than the detailed heightmap technique used for the urban effect) - so it allows to get a lot more bang for the buck provided you're willing to overlook the occasional inconsistency (this is a bit like with the 3d clouds - if you try really hard, you can see them rotate and deduce how it's done - but you have to go looking for it, it won't jump out). > From you screen shots it seems like > it ought to be scalable, since we could enable certain aspects (grain, > bump-mapping) based on a performance / quality slider, while still > having a single approach. Well, yes, in theory... In practice, you may be forced to create a different effect and shade fordifferent quality settings. if() statements inside shader code are very tricky - you might easily end up evaluating both branches. For instance, in theory (=according to the specification) texture lookup can be conditional on uniforms. In practice, on my box I found that this works only for uniform int, not for uniform float - for an uniform float, always both branches were evaluated. I have also no idea how, say, Radeon drivers respond to the same design - they may have a completely different strategy evaluating branches... Which means in practice, you get to see the lower quality as indicated by the slider, but the framerate isn't any better than with high quality. So you can not easily design a shader which takes quality levels from the gui and just enables what you like - if you're careful in designing it, it works up to a point, but eventually no longer. There's a reason why terrain-haze.frag, terrain-haze-detailed.frag and terrain-haze-ultra.frag are different files... So this has to be designed carefully up-front. * Thorsten ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
