Hi Thorsten,
As of my last rendering dialog update, atmospheric scattering shader options
are "invisible" when Rembrandt is enabled. We could apply that same scheme to
all the other effects...
But I sort of lost track of what effects do work and what do not. The water
shader for example looked better than ever with Rembrandt enabled, until Fred
told me it wasn't supposed to and I found out that it only looks okay at
certain times of day...
So.if.someone.could.setup.a list of effect(combination)s that don't work, I can
try to construct something.
Cheers,
Gijs
> From: thorsten.i.r...@jyu.fi
> To: flightgear-devel@lists.sourceforge.net
> Date: Tue, 19 Jun 2012 09:23:09 +0000
> Subject: [Flightgear-devel] Shader menu structure
>
> > Anyway, just reporting what I see, but I am sure other
> > users must get VERY confused by such strange - it works,
> > then it does not work - behavior... but I suppose when
> > it is all documented the sun will shine, and shadows
> > cast...
>
> Indeed. Forum reports suggest that users do get confused. So what do we do?
>
> The problem: A shader for object X isn't an independent entity which you can
> switch on and off at your leisure independent of what else is going on - it
> needs to share the fogging and lighting scheme of the rest of the scene,
> otherwise it creates visual artefacts. At the moment, we have three such
> schemes:
>
> a) default in which the light is always the sunlight and the fog is always
> exp(-(const * length/vis)**2)
>
> b) Rembrandt in which the light can come from multiple sources and sunlight
> may be blocked by a shadow, fog remains as is
>
> c) Lightfields in which the sunlight is the only light source but at dusk or
> dawn becomes a function of position in the scene and in which the fog has a
> more complicated 2 component structure
>
> Each of the schemes has a justification to be there in terms of features vs.
> performance. Making a shader of one scheme work in a different scheme is a
> non-trivial exercise, in the case of water reflection shader into lightfields
> it cost me about half a week of really good coding time (kids with
> grandparents). So we simply don't have all shaders in all schemes, and I
> don't even know if all would run with enough fps in all schemes.
>
> How to present it to the user?
>
> I don't know off-hand how Rembrandt handles non-Rembrandt shaders. In the
> lightfield scheme, the first solution was to let the user do the
> configuration, i.e. when the main selector (skydome/atmospheric scattering)
> was checked, all other special shaders continued to work, leading to really
> bad visual artefacts and a couple of bug reports. No good.
>
> The current solution involves overrides - the lightfield scheme declares
> before the default scheme, and as a result when lightfields are on, the
> shader configuration menu in essence changes function and switches higher
> detail shaders on only if implemented, whereas sliders do nothing if the
> corresponding shader isn't implemented. That's a good solution insofar as it
> largely prevents users from creating visual mismatches between schemes, but
> leads to complaints that 'shader X doesn't work when atmospheric light
> scattering is on'. So, still not good enough and creating confusion.
>
> *The* solution is of course to make all shaders work in all schemes.
> Certainly not for 2.8, that would be my 3.0 idea as stated elsewhere.
>
> In the meantime, what would be the best way to make it clear in the GUI that
> Rembrandt and lightfields are genuinely different lighting schemes and come
> with their own set of shaders? Should there simply be text in the GUI? Should
> there be an on-screen message printed? Should the GUI change in some way and
> present only the actually existing options dependent on scheme?
>
> Please give some feedback - how can we communicate better what is happening
> and why there are limitations?
>
> * Thorsten
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
