Which edge is which when tessellating?

Started by
5 comments, last by Jason Z 10 years, 12 months ago

Ok, so I have 10 control points for a 3 order bezier triangle. It is arbitrary which points are which, I know who they are and how to use them, but there is no obvious relation to these points from the edges to tessellate. In my hull shader, I decide how much to tessellate each of the three edges, but how do I know which edge is edge zero, one, two etc?

For example, if cp[0], cp[1] and cp[2] are the control points to my bezier triangle corners, how do I decide how much to tessellate each edge based on the screen size of the edge?

Advertisement

You know the orientation of the control points relative to one another, and you know the world transformation that they are being transformed with, so you should have the information that you need. If you are currently doing the transformation in the domain shader, then you may have to move that back to the hull shader. Then you can transform each control point, and then using whatever metric you want you can adjust the tessellation accordingly.

In general this is better than doing the transformation in the domain shader, since it is running after the amplification from tessellation. Always try to push the computation upstream if possible!

Here is my current hull shader:


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

	pt.EdgeTess[0] = 6;
	pt.EdgeTess[1] = 6;
	pt.EdgeTess[2] = 6;
	pt.InsideTess = 6;

	return pt;
}

How do I know which cp's are associated with pt.EdgeTess[0]? I have to make sure that shared edges are tessellated the same way. My shader pipeline currently supports two forms of triangle input sets, one pointing up and the other pointing down. After translating them with my matrices, they could be oriented any old way. If one of my edges on my triangle is short on the screen, how do I know which element in the EdgeTess array to decrease?

In general this is better than doing the transformation in the domain shader, since it is running after the amplification from tessellation. Always try to push the computation upstream if possible!

In my case, the domain shader is calculating patch surface normals according to world space. If transform my control points to screen space in the hull shader, I wouldn't be able to calculate normals any more, because at that point all the geometry is co-planar correct?

Ok, I have discovered that by setting one of my tessellation factors to 3, I can find out by visual experimentation which edge is which. It appears to be a stable association that is NOT dependent on the view space. In my case, the edge from cp[0] to cp[1] is edge index 2, edge cp[1] to cp[2] is edge index 0 and edge cp[2] to cp[0] is edge index 1. In my case, they also seem to line up by accident so I don't have to worry about mismatched shared edges.

Strange. Is there any way to predict this without experimentation? There must be some rule it would seem.

It's fixed, and your result looks correct. edgen is opposite to vertexn. Haven't found that in the docs, only in this paper, page 4. Don't ask me about quad domains, haven't tried that.

Here is my current hull shader:


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

	pt.EdgeTess[0] = 6;
	pt.EdgeTess[1] = 6;
	pt.EdgeTess[2] = 6;
	pt.InsideTess = 6;

	return pt;
}

How do I know which cp's are associated with pt.EdgeTess[0]? I have to make sure that shared edges are tessellated the same way. My shader pipeline currently supports two forms of triangle input sets, one pointing up and the other pointing down. After translating them with my matrices, they could be oriented any old way. If one of my edges on my triangle is short on the screen, how do I know which element in the EdgeTess array to decrease?

It actually doesn't matter (I know - that isn't intuitive...). As long as neighboring patches share the same control points, and the control point to tessellation factor algorithm will produce the same output for the given input control points, then the order doesn't make any difference.

But for the same reason you are having trouble to understand it, it would be impossible to have a standard notation to say which control point goes where since it depends on the primitive topology, the number of control points, and so on. I believe there is a way to identify where a control point is located within a control patch, but I don't think there is one for the oriented control patches.

This topic is closed to new replies.

Advertisement