> 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
