Followers 0

# How much to tessellate?

## 31 posts in this topic

HexVertTri_HS.fx(1,1): error X3000: Illegal character in shader file

Ah well, the compiler still can't cope with unicode source. At least it should give a more meaningful error. You need a file in pure ASCII/ANSI, e.g. a text file created in Visual Studio will be UTF-8 encoded, which starts with the so-called BOM-char, which in turn makes fxc hiccup. Use an alternative text editor (Notepad++) or copy a file that works and clear it (VS will usually not screw that at least).

Nice to hear it's working.

1

##### Share on other sites

Ok, I have that squared away and I'm back in business! My algorithm works great, I just have to tweak it so that both low detail and high detail aren't so quick to appear. I can handle that.

After this I'll need to see some performance info of some kind, so I need to print text. I'll open a new thread for that. My research on that topic has given me some conflicting info.

Nice job sticking to it - so where is the obligatory screen shot showing us the low and high res triangles all at once???

1

##### Share on other sites

Nice job sticking to it - so where is the obligatory screen shot showing us the low and high res triangles all at once???

Alrighty then. I'm actually still futzing with the LOD settings, but I do have an interesting discovery. Here is the new code, I tried to do some culling of the backward triangle patches, but in this case the surface can protrude too much and the gaps are visible. I also tried to greatly reduce the tessellation in that case, but the popping was very noticeable.

PatchConstants PatchHS(InputPatch<VertexOutput,10> cp, uint patchID : SV_PrimitiveID)
{
PatchConstants pt;

float4 corner0 = mul(float4(cp[0].PositionWorld,1.0f),ViewProjection);
float4 corner1 = mul(float4(cp[1].PositionWorld,1.0f),ViewProjection);
float4 corner2 = mul(float4(cp[2].PositionWorld,1.0f),ViewProjection);

corner0 = corner0/(corner0.w + 0.00001f);
corner1 = corner1/(corner1.w + 0.00001f);
corner2 = corner2/(corner2.w + 0.00001f);

static const float dMax = 1.5f;
static const float dMin = 0.04f;

float dist0 = distance(corner1.xy,corner2.xy);
float dist1 = distance(corner2.xy,corner0.xy);
float dist2 = distance(corner0.xy,corner1.xy);

pt.EdgeTess[0] = 64.0f * saturate((dist0 + dMin)/(dMax + dMin));

pt.EdgeTess[1] = 64.0f * saturate((dist1 + dMin)/(dMax + dMin));

pt.EdgeTess[2] = 64.0f * saturate((dist2 + dMin)/(dMax + dMin));

pt.InsideTess = min(pt.EdgeTess[0],min(pt.EdgeTess[1],pt.EdgeTess[2]));

//corner0.z = 0.0f;
//corner1.z = 0.0f;
//corner2.z = 0.0f;

//float3 winding = cross(corner1 - corner0,corner2 - corner0);
//if(winding.z > 0)
//{
//	pt.InsideTess = 1.0f;
//}

return pt;
}


Here is the interesting part. I originally chose 'fractional_even' arbitrarily. Switching to 'fractional_odd' can completely change the look of the scene. First is the view from central Taffy Mountain looking west with fractional even partitioning:

[attachment=15270:CTLookingWestEven.jpg]

Now the from the same vantage with fractional odd partitioning:

[attachment=15271:CTLookingWestOdd.jpg]

At least in this particular case, I would say that fractional odd has far fewer undesireable artifacts! It's an interesting consequence.

1

##### Share on other sites
Taffy Mountains. Sweet.

Interesting, now I finally get it with that odd/even difference. Seems like even always has some tesselation, since it "starts" at the edges center. See here.

fractional_even with 1.2 for all factors

fractional_odd with 1.2 for all factors

(Oops, should have used a lower resolution, the thumbnails came out black, sorry)

With even, the higher tesselation starts only with factors > 2 it seems. So for your plateaus a odd makes more sense. Shouldn't make a difference with very high tesselation, though.

Backface culling ? You need to give it some bias and you can actually eliminate the patch completely (so it doesn't get rasterized at all) by setting the factors to zero:
// view: view direction from camera to patch
if(dot(view, faceNormal) < - BackfaceCullBias)
{
pt.EdgeTess[0] = 0;
pt.EdgeTess[1] = 0;
pt.EdgeTess[2] = 0;
pt.InsideTess  = 0;
return pt;
}

Here I use a (experimental) bias of 0.3. See how the top of the "cube" still gets rasterized.

The same with a sphere:

Not sure if this of use for your case, but this "Fresnel term" ([tt]dot(view, normal)[/tt]) can also be used to adaptively tesselate a mesh's contour:

PS: The distance based factors are deliberately exaggerated here, so I can check the behaviour better.

Edit: Pfff, I got the odd/even mixed up with the triangle. Corrected. Edited by unbird
1

##### Share on other sites

With even, the higher tesselation starts only with factors > 2 it seems. So for your plateaus a odd makes more sense. Shouldn't make a difference with very high tesselation, though.

That's actually the definition of the even/odd partitioning modes.  Even rounds to even factors while odd rounds to odd factors.  So for even, you end up with a factor in the 2, 4, 6, 8, ..., 64 range, while for odd you get 1, 3, 5, ..., 63.  If you take this into account when designing the algorithm that produces the tessellation factors, then you will be in good shape and can set the minimums accordingly to ensure you get at least a little bit of tessellation.

The same can be said for the other two types (integer and pow2) as they just define the "steps" in your tessellation factors.

2

##### Share on other sites

The problem with fractional_even is that you get a very tight mass of triangles mid edge, and very large triangles in the corners. Obviously this has potential for artifacts. With fractional_odd this difference is much less pronounced. I'm not sure where anyone would ever want to use fractional_even unless you had very specific topology that benefitted from that imbalance somehow. Here are some wireframe results:

fractional_even:

[attachment=15320:PartitioningEven.jpg]

fractional_odd:

[attachment=15321:PartitioningOdd.jpg]

0

##### Share on other sites

Backface culling ? You need to give it some bias and you can actually eliminate the patch completely (so it doesn't get rasterized at all) by setting the factors to zero:

This works great for me unbird. Thanks for the tip! I have to set my bias kinda high, but I'm still getting rid of enough patches for a noticible frame rate boost.

0

## Create an account

Register a new account