> FIRST: I'm not criticing your work. Instead I really appreciate your > work, as you try to make things right! > But I criticise the way we handle new features. Due to this I can pretty > well understand Freds concerns about adding a simple switch for enabling > Rembrandt, which is a experimental feature as well. Keep it more or less > only available to them who does know what they do and understand that > there are still problems seems the better way sometimes.
I think Rembrandt being enabled by a commandline switch is a reasonable way to go. Also, the skydome shader in 2.6 would have been better in the debug section in my opinion. > If I remember right, in 2.6.0 the skydome shader was marked as > experimental. So of course that means that things doesn't work right, > and yes, and under some circumstances the shader didn't work properly. It never worked properly, in some conditions that was just less visible than in others. There was no single situation in which the horizon ever matched, only flying in valleys you'd never see it. > And so it is now. > But we changed a skydome shader with problems with another skydome > shader with other problems which needs to be fixed. No, it is not so now (at least for me that is, maybe there are problems with other cards/systems/... I'm not aware of). I get to see a seamless and plausible match between sky and terrain from ground level to low Earth orbit, at all times of the day and under any weather condition. Scenery and models are now rendered correctly with the sky at all locations and all times. Not having a particular extra effect available is not the same as having a graphical artefact in the scene, and I refuse to treat the two on the same level. The first is a missing feature, the second is a bug. There are those of us who do not enable all available shaders even in the default scheme and don't miss features. There are even those who use Flightgear without shaders. If airplane X requires a shader to work at night or under some conditions, then the problem is with airplane X because at least as far as I am aware the development philosophy is that Flightgear should still run under pure CPU rendering conditions. >From my perspective, there is nothing that 'needs to' be fixed. Bugs need to >be fixed, not missing features. Sky and terrain render seamless everywhere at >all times no matter the weather. There is just a lot of features that can be >added. For information, my priority list is very much focused on looking out of the cockpit and seeing the scenery. So my plans are to write a low-impact water shader which colors the water correctly based on the environment conditions but doesn't do wave reflection computations so we have some environment sensitiity of water for not so powerful systems. Then I plan to work on the random vegetation, then probably the urban shader. Landmass relief doesn't run on my box at all, so somebody else has to do that one. I'm still thinking of how I could make Emilian's original idea to factor light and fog computations out and just use include files, but in the schemes I could come up with we'd be losing 30-50% performance because redundant operations are performed - help appreciated. External views is not something I am particularly interested in, so it's rather low on my priority list, but if someone else wants to have a go at the ubershader, I'm here to help and can explain what needs to be done. > But from users view it is difficult to understand, as we already could > see (I was not the only one who did not understand the whole thing). > That's why I hoped we can get something like a compromise and that's why > I came up here with. I've really been sleeping over this. Consider this different story: You've been working for a few month on a really high quality 3d model of a plane, beautifully textured. To be able to test it, you create a very simple, bad and unrealistic YaSim model, and it so happens that a release is imminent, so the YaSim model gets into the release. Now, you spend the next six month replacing that simplistic model by a very detailed JSBSim model for which you dig out all the tables from the manufacturer and patiently test it many hours against performance tables. Before the next release, someone comes complaining: Hey, the XXX is now so difficult to fly! It used to be such a cool plane, you could land on a skyscraper and it wouldn't even take any fuel, this was so fun to use and now I can't even get it off the runway! Can't we keep the old version? So, would you optionally include the YaSim FDM because someone thinks it was cool and misses it? I would not. I personally want to deliver proper work and would like to remove features I know to be bad and obsolete. That has a personal comopnent - I have to be happy with what I have done - but it also has a practical component, because I am to some degree being identified with my work, and so I get to deal with the questions which arise. I think I understand the skydome problem quite well. There are two things meeting up: First, it was imo a mistake to include the skydome shader into the rendering dialog rather than into debug. Second, it is terribly difficult to grasp what the problem is. The horizon is for most of us something which is just there, nobody pays much attention as long as it looks plausible. In actual reality, I have on my desk about 20 pages of light scattering equations which tell me how the horizon looks under various conditions. The horizon region is much more difficult to compute than the rest of the scene (Earth curvature starts to matter, thus the atmosphere may or may not become optically thick, light paths become terrain-elevation dependent for low sun,...). The combination of the two things is that everyone thinks there is a skydome shader which just needs a bit of tinkering, and there is the atmospheric scattering which has a lot of extra options, so you can separate the two if you don't need the extra options. Not true. The haze layer is needed because the atmosphere may get optically thick, so the skydome shader has to include the option. Once you have it, you can use it for volumetric fog, but that's not why is needs to be there. Lightfields you need because the skydome knows about different lighting in different places. Once you have them, again you can do interesting things, but that's not why they need to be there. There are in actual fact very few extra options which are not needed for a seamless horizon - the density ripples in the fog, or the dust cover. Basically, with low shader slider quality you get the minimal bug-free setup, with higher shader options you get the extras. To say it very bluntly: To make a skydome only option available is to re-introduce a bug which I have spent a lot of time and effort to eliminate. The fact that under some situations you can hide the bug and make cool screenshots and videos shouldn't factor in - advertizing Flightgear with screenshots and videos in which the fact that the horizon is jarringly wrong is hidden is fundamentally somewhat dishonest - you imply that the user could expect to see what he sees in the videos whereas in actual reality he is going to see visual artefacts at the horizon most of the time. It's better not to advertize a feature at all rather than to be dishonest about what is going on in my opionion. Originally I started this thread asking for help how to communicate all this best. It seems we've introduced a regression here as well. * 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
