[osg-users] NodeKit integration in OpenSceneGraph-2.x series
Robert Osfield
There has been lots of discussion about various NodeKit or last month
or two. In OSG-2.6 we saw the introduction of osgWidget from the
community, in OSG-2.8 we'll see the integration of new osgVolume
library. OSG-2.10 is likely to see the integration of osgAnimation,
but if things converge quickly for this NodeKIt it might even make it
into OSG-2.8.
There are other NodeKits out into the community, some are up to date
and well maintained others rather dormant or even orphaned. Each of
these NodeKit could be put forward for integration with the core OSG.
Whether any of these should be integrated and if so how one goes about
is something that is worthy of discussion. I don't think we need
heavily structured metrics to measure NodeKits against, but some
informal metrics might help provide some transparency in the process.
Here's a couple to get started with:
1) What overall feature set does the OpenSceneGraph need as it evolves
to better meet the common needs of the community?
All NodeKits needs to be take as a step towards this goal, this
includes ones already in OpenSceneGraph trunk.
But how to define the goals for the OpenSceneGraph for the 2.x and
3.x series and beyond?
2) All NodeKit to make into the core OpenSceneGraph need to be
portable across all platforms. (Or might there be exceptions??)
3) All NodeKit to make into the core OpenSceneGraph need to fit to the
C++ design and coding style
4) All NodeKit need to be activity used and supported by a range of
members in the community.
5) Granularity of NodeKits need to fit the function as well as the
breadth/complexity of functionality encompassed.
6) Where functionality of two NodeKits overlap then for integration to
occur the NodeKit need to be merged in some fashion,
this might be that osgOriginal and osgNew get merged into
osgOriginal, or even into a osgBetterNameForCombination.
Migration to new merged classes/NodeKits would require a system
for helping existing users migrate / provide deprecated functionality
for a defined period.
7) Naming of NodeKits should be descriptive of it's function, prefer
long descriptive name over short acronyms.
8) NodeKits should have ascii read/write support, but ideally binary
support too (we really need an extensible binary format).
9) NodeKits must be wrap-able via osgIntrospection/genwrapper.
10) NodeKit should facilitate collaboration and quell fragmentation of
code and developer resources.
11) NodeKit should be of solid design and implementation quality.
12) NodeKit and dependency proliferation should be deemed a negative
quality - a NodeKit must add real value to compensate for the
extra complexity it introduces.
OK, feel free to add more/refine the above. Once this discussion
reaches some kind of conclusion I'll put up a page on the WIKI
summarising it all.
Putting the above metric against the core OSG NodeKits we see a couple
of libs that perhaps could be renamed/refactored. osgSim and osgGA
aren't descriptive names at all. osgDB is not much better, put
probably not quite so bad and it's not a NodeKit so exempt from all
common sense :-)
osgGA is very old and clunky which could do with a revamp, such as
revamp might be a good time to merge the functionality it provides
into other NodeKits. Perhaps some functionality going into core OSG,
some into osgUtil, the rest into osgWidget/and or osgViewer? This
would give us one less NodeKit to worry
about.
osgSim is a bit of rag tag collection of functionality. It's role is
primarily our osgVisualSimulation NodeKit, although some of the
functionality is bit more general than this.
--
Then we have functionality that it might be good to have in the core
OSG, animation, audio, physics and ephemeris models are all what I
would deem as worthy for inclusion to the OSG. I mention these as
they are functionality that I believe meets item 1 above - they are
useful to a wide range of OSG users, they make the OSG more useful off
the shelf.
Animation is something that is under-way in the form of osgAnimation,
which started life as AnimTK and has evolved rapidly to tick many more
of the above items, so it looks to be rapidly becoming a good
candidate for inclusion.
Audio is something that could be filled by osgAL, but I've done
reviews of it before with a mind to merging it as an osgAudio library
but felt that it needed work before it was ready for inclusion.
Physics is an integration issue as we'll never attempt to do wholesale
physics ourselves, I haven't reviewed any strong candidates for this
role yet.
Ephemeris model - accurate day and night sky rendering is something
that osgEphemeris could serve as base for. When I review it a couple
of years back I felt that it was it wasn't ready for integration, and
it's evolved little since. The osgEphemeris distribution is rather
spread out and overly hard-wired for it to really
shine as an OSG NodeKit. A tighter library which automatically
supports tracking of time around a geocentric model, as well as fading
the sky model from an
in atmosphere to a space view is something that needs to tackled. In
my ideal world we'd be able to just decorate a terrain model with a
single Ephemeris node and have it work without any hard-wiring from
the viewer. If can you distil the scene graph integration down one
main Node then perhaps it could folded into a lib like osgSim rather
than sitting out in its own library.
--
Then there are other items orthogonal like language bindings, and
OpenGL ES 1.x, 2.x and OpenGL 3.x support. These aren't NodeKits, but
it might be that one day we might have have extra libs for these as
part of core OSG distribution. Such libs would need to tick most of
the same boxes as NodeKits.
As a general note on version numbers, I'd say added extra NodeKit
into the core OSG is something can easily fit into a natural OSG-2.x
series progression.
What would push a version bump to the OSG-3.x would be re-factoring of
core libraries such that would necessitate application developers
porting their application across to the new OSG-3.x series, and would
provide significant new scope to the OSG. OpenGL ES 1.x and 3x
support are items that to do properly will probably require such a
bump.
Robert.
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Jan Ciger
Hash: SHA1
Hi Robert,
Robert Osfield wrote:
> Animation is something that is under-way in the form of osgAnimation,
> which started life as AnimTK and has evolved rapidly to tick many more
> of the above items, so it looks to be rapidly becoming a good
> candidate for inclusion.
Just a parenthesis - I gave quite a bit of feedback to Cedric about
this. I think that there are some design issues that need to be
addressed first, before it even reaches basic feature parity with
existing code in osgCal or Replicant when concerning basic animation
support (not the more advanced stuff in Replicant).
> Physics is an integration issue as we'll never attempt to do wholesale
> physics ourselves, I haven't reviewed any strong candidates for this
> role yet.
I wouldn't try to integrate physics as such - that is a monstrous job
and you would be tied to one engine that doesn't fit everyone (which
one? ODE? Bullet? Havoc? ...)
I would rather make things easy to integrate by the end users (e.g. an
easy way to get bounding boxes and meshes from the nodes at runtime for
collision detection) and perhaps include a collision detection support
in the core scenegraph. This has been a persistent question over the
years and a good integration of collision detection needs support from
the scenegraph.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJFzQMn11XseNj94gRAkOqAKCR4c3hilM7YZg+3sKYneEQfUpAEACghzK5
iQp3QmTvjMbFanG8TypXsg4=
=ZgZE
-----END PGP SIGNATURE-----
Erik den Dekker
> > Animation is something that is under-way in the form of osgAnimation,
> > which started life as AnimTK and has evolved rapidly to tick many more
> > of the above items, so it looks to be rapidly becoming a good
> > candidate for inclusion.
>
> Just a parenthesis - I gave quite a bit of feedback to Cedric about
> this. I think that there are some design issues that need to be
> addressed first, before it even reaches basic feature parity with
> existing code in osgCal or Replicant when concerning basic animation
> support (not the more advanced stuff in Replicant).
Jan, I followed your comments to Cedric and above with interest. You made
several important remarks to ensure that osgAnimation will properly support
character animation / skeletal animation.
However, I wonder if you are not putting too much emphasis on just this
aspect while there may be more ways to do and use animation. It is my
understanding that animation means that a certain aspect of a scene is under
control so it can be changed over time. This aspect is usually orientation,
position or scale, but may also be color, a float weight, a bool, a string,
etc... maybe some custom type. IMHO osg should take a generic approach
towards animation, albeit probably not too generic :). Perhaps 3D studio max
(or similar - I just happen to have some experience with this app) can be
taken as an example how to approach animation. It uses animation controllers
and key frame animation to implement animation and in my experience this is
quite flexible. I wonder how far osgAnimation should go in replicating
similar functionality.
This said, I must admit that I have only quickly glanced over osgAnimation
in its current state, and I believe it already supports much of what I
mentioned.
Cheers,
Erik den Dekker
Wang Rui
Of course, OSG focuses on how to improve the efficiency of rendering and most models are generated from external libraries and software (like 3dsmax). But some times we may need build models from curve and point data of end-users. It is a trouble if these data should be converted by other software and transferred back to OSG, especially on the network. Also a modeling nodekit is a good place for some of existing classes to live in, like Delaunay, Simplifier and SmoothingVisitor, and a good start for future developments. Maybe we could create and assemble models using a modeling nodekit and control them with an animation nodekit in comming days.
Robert Osfield
On Sun, Nov 9, 2008 at 7:03 PM, Jan Ciger <jan....@gmail.com> wrote:
> Just a parenthesis - I gave quite a bit of feedback to Cedric about
> this. I think that there are some design issues that need to be
> addressed first, before it even reaches basic feature parity with
> existing code in osgCal or Replicant when concerning basic animation
> support (not the more advanced stuff in Replicant).
And this is why I wanted to encourage discussion about it from those
experienced with osgCal etc. ;-)
osgAnimation does have a lot of promise, that promise is most likely
to be fulfilled with usage and refinement. This is exactly how the
core OSG shaped up from being a tiny niche scene graph that could
render a shiny cow to one that can do what it does today.
>> Physics is an integration issue as we'll never attempt to do wholesale
>> physics ourselves, I haven't reviewed any strong candidates for this
>> role yet.
>
> I wouldn't try to integrate physics as such - that is a monstrous job
> and you would be tied to one engine that doesn't fit everyone (which
> one? ODE? Bullet? Havoc? ...)
>
> I would rather make things easy to integrate by the end users (e.g. an
> easy way to get bounding boxes and meshes from the nodes at runtime for
> collision detection) and perhaps include a collision detection support
> in the core scenegraph. This has been a persistent question over the
> years and a good integration of collision detection needs support from
> the scenegraph.
I covered this point in my email on the physics integration thread - I
don't want an osgPhysics library tied to specific physics engine, but
rather a NodeKit that facilitates the integration of physics engines.
It's best to track down this email as it goes into my thoughts on this
topic in far more detail than is appropriate to repeat here.
Robert.
Robert Osfield
I was wondering about mentioning modelling functionality in my email,
but held back as it's potentially a huge and complex topic in itself.
I certainly open to nurbs support in the core OSG, hard stuff are
items like computing accurate intersections between nurbs. The same
goes for basic geometry construction. Currently we have various
things for creating scene graph elements in osgUtil, and the
ShapeDrawable in core osg. If we had a osgModelling NodeKit/utility
library then these elements might be best moved into osgModelling.
The are a number of areas in geometry creation that can get very
complex, I know because I've done a work in this in the past -
sometimes things get far more complex than original expected once you
deal with real world data. This complexity also raises the bar for
how many users are capable of helping maintain it. The fewer the
users available to maintain the more often it falls on my shoulders to
fix problems, but given my role these days I have to function as a
multi-tasker covering many different topics it makes it very hard for
me to have sufficient time and focus to tackle these complex problems.
Due to this maintenance issue taking on any NodeKit makes me bit
nervous, the more advanced it is the more of challenge it will be for
me to keep on top of it.
There already couple of NodeKit's in the OSG that I already feel not
fully able to maintain them, and these NodeKit's have been effectively
orphaned so it has ended up on my shoulders to maintain them. New
NodeKit's don't solve these existing maintenance issue only add to the
possible burden so I have to be very careful. Having NodeKit's
develop out in the community and be shook down prior to integration is
the way forward on this.
Robert.
On Mon, Nov 10, 2008 at 12:45 AM, Wang Rui <wang...@gmail.com> wrote:
> Hi Robert.
>
> I wonder if there is a plan to add a modeling library to the core OSG in
> future. Not because I'm working on a similar library 'osgModeling', but also
> from the experiences of other 3D graphics APIs. Take VRS3D for example, it
> has a number of common functionalitys which help build user customized
> models from curves and parameters, like extrusions (VRS::Extrusion),
> revolutions (VRS::Hyperboloid), torus and the most important, Bezier and
> NURBS.
> Of course, OSG focuses on how to improve the efficiency of rendering and
> most models are generated from external libraries and software (like
> 3dsmax). But some times we may need build models from curve and point data
> of end-users. It is a trouble if these data should be converted by other
> software and transferred back to OSG, especially on the network. Also a
> modeling nodekit is a good place for some of existing classes to live in,
> like Delaunay, Simplifier and SmoothingVisitor, and a good start for future
> developments. Maybe we could create and assemble models using a modeling
> nodekit and control them with an animation nodekit in comming days.
>
> I would like to help develop such nodekits and share my existing code if
> others have better plans and actions. Also I would keep on developing
> osgModeling as a external project if a modeling library is not needed at
> present, and be glad to do any work to improve and popularize OSG. There are
> thousands of OSG members in China (statistics from the osgchina forum) and
> it will be a great power of the OSG community in any time.
Sukender
I agree with your vision and think that this will push OSG to more power and popularity. Grouping, refactoring and factorizing are always great ideas - even if that would require a lot of work from the whole community.
About physics: I want to say something, but I didn't found the "physics integration thread"... (I just changed my email address so that my inbox is almost empty!)
** About utilities:
I coded some little features that could be integreated into OSG, but I have one problem: these are often specific and very small (not enough to create a nodekit). So what? May I suggest them to be integrated into osgUtil or such? In osg-submissions perhaps?
Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP networking (TNL).
** About organization:
I think that work that is enough "general purpose" should be integrated into OSG, but that maybe needs a little bit organization: as the number of functions and classes will grow, the user may get "lost". Here are some ideas:
- Create sub-namespaces to split big ones
- Create an index (in reference docs) by theme (meshes boolean operations, image processing, post-render effects, spatialized audio...)
- And of course update the wiki as it is already!
For me, that's leaving less and less code in my engine, which is great news - since it could be useful to more people of course.
** About dependencies:
I agree that dependencies should be added only when really needed, but in another hand, it is sometimes useful to link against lower-level portable libraries. I'm actually thinking about boost libraries (filesystem.path, program_options, and smart pointers).
For instance, I coded overloads of osgSB::read*() that take boost::filesystem::path. The main benefit is of course to handle paths the same way under many OSes. Do you think that it could be possible in OSG?
Sincerely,
--
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Robert Osfield
On Mon, Nov 10, 2008 at 9:56 AM, Sukender <suky...@free.fr> wrote:
> ** About utilities:
> I coded some little features that could be integreated into OSG, but I have one problem: these are often specific and very small (not enough to create a nodekit). So what? May I suggest them to be integrated into osgUtil or such? In osg-submissions perhaps?
> Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP networking (TNL).
We have to be careful about when and where we do feature integration.
Sometime integration could be put into a pre-exisitng library, I do
raise this point in my first post, but countering this if extra
external dependencies are brought in by an addition.
> ** About dependencies:
> I agree that dependencies should be added only when really needed, but in another hand, it is sometimes useful to link against lower-level portable libraries. I'm actually thinking about boost libraries (filesystem.path, program_options, and smart pointers).
> For instance, I coded overloads of osgSB::read*() that take boost::filesystem::path. The main benefit is of course to handle paths the same way under many OSes. Do you think that it could be possible in OSG?
Each dependency needs to be viewed on its own merit, and kept to
specific scope. The larger the dependency the smaller the scope it
should have, i.e. be kept to a plugin or a specific NodeKit. This
approach allows users to be able to gain the bulk of OSG functionality
without needing to pull together other significant libs. Boost is
something that I'd put under the category of a big dependency and as
such isn't something that should go any where near the core OSG that
needs to be kept as light and easily portable with minimal
dependencies. You are welcome to add such dependencies to your own
app, but for the OSG I need to keep the core clean as possible as it's
the common denominator that we all share.
As guide I'd recommend having a look at the way I've managed exisiting
NodeKits and dependencies. You'll find the core OSG libs all just
depend upon principally C++ and OpenGL, this is something that has
guided OSG development right from the beginning and is something that
has helped the OSG port to far more platforms than competing real-time
graphics toolkits.
Jan Ciger
Hash: SHA1
Hi Eric,
Erik den Dekker wrote:
> Jan, I followed your comments to Cedric and above with interest. You made
> several important remarks to ensure that osgAnimation will properly support
> character animation / skeletal animation.
>
> However, I wonder if you are not putting too much emphasis on just this
> aspect while there may be more ways to do and use animation. It is my
> understanding that animation means that a certain aspect of a scene is under
> control so it can be changed over time. This aspect is usually orientation,
> position or scale, but may also be color, a float weight, a bool, a string,
> etc... maybe some custom type. IMHO osg should take a generic approach
> towards animation, albeit probably not too generic :).
I think that basic position/orientation/scale style animation is
supported by OSG already. No need to reinvent the wheel there.
> Perhaps 3D studio max
> (or similar - I just happen to have some experience with this app) can be
> taken as an example how to approach animation. It uses animation controllers
> and key frame animation to implement animation and in my experience this is
> quite flexible. I wonder how far osgAnimation should go in replicating
> similar functionality.
That's fine, however I would be extremely wary of an all-encompassing
animation framework that tries to do everything and does nothing well. I
think that it is better to take the "Unix-like" approach - a set of
small tools that do one thing, but do it really well. That means, that
if you need only translation/rotation/scaling you use a simple
keyframing support that is in OSG already, if you need skeleton you use
osgAnimation or osgCal, if you need morphing, you use a (yet not
existing) morphing library.
The only thing these things have in common is a that they vary over
time. That is already well supported in OSG - both the real time and
simulation time.
There is nothing else really common in the code and shoehorning all this
into one is not a good thing from the maintainability and usability
point of view. The Max example is a red herring - unless you plan to
develop an animation package, it has little relation to OSG. In Max it
makes sense to have all under a "single roof", because the animator
usually uses several of the tools at once and Max authors cannot predict
whether he or she is going to make characters or animate flying boxes.
However, the underlying code is very different under the hood for each
tool.
That said, there is nothing that prevents Cedric (or someone else) to
implement e.g. support for morph targets in the skeletal animation lib
or making osgAnimation a collection of tools to support different types
of animation instead of just a skeleton-based one. However, I think that
this is as far as it should go - if you need something special, you are
better off developing a special tool for it, than trying to "bend" the
existing codebase to do things it was not intended for.
> This said, I must admit that I have only quickly glanced over osgAnimation
> in its current state, and I believe it already supports much of what I
> mentioned.
I am not sure what you mean - right now all it does is a simple software
skinning of models animated via skeletons. There isn't really a notion
of a controller or anything.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJGBCon11XseNj94gRAreEAJ9jVs08NPYxrnaWv04hsmLweiz9OwCfabz3
vNWQmiXZghXnfaqIUOzL4eU=
=UeSJ
-----END PGP SIGNATURE-----
Wang Rui
Sukender
> Hi Sukender,
>
> On Mon, Nov 10, 2008 at 9:56 AM, Sukender <suky...@free.fr> wrote:
>> ** About utilities:
>> I coded some little features that could be integreated into OSG, but I have one problem: these are often specific and very small (not enough to create a nodekit). So what? May I suggest them to be integrated into osgUtil or such? In osg-submissions perhaps?
>> Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP networking (TNL).
>
> We have to be careful about when and where we do feature integration.
> Sometime integration could be put into a pre-exisitng library, I do
> raise this point in my first post, but countering this if extra
> external dependencies are brought in by an addition.
Err... well, I'm not sure I explained myself the right way. I was saying that I coded some utilities *that have no other depedency* than OSG but that could be a little bit specific. So you think that I may discuss them on osg-submissions, or here? (The note about openAL/TNL was something completely different...)
I agree that dependencies are generally a burden when compiling OSG (thanks to those who maintain 3rd party libs!). And I won't suggest intagration of huge libs anymore!
But do you think some users could be interested in code that has dependencies, but distrubuted *outside* OSG? I mean perhaps some people already said "I want library XYZ to be integrated into OSG" ; so maybe this could be useful to put links to existing code on the wiki? Maybe a "Already-coded libs integrations"-like paragraph anywhere on the wiki could be useful? Well, that's just an idea...
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Robert Osfield
On Mon, Nov 10, 2008 at 11:06 AM, Sukender <suky...@free.fr> wrote:
> I agree that dependencies are generally a burden when compiling OSG (thanks to those who maintain 3rd party libs!). And I won't suggest intagration of huge libs anymore!
> But do you think some users could be interested in code that has dependencies, but distrubuted *outside* OSG? I mean perhaps some people already said "I want library XYZ to be integrated into OSG" ; so maybe this could be useful to put links to existing code on the wiki? Maybe a "Already-coded libs integrations"-like paragraph anywhere on the wiki could be useful? Well, that's just an idea...
We already have a Wiki page for community maintained NodeKits.
http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits
Sukender
Allright, I thought it was only for nodekits, not for integration of a specific library.
--
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Paul Speed
If this new node kit is only going to handle skeleton-based animation
then maybe osgAnimation is not the best name.
-Paul
Robert Osfield
On Mon, Nov 10, 2008 at 5:54 PM, Paul Speed <psp...@progeeks.com> wrote:
> From the peanut gallery (since I'm watching this with great interest)...
>
> If this new node kit is only going to handle skeleton-based animation then
> maybe osgAnimation is not the best name.
That is nothing better that criticism....
Ohh yeah there *is*, it called CONSTRUCTIVE CRITICISM.
So oh of great wisdom you need to come forward with a better name.
FYI, AnimTK which has become osgAnimation is not just about skeleton
based animation, it just one of introductory features.
Robert.
Paul Speed
Robert Osfield wrote:
> H Paul,
>
> On Mon, Nov 10, 2008 at 5:54 PM, Paul Speed <psp...@progeeks.com> wrote:
>> From the peanut gallery (since I'm watching this with great interest)...
>>
>> If this new node kit is only going to handle skeleton-based animation then
>> maybe osgAnimation is not the best name.
>
> That is nothing better that criticism....
>
> Ohh yeah there *is*, it called CONSTRUCTIVE CRITICISM.
Yikes!
>
> So oh of great wisdom you need to come forward with a better name.
>
> FYI, AnimTK which has become osgAnimation is not just about skeleton
> based animation, it just one of introductory features.
Yeah, I was being too subtle. The previous poster seemed to be arguing
for only including bones/skeleton/skinning support... with everything
else falling into different node kits. So you either end up with
osgAnimation not really being about general animation (osgBones?) and a
handful of other "animation" related nodekits, or you (the collective
you*) solidify the description of osgAnimation to more clearly align
with what you (the specific you) feel it should contain. (Which for the
record, I agree with your take on it... ie: not just bones)
Never meant to step in the bear-trap, though.
-Paul
(*) - I might have said "we" but did not want to presume to include
myself based on one errant and poorly received comment. :)