[Flightgear-devel] Removing landclass seams

[Renk T. <tho...@jy...>]

> By the way, do you know this book ?
> http://books.google.fr/books/about/Texturing_and_Modeling.html?id=bDlSJd8GfMcC&redir_esc=y

No, I don't. I have never read much about scenery texturing. (I mostly make it up as I go - my greatest wish would anyway be an artist and a decent database to extract GPL compatible textures from - I often have an idea what I want to have in a texture but am unable to get it).

After spending three hours to think about the landclass problem, I can appreciate the allure of photo-texturing or complete procedural generation without reference to geodata much better.

* Expanding triangles has been discussed and probably leads to issues.

* Just passing distance to a boundary doesn't do the trick, because we don't know what texture we would want to fade into. Even if we somehow manage to set a sampler2D to point to the texture we want to fade into, it only works for the basic scheme, but discontinuities remain in the overlay textures. In order to fix those, we need additional textures, which is a performance drain, but even so, I think we can only have 8 or so.

* Can things be fixed after the fact by somehow blurring boundaries? This would require first rendering the terrain texture as composite but projected vertically rather than into eye space, then post-process the seams with a filter. Sounds like a Rembrandt task, except that I don't know if it's feasible at all, how to tell the filter where the seams are and if the whole thing is anywhere efficient.

Problems not touched so far are that some of the seams are actually sort of acceptable (agriculture has pretty sharp boundaries, streets certainly do), some of them would have a completely different nature when smoothed properly (urban would fade into the surroundings by distinct chunks of houses which grow further and further apart, not by a blending) and some of them are rather one-sided (the terrain/water interface would affect the terrain side much more than the water side).

So what we would need is a function which can be evaluated for any coordinate point in the shader which returns where the seams are and what the nature of the landclass boundary is, so that the shader can target the smoothing strategy accordingly.

* One way to construct this would be to use the geodata as a guidance field for a complete procedural texturing approach in which almost  _all_ seams would be generated by the shader. Say each vertex gets an attribute describing the texture mix at this position. Assume we use 16 base textures for the terrain - since the mixing fraction must be [0-1] and doesn't need great precision, we can use a single number to encode multiple textures, for instance 55.0 could stand for 0.5 texture1, 0.5 texture2, 0.0 texture3. A vertex at a seam between two landclasses woud get a fraction of 0.5 each, a vertex between four a faction of 0.25 each, and so on. We'd need a manageable number of attributes.

The mixing fractions would then be parsed and decoded in the vertex shader and converted to varyings, so the fragment shader knows for each point the bare mixing fraction of any of the 16 basic texture types. Based on the texture channel, the fragment shader can then filter the mixing fraction and decide how to actually mix the assoicated textures, accounting for the different boundary types.

A palette of 16 standard terrain textures can be stored in a single 2048x2048 texture sheet and referenced with a multi-texture coordinate, so we don't necessarily run out of texture units. A similar palette of overlay textures for all landclasses can be stored.

This would make regionalization quite a bit more complicated, as we'd need a new palette when we change the region, but the problem could be partially softened by allowing color multipliers for the base texture, so the region can simply define 'take the standard palette forest texture, but multiply with (1.2, 0.9,0.7)' .

Which reminds me - is there a performance penalty for using many uniforms? My impression is not, at least I've never seen any, but it'd be good to have this confirmed. Also, can be declare uniform vec 3 in the effect files, and if so, what is the syntax?

The end result would be a seamless terrain texturing scheme in which the distribution of textures roughly follow the geodata, but not exactly - noise would blur the boundaries and bits of other landclass texture might intrude into any given landclass. It'd just be a completely new scheme, incompatible with basically anything we do right now...

I'm fairly sure this would work, but we'd be limited to 16 distinct landclasses in any given region, and it'd be a hell of work to implement this... 

* Thorsten