I've spent four hours yesterday to trace down the cause for fog inconsistencies which I observed in custom terrain.
One of them was the fact that the top fog level was sometimes displaced by some offset from terrain chunk to terrain chunk in the new CORINE Italy scenery and the other is the fog pattern over the ocean. The first issue goes like this: I've been operating under the impression that for the purpose of rendering scenery, vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0); alt = ep.z; gives the correct altitude of the eye above MSL and terrain_alt = gl_Vertex.z; gives the altitude of the vertex and that comparing these altitudes against external uniforms (like the ground haze level or the snow level) gives correct results (the last assumption is coded in landmass.vert/frag for snow) - which usually does a good enough job. It turns out however this isn't correct in general - in the custom scenery, the altitudes computed that way were not above MSL but displaced scenery chunk by scenery chunk with a constant offset, so the same alt=500 condition in the shader meant 700 m MSL for one chunk of scenery but 850 m for an adjacent chunk, resulting in a discontinuity in fog (and snow) rendering across terrain seams. I don't know if this is a flaw in the custom scenery building process (I haven't seen the problem in default scenery yet) or not, in any case the terrain itself renders correctly, so the offset is known to ftransform(); but for the purpose of shader coding, it means we cannot assume to have know the proper MSL altitude scale inside the shader. The correct solution is to pass eye altitude (eye_alt) as a uniform, then the offset is given by offset = (ep.z - eye_alt); and the the true MSL altitude of the vertex is true_alt = gl_Vertex.z + offset; and this indeed deals with the discontinuities just fine. For testing purposes, I've implemented the eye altitude property to be passed as uniform from Nasal, but it should be done properly, hence: Do we have the eye altitude in meters in the tree in a property that is readable (= is continuously updated) by the shader, or alternatively, can we get it, i.e. the equivalent of var viewpos = geo.viewer_position(); var alt =viewpos.alt(); I believe all snow renderers should take that into account as well. The second problem is the 'checkerboard' appearance of fog rendering over ocean. To the limit of my ability to test, the cause is incorrect interpolation of distances and angles due to very large vertex spacing (I've asked the shader to plot step functions in angle and distance to see how the interpolation goes, and it had the expected outcome). Basically, when you approach a huge square directly from the side so that the closest distance is 1 unit and you see the two corners under 45 deg, then the distance to the corners is actually 1.414 units, and naturally the interpolator thinks that the distance is 1.414 units everywhere on the line even when actually it gets much closer - this is why fog seems to 'cling' to the middle of the line, because there the distance is overestimated. The default shader doesn't fog with true distance but with z-distance in eye space, which in the above situation pretends that the distance to the vertices is just 1 unit as well, which makes for homogeneous fogging along the line. But this leads to massive artefacts for larger FOV - at 90 deg FOV, the error in fogging at the edge of the screen already is 50%, at 120 deg the edges are done completely wrong. Moreover, the scheme doesn't work together with the two component calculations required by the terrain haze shader. To me, the only viable solution appears to be more vertices for ocean tiles, I don't think there are computational tricks which wouldn't be at least as bad under certain conditions - comparing with vertex density of normal terrain, even a factor 100 should be doable without problems. I vaguely remember that Vivian and Emilian had tried this and were negative, but I haven't really seen the outcome. I believe the results over terrain show conclusively that at some vertex density the problem goes away, and given that I can understand and explain all aspects of the problem I see, I think my analysis is correct. Cheers, * Thorsten ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
