> Geometry shader can also process adjacency information if provided by the
> CPU through special primitives (GL_TRIANGLES_ADJACENCY and
> GL_TRIANGLE_STRIP_ADJACENCY)

Oh, right - a geometry shader can probably receive a triangle as input, compute 
its center of gravity, shift all vertices outward by 5-10 m and return a 
slightly larger triangle to the vertex stage. I know very little about geometry 
shaders, but it'd be a nice reason to have a look.

So, a sketch for a (probably rather unsophisticated scheme):

* have a geometry shader make every triangle a little larger

-> in level terrain, we get then overlap of differently textured landclasses, 
and since we know how large we made the overlap region, we can later fade the 
textures in that region
-> in sloped terrain, we get artefacts as the enlarged triangles do not fit 
together properly, so

* at the vertex shading stage, we need to determine if the terrain is flat or 
not
-> if the terrain is flat, we use the overlap region to blend textures later
-> if the terrain is a bit sloped, we shrink the overlap region (i.e. we tell 
the fragment shader to fade to alpha much faster)
-> if the terrain is very sloped, we reduce it to zero

* at the fragment stage, we somehow tag fragments in the region where textures 
overlap and give them some alpha value
-> we end up with blended textures and (hopefullly manageable) artefacts

What's not clear to me is how we determine if a fragment is close to a triangle 
edge or not. Somehow this requires to compare uninterpolated vertex coordinates 
with interpolated vertex coordinates, but it's not clear to me how the 
uninterpolated coordinates can be passed to the fragment stage.

What's also not clear to me if this wouldultimately  fail due to z-fighting...

Also, this scheme would operate on *any* triangle, regardless if it is actually 
at the landclass boundary or not. I do believe its operation would not show 
when there is no landclass boundary as one blends same with same texture.

Feels somehow still... unsatisfactory.

> How about extending the BTG format to record for each vertex the distance
> to boundary (in tc unit). The terragear toolchain would compute it  
> offline
> and the runtime loader would convey that value to the shader as a vertex
> attribute. Distance for each fragment would be interpolated in a varying.

Well, yes - so then we know how far a fragment is from the boundary, but what 
we don't know is what the texture is I should blend into - so somehow we'd need 
to transport that, also allowing for edges in which n different textures 
meet... Ugly, ugly...

* Thorsten
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to