Hi Philipp,
This is just a personal preference, but when faced with a similar
problem I tend to keep the data separate rather than extend the existing
class. The benefits are:
- You can use whatever class hierarchy suits your problem without being
bound by the constraints of what works best for the target class (in
this case, either Geode or Drawable).
- If you need more than one Geode, or multiple types, or no Geode in
some cases, it varies, or you want a geometry-free run, you're going to
wish you went for a separate class.
- If you want to perform geometry updates, you can always choose to
either modify the existing geometry, or just create a whole new Geode
and/or Drawable. If you extend instead, you're stuck working with that
one as a base, and you'll need to modify.
- If you want to add additional effects in some way to the geometry, it
will likely be easier this way.
Of course, there are cases where it would make more sense to extend the
OSG classes themselves. For example, if your problem was somewhat close
to a scene graph in design, and the geometry was always incrementally
updated due to a full rebuild being prohibitively expensive, it might
save some time to tie it in more directly through class extension.
Just my thoughts on the issue. I hope they help. :)
Garth
PS. In my own project I am *effectively* using a single osg::Group per
object that has a renderable component. That way I can include as much
or as little of OSG as I need. In practice it's a little more complex
than that, but it follows this basic idea.
On 07/01/12 02:54, Philipp Moeller wrote:
Hi list,
my use-case is this: I have data structures that cannot be rendered
directly but can be transformed to something that is renderable. All
algorithms manipulating data work on my own data structures. After the
algorithms are done, I would like to update the geometry to reflect the
changed data.
I'm unsure if I should extend a osg::Geode, add my datastructure as a
member and a rebuild() member funtion or if it makes more sense to
extend a osg::Drawable and go from there.
Basically, the setUserData() function already does what I want but it
lacks a way to issue an update.
Alternatively, I can just store my data separately and use setUserData
to have to keep pointers to the associated data and work from there.
Cheers,
Philipp
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
