Original Post
I just spent several hours tracking down a very hard-to-isolate issue with OpenGL 4.0 tessellation. While I now have a workaround, I am trying to figure out if this behaviour is documented anywhere (I can't find any mention), or if it is a driver bug.
Basically, if I set GL_PATCH_VERTICES to any number other than 3, then I must reset it to 3 before rendering any non-tessellated geometry.
In my case I am using quad-patches for terrain rendering, so I have to call glPatchParameteri(GL_PATCH_VERTICES, 4) immediately before rendering the tessellated geometry. If I don't reset it with glPatchParameteri(GL_PATCH_VERTICES, 3) immediately afterwards, then all non-tessellated geometry will not render (as in no vertices will be read into a transform feedback buffer), so it appears that geometry is eaten in the (supposedly inactive) tessellation stage.
This is occurring on an AMD 5770, running Catalyst 10.10, under Windows 7 amd64, which happens to be my only machine to support DX11 features.
Any idea if this is a documented issue/feature?
[Edited by - swiftcoder on November 21, 2010 4:41:45 PM]
Basically, if I set GL_PATCH_VERTICES to any number other than 3, then I must reset it to 3 before rendering any non-tessellated geometry.
In my case I am using quad-patches for terrain rendering, so I have to call glPatchParameteri(GL_PATCH_VERTICES, 4) immediately before rendering the tessellated geometry. If I don't reset it with glPatchParameteri(GL_PATCH_VERTICES, 3) immediately afterwards, then all non-tessellated geometry will not render (as in no vertices will be read into a transform feedback buffer), so it appears that geometry is eaten in the (supposedly inactive) tessellation stage.
This is occurring on an AMD 5770, running Catalyst 10.10, under Windows 7 amd64, which happens to be my only machine to support DX11 features.
Any idea if this is a documented issue/feature?
[Edited by - swiftcoder on November 21, 2010 4:41:45 PM]
