> De: "Renk Thorsten" <thorsten.i.r...@jyu.fi>
> 
> > 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)
> artifacts
> 
> 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 would ultimately  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...

First, from your sketch, I think you misunderstood where the gs fit.
In fact it operates on the result of the vertex shader, and its output 
is directly rasterized to the fragment shader. But you can have a null 
vertex shader (that do nothing except outputting its input) and do the 
vertex work in the gs as you can have all the vertices of the primitive 
in the same function. But currently the gs is not able to tell if the 
edge of the current triangle processed is convex or concave, because it 
has no idea of the 3 adjacent triangles.

The geometry shader specification adds new primitives with adjacency. See 
http://web.engr.oregonstate.edu/~mjb/cs519/Handouts/geometry_shaders.6pp.pdf
(6th slide). That can be used to generate silhouettes if the normals don't 
point to the same direction. But that would require to modify the C++ code 
in order to push the adjacency information to the GPU.

By the way, as a gs is able to create geometry, instead of expanding a single 
triangle, you can output the original triangle and a flat boundary around it 
using 3 quads (in fact 6 additional triangles).

Combined with adjacency information, that way there would be no extra geometry 
for the edge shared by 2 triangles of the same landmass and only one when 
landmass
differs.

Anyway, I don't thing the using geometry shader without adjacency info is 
satisfactory for the reason you already exposed (z-fighting, hairy surface, etc)

Regards,
-Fred

------------------------------------------------------------------------------
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