Can tessellation happen post-transform?

Mat3

Newcomer
In the R600.. I know it does its work before transformation, but it would be possible (at least in theory) to design it so that it could work on post-transformed polygons too, right?

Edit: Geometry shaders can also do tessellation, and aren't they done further down the pipe than vertex shaders?
 
In principle tessellation can happen in any space, though pre- and post-projection tessellation are different. Since it can change the shape of objects, some form of clipping should take place after it.
 
Thanks.. since it's possible, I have a couple other questions...

If you tessellate after, wouldn't there be the advantage of not transforming a bunch of small back facing triangles that end up being discarded?

Also, would it work for a TBDR to reduce the memory constraints of the display list? The display list would store the simple models and then tessellation would happen after once the final scene was ready for rendering.
 
Back face culling before tesselation might seem like a good idea, but it may cause problems. Back facing triangles may be curved enough by the tesselation that after tesselating parts of them are actually front facing. The shape of the objects then will change depending on the viewing angle which isn't what you'll want. Bits will pop in and out.
 
Don't know why but i get that feeling about Tesselator thingie... like it will end up just like TruForm. Wonderful on paper, few games will use it and then they'll ditch it from the drivers.
 
Back face culling before tesselation might seem like a good idea, but it may cause problems. .
Surely it would only cause problems if you did it incorrectly. Of course, doing it with the curved surfaces would mean you would have to be conservative with your culling, but I think I've seen a paper describing it.
 
Back face culling before tesselation might seem like a good idea, but it may cause problems. Back facing triangles may be curved enough by the tesselation that after tesselating parts of them are actually front facing. The shape of the objects then will change depending on the viewing angle which isn't what you'll want. Bits will pop in and out.
Instead of having one face normal, you have three normals at the vertices. If all three face away from the camera, none of the tesselated faces are visible.
 
depends on the method u use to decide how to tessellate, if its pure subdivision then yes.
but ill think if u wanna use tessellation u would want a texture as input, displacement, thus the resulting faces could face in any direction
 
depends on the method u use to decide how to tessellate, if its pure subdivision then yes.
but ill think if u wanna use tessellation u would want a texture as input, displacement, thus the resulting faces could face in any direction
Well, it would make things more challenging, but given that there must be an upper bound on the distance each vertex is displaced, it would still be feasible to do some early culling....but I don't fancy working out the maths :)
 
It's worth baring in mind that having the GS after the VS in the pipeline has no requirement on it being pre- or post- transformed data. You can just implement as pass-through VS and do all the transformation in the GS. A bit pointless and inefficient, but perfectly legal.

The R600's dedicated tesselator always struck me as an oddity for current generation (current now including D3D10). Either it's some clever optimization (which wouldn't mean it's a feature we directly use as such) or it's a place-holder for some future work - what I've seen of future directions with D3D it could fit very nicely.

Jack
 
Back
Top