I am looking to bring my application up to date using shaders instead of the classic GL2.1 specification. One thing that I have noticed is that the gluTesselation routines are not available in the core mode for 4.x shaders. How can I get a tesselation of vertexs for a polygon surface that contains holes without these functions? I have looked at the tesselation shaders and they don’t seem to provide the ability to tesselate a surface which contains holes in the classical sense like the traditional glu functions would do.
What function set is available to all defining an exterior polygon and then defining the interior polygons which will get removed from the final surface such that I get a single list of triangles which could be put into a VBO for the shaders?
Do it on the CPU. Its not like you were getting hardware acceleration beforehand. There’s nothing those functions were doing that you couldn’t do yourself.
I don’t want to reinvent the wheel. Can I still use the gluTess functions when using core shader mode? Obviously, I would have to use feedback mode to get at the triangulated vertex results from the tessellation and store those into a VBO. But the question comes back to, will these still work?
The GLU tessellation functions don’t call any OpenGL functions; they just invoke the various callbacks registered via gluTessCallback. So there’s no fundamental reason why you can’t use them with a core profile. Although it’s a bit more complicated because the tessellation API was designed to be used with glBegin/glEnd.
Usually when I do a tessellation in the traditional 2.1, I put it in a display list. So for that portion I don’t have to deal with the glBegin/glEnd. However, since this will be used to generate the vertexs for a VBO, this would have to happen by way of an actual render in feedback mode. Is there another way to get the generated triangles from the tessellation object so that the vertexs can be stored into a VBO for use by the shader? How are people doing the tessellation these days using shaders? They must be using something, as there is no point in always rolling out ones own tessellation algorithms.
That’s incorrect. The tessellation API returns primitives and vertices via the callbacks you register. As display lists aren’t available in the core profile, you’ll need to do something else with those callbacks, e.g. adding the vertices to a VBO.
So, the callbacks will be call as the primitive triangles are being created from the tessellation? If I understand this correctly, I should be able to plug code in on the vertex callback to populate a VBO of the final triangles which will be fed to the shader. Is this what you are referring?
Yes. It’s a bit more complex than that, as a single gluTess{Begin,End}Polygon() pair will typically make multiple calls to the begin/end callbacks with varying type arguments (which can be GLU_TRIANGLE_FAN, GLU_TRIANGLE_STRIP, or GLU_TRIANGLES). So as well as storing the vertices passed to the vertex callback, your code will need to keep track of which primitive type is being constructed and construct an element (index) array with the correct topology.
Is there a good way to determine approximately the amount of space that would be needed during the tessellation operation so that memory can be pre-allocated in a block instead of wasteful resizing, reallocating of memory.
If the geometry doesn’t self-intersect, there won’t be any new vertices created, so the VBO only needs to be large enough to hold the original vertices (provided that the vertices are labelled so that you can identify duplicates). I believe that each triangle will contain at least one edge from the original polygon, which gives you an upper bound on the size of the element array.
If the geometry can self-intersect, all bets are off.
[QUOTE=GClements;1293093]If the geometry doesn’t self-intersect, there won’t be any new vertices created, so the VBO only needs to be large enough to hold the original vertices (provided that the vertices are labelled so that you can identify duplicates). I believe that each triangle will contain at least one edge from the original polygon, which gives you an upper bound on the size of the element array.
If the geometry can self-intersect, all bets are off.[/QUOTE]
I forgot to mention that there are internal circular holes. What really, it seems like there is no good way to get a quick guess except that the minimum would be the maximum of the vertexes used to describe the outer polygon plus the vertexes of the inner polygons.