Hi Aurelien, On 10 June 2013 21:48, Aurelien Albert <[email protected]> wrote: > You're right. Mixing concepts/feature is often a bad idea. > > But there was another idea here : giving ability to CPU algorithms to parse > primitives properly. > > So perhaps a good place for patch size parameter is in the osg::PrimitiveSet > class, but using a dedicated member ?
This would increase the size of the osg::PrimitiveSet objects just for occasional use so would result in greater memory usage and more cache misses. > This way it will be still possible to execute properly algorithms such as > "normal smoother" optimizer or user-defined algorithms. > Of course an intersector will never properly on GL_PATCH (due to primitive > creation / displacement on GPU side) but it's really usefull to be > able to properly parse data. > > The use of a StateAttribute for GL_PATCH_SIZE will make this work much harder. If you want to properly account for handling GPU tessellated meshes then we'd need some form of callback mechanism for users to provide the meshes, a bit like custom shaders that you attach to a osg::Program that are written to handle a specific patch setting, the callback would also need to know. Whether you hard code this or whether you look at state is something we'll have to leave open. Uniform values as well as osg::Geometry vertex and primitive data will have an input to this so whatever we do we'll need to have some for a state tracking scheme for the callback to handle. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
