Hi Robert,
> although I'm not yet happy in having the mutable variable
I haven't tought about threading issues... maybe moving this variable from
osg::Program to osg::PerContextProgram would aviod any threading issue ?
Posted: Fri Jun 07, 2013 3:34 pm Post subject: Bugfix for GL_PATCH_PARAMETER
Hi Aurelien,
On 7 June 2013 13:10, Aurelien Albert <> wrote:
Quote: � Select �
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.
Quote: � Select �
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.
Quote: � Select � � Expand �
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.
In my opinion, this is the best option, because you can now tell to a
primitiveset exactly how it should be drawed.
About tesselating data on CPU : forgot about it. It's impossible. It's as
complex as executing a fragment shader on the CPU.
Thank you!
Cheers,
Aurelien
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54493#54493
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
