Hi Aurelien,
On 7 June 2013 13:10, Aurelien Albert <[email protected]> wrote:
> When writing a tesselation shader, you have to decide the patch size you want
> to be used as input by this shader.
> I mean that your code for 3-vertices patch will be really different from a
> code for doing the same thing with 4-vertices patch.
Indeed. I was surprised to see that extension isn't associated
directly with the program handle like the other program parameters.
> So, I think the idea "GL_PATCH_SIZE is associated with the program" is not a
> bad idea, since they are really correlated.
So as things stand you want to make sure it's set any time you are
using a tessellation shader, otherwise it's ignored, which to me makes
me think your suggested change is sound, although I'm not yet happy in
having the mutable variable - this type of approach suggests to me a
wider problem that you are working around, it also hints at potential
threading issues.
Perhaps one could push the GL_PATCH_SIZE state calls into osg::State
and let it do the lazy state updating, this could be called from
osg::Program at the appropriate point, this way you'd not need to
worry about checking the tessellation shader status.
> The idea of a StateAttribute could lead to better optimization (less openGL
> call to set alwas the same GL_PATCH_SIZE value) but I don't think that's a
> good idea because it can be hard to always know which GL_PATCH_SIZE value
> will be used for a particular shader.
>
> Maybe another idea should be to exend the osg::PrimitiveSet::Mode enum like
> that : (so all CPU code, like visitors know how to iterate over the data)
>
>
> Code:
> {
> POINTS
> LINES
> LINE_STRIP
> LINE_LOOP
> TRIANGLES
> TRIANGLE_STRIP
> TRIANGLE_FAN
> QUADS
> QUAD_STRIP
> POLYGON
> LINES_ADJACENCY
> LINE_STRIP_ADJACENCY
> TRIANGLES_ADJACENCY
> TRIANGLE_STRIP_ADJACENCY
> PATCHES_1 // GL_PATCH - Patch
> size = 1
> PATCHES_2 // GL_PATCH - Patch
> size = 2
> PATCHES_3 // GL_PATCH - Patch
> size = 3
> ...
> PATCHES_N // GL_PATCH - Patch
> size = N
> };
Interesting suggestion. There is real problem with the disparity
between processing fixed function geometry and how shaders relate to
geometry. Whatever we do we'll need to provide some state related
mechanism that is able to tesselate and place objects on the CPU in
the same way that they are processed on the GPU. This is a really
bleeding edge scene graph problem, no prior art to inspire us on this
one.
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
