On 30 Dec 2012, at 08:55, Renk Thorsten <thorsten.i.r...@jyu.fi> wrote:
>> What's the a / b performance impact?
>
> <snip>
> 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).
Thank you for your response, it's extremely informative for me, as someone who
knows a bit about shaders, but has not written many 'real' ones. Everything you
describe makes sense, especially the tradeoff between 'real' lookups vs
procedural data. And the cost of always doing texture lookups, eugh.
We have to accept some inconsistencies if we want even vaguely tolerable
performance, and pretty much everything you said convinces me we should switch
to the 'b' approach, or family of them (see below), as the default option after
2.10, to get as much test and feedback as possible before 2.12. (But keep the
current 'a' terrain effects as a GUI option) If anyone during that time-frame
finds a serious area where the 'a' approach is better, there will hopefully be
time to address it, so that by the time 2.12 is code-frozen, the 'a' effects
can be removed (and the GUI switch).
How plausible does that sound?
> 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.
Indeed - what we'd really like (and what some other systems have) is a
pre-processors to adjust the shader body before compilation. So would could
#ifdef out certain pieces, but still have one shader codebase. Though I guess
we'd still need different effect files … hmmmm - not really feasible I guess.
I guess until there's some wider feedback and testing of the new effects, to
see if there are in fact any cases where the performance drop is unacceptable,
we don't know how many simplified variants are needed. Hopefully it's just one,
i.e 'full quality' and 'reduced quality'? Or at worst three - low, medium and
full? But that's still unpleasant to maintain :(
James
------------------------------------------------------------------------------
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
