Hi Roland,
Yes i would like tok keep it backwards compatible when changes are
recent, But i dont want to maintain old code too, so the idea is too
keep old code a bit and then remove it after a while, when blender
exporter will be updated i guess.
Yes the number of way to interpole things are small, i think it will
grow in the futur depending on people needs. It's interesting the
collada datatype works and more generic. I dont know if we need all this
generic stuff, but anyway it's a good example iand show us how it could
be flexible to use array.
The Animation call back for StateSet Uniform and others are not yes
implemented, but you are definitely right.
Oh, and animations in Collada can be endlessly nested
Can you give me an example i am not sure to understand this point.
Thank you for explanation, we have good elements to think :)
As you saw osgAnimation is young and needs time to become better and better
I am in travel for a few days, so i will submit your changes as soon as
i can. I guess a few days
And thank you for helping
Cheers,
Cedric
Roland Smeenk wrote:
Cedric,
I just added the things I thought were relevant to the writer. You may have a
better overview of the things to come or to go. Do you to keep writer backwards
compatible for all future changes?
Looking at the animations in Collada (which drives most of the changes I made and would like to make to osgAnimation) I still see some areas of osgAnimation that may be extended.
Collada supports the following interpolation types:
-STEP
-LINEAR
-BEZIER
-HERMITE
-CARDINAL
-BSPLINE
Each key in an channel can be of a different interpolation type!
Currently the first key determines the interpolation type for the whole channel.
The datatypes supported by channels can be composed of arrays of floats, ints,
bools, names, IDREFS.
So for instance a bezier position animation may be composed of a float array of
time values, a float array of position values, a float array of intangents, a
float array of outangents and an array of interpolation types (name array).
Each array contains one or more values that may contribute to a single
keyvalue. So for instance the position float array contains X, Y, and Z values
for each position.
This design also makes it possible for instance to build a single channel that
updates all available morph weights in a morphgeometry. So if there are 5
morphtargets this would need a osg::Vec5Array, which obviously does not exist.
A little too much detail maybe, but this shows the flexibility of Collada
animations. I am not saying we should be this flexible with osgAnimation. In in
practice there will be a few typical keyframe compositions (like those exported
by Max or Maya).
Furthermore Collada animations may target almost all data available, because
most of the data is targetable. In osgAnimation the target exists in an
AnimationUpdateCallback and specific callbacks know what targets go into a
specific node type. Currently the AnimationUpdateCallback is derived from
Node::UpdateCallback.
We may also need to be able to create custom callbacks for osg::StateAttribute::Callback, osg::StateSet::Callback, osg::Uniform::Callback, osg::Drawable::UpdateCallback etc.
In that case the linkvisitor should also dive into these objects to see if it can link the animation.
Oh, and animations in Collada can be endlessly nested.
Anyway enough rambling, just some food for thought...
Roland
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=7540#7540
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:[email protected]
http://www.plopbyte.net
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
