> First I get this when opening the shader settings dialog: > > Nasal runtime error: non-objects have no members > at $FG_ROOT/Nasal/props.nas, line 181 > called from: __dlg:shaders-lightfield, line 32 > > and the slider is off to the right, and can't be of much use.
Assuming that this is the shader GUI dialog, I have no memory of touching it and the merge request did not include any changes to the dialog - this must be some other problem (?) > Second, the "fast"(4) water lacks specularity, is this intended? Hm, could this be a dds problem again - the typical symptom is lack of specularity? I thought I had understood how the dds nature is communicated, but I might have messed this up. I see specular reflection with the shader. > Third, there are lawnmower/corn rows on the detail textures, I suspect > these > to come from texture fetching inside conditionals, but I might also be wrong. No, that's just plain old tiling of textures. One would have to optimize the detail overlay textures further to get completely rid of it, but I'm not really good in texture creation. I suspect some of your dds material would be rather good overlay textures, as they're very homogeneous and low tiling, just what one needs for the detail overlay. Texture fetching inside uniform int conditionals can't give you artefacts in a scene as far as I know. > Fourth, and I'm sorry to say this, but the (micro)stuttering is horrible > in high detail terrain, (just staying put and rotating the view), Would this be the stuttering that according to Vivian is Nasal related, of which I claimed all along that it's caused by the shader? :-) > I still think that doing heavy work in the vertex > shader won't cut it, it might give *you* a fps boost in corner cases, but the > > way that scenery is going it will only make matters worse in the long run... I have no clue about the way scenery is going. I think the optimal solution would be LOD levels on disk, so we have low vertex resolution at the horizon and relatively high vertex resolution nearby. You can try to shuffle more work to the fragment shader, but personally I'm not fond of flying with 5 fps, so I'm not going to do it (yes, I actually tried it...). It doesn't give me a boost in some corner cases, it makes the difference between unflyable 5 fps and usable 15 fps. I never intended the procedural texturing for use in custom scenery and I don't use it in custom scenery. All the newer aditions are optional - if they don't perform acceptable on you rmachine, then don't use them or use the bare atmospheric scattering scheme which hasn't changed, or switch trees off (they're pretty expensive for me). I'm frankly tired of 'This needs to be faster/smoother'. No, it doesn't. I'm not forcing anyone to use it, I put a lot of effort into cooking up ways to make it run faster, I don't work on things outside the rendering pipeline which determine smoothness, I'm bitching all the time about things like the instument panel should obscure terrain here on this list which I can't do myself, and the result is optimized as I can make it. I'm not the miracle man, sorry. It's simply not productive to point out that you'd like to have it faster and smoother - we all do, it's an open secret. * Thorsten ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
