> 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