The osg::Shape primitives are primarily about representing shades using geometrical primitives such as required for using in collision detection/physics engines. This is why you can associate them with osg::Drawables etc. The fact that we have a ShapeDrawable for rendering shapes is addition for convinience of rendering shapes rather than original intent of osg::Shape. In this context a subdivision surface is probably beyond the bounds of osg::Shape should try and encompass.
I see more overlap in the case of osg::Geometry - in particular the geometry, attributes and primitives for a subvision surface are already there waiting to as the input source to the subdivision code. However, a CPU based division code will need to generate new vertices, attributes and primitives and its these which will need to be passed down to OpenGL via the convential means. Considering the fact that the sub-division surface is view dependent pushes the compute into the cull or draw stage of rendering, or perhaps even a whole seperate division thread, points to multi-buffering of the division Geometry, especially if you are considering multi-camera support.
So I'd be included to have a subclass from osg::Geometry which allows the users to use the normal methods for setting up vertex, attributes and primitives, but have a multiple buffered osg::Geometry stored internally, and its these internal osg::Geometry that are populated by the subdivision code and finally rendered in place of the original osg::Geometry. This will require drawImplementation to be overriden on the subclass.
Robert.
On 5/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I'm playing around with creating subdivision surfaces in OSG, and I've
reached an architectural sticking point. Currently I've subclassed
Geometry which takes the control mesh and generates the renderable mesh
with AddPrimitive() and so on. But after a re-read of the OSG docs, it
seems logical to have a subdiv surface as a Shape. The Shape docs say that
they can be used for procedurally generated Geometry which is just what I
want, but all the implemented shapes use ShapeDrawable which is just a
convienience class for rendering without going via Geometry.
So my question is, what's the best way (in terms of keeping within the OSG
style and framework) of adding procedurally generated geometry such as my
Subdivision Surface?
John Donovan
Sony Computer Entertainment Europe
http://www.scee.com
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
[EMAIL PROTECTED]
This footnote also confirms that this email message has been checked
for all known viruses.
**********************************************************************
Sony Computer Entertainment Europe
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
