Hi Jan,
Thank you taking time to read code and test it. I will try to answer to
your remarks.
Jan Ciger wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Robert (and all),
Robert Osfield wrote:
Your experience on CAL/OSG integration would be useful a guide for the
osgAnimation development. My hope is that osgAnimation would be able
to replace osgCal usage, but without any experience with osgCal I
can't say how easy as step this is right now, or how easy this can be
made, so... it would be useful to get feedback from those who've been
using osgCal/ReplicantBody as to what is missing/needs improving on
osgAnimation to make it possible to move apps over to osgAnimation.
I have managed to compile the branch with osgAnimation and it works OK
on my Linux system. Here are few things I have observed, Cedric feel
free to correct me if I am wrong here:
- - The animation format seems to be not very practical/efficient. The
animation is stored as a special node in the .osg file, with each bone
having every key specified, even if it is not moving. It is simple, but
leads to huge files. Cal3D and most animation toolkits are able to
interpolate the keyframes between points in time - i.e. I specify a time
when certain key pose should be set, not a set of samples at fixed
intervals. If the bone is not moving, only one sample is set at the
beginning.
You are right, but it's not the job of osgAnimation to make this
assumption, osgAnimation
interpolate bewteen keyframes. The optimization of key is the
responsiblity of the exporter
instead. In the osg exporter i bake everything without optimization yet,
that's why it produces
a big amount of data. To work quickly i just exported all baked animation.
If you want you can just put one key for a channel or two with 40
seconds between them.
So it's not a blocker. But in the futur you could want to separate each
channel like PosX PosY PosZ
because sometimes it vary only on one value and you can save space like
espacialy if you have to bake
animation.
Also, from a practical point of view it is better to separate
animations, skeleton and mesh files. The same skeleton and animations
are often reused for several different meshes (e.g. with different
textures or even shapes). This could be probably handled by loading
several osg files, but it needs to be kept in mind. This is why Cal3D
has these data separate.
Yes i am completely agree with that. Here more info how it's splitted.
RigGeometry
Animation/Channel
Skeleton/Bone
So those 3 elements can be splitted in different file, and in animtk it
was like that before, the .osg is just a container of those three elements.
- - Is there support for different frame rates of the animation? This is a
very important feature, together with the capability to
resample/interpolate the animations on the fly. E.g. a motion capture
system can give you an animation file at a frame rate being anything
between 20-120 Hz. You cannot rely on having all animations at the same
frame rate, because assets are often reused and pre-converting
everything every time is simply not practical.
There is no framerate, you specify your keyframes in seconds so more
your put keyframes
in a short range of time and better the resolution is.
- - How many bones can be influencing one vertex of the mesh? The data
seems to be stored as skeleton bone having a list of vertices affected
by it + weight. I wonder how practical this is from the exporter/design
tool point of view - you typically "paint" weights over the mesh and
assign bones to vertices, not vertices to the skeleton bones.
the format stored is VertexGroup.
For a geometry you have a set of VertexGroup, a vertex group is a list
of 'id of the vertex' and its 'weight'.
The name of vertex group identify the target typically the bone. Using
this format is generic. For example
if you want to extend the mesh, like adding new vertexes, you can add a
group for them and give it the name
to the new bone or other elements that could influence those vertexes.
Then rebuild
the association on the fly. I choiced this format for genericity it's
easier to manipulate, but i know sometime it's less readable in
the osg file.
This is a detail, though, but it leads to long lists of vertices that
are duplicated several times, for each bone affecting the vertex. A more
usual way is to have a vertex id followed by a list: bone id weight bone
id weight ... That allows to have the long list only once. A
pathological worst case would be a mesh where every vertex is affected
by all bones. With the current format one would have e.g. 2000 vertices
x 15 bones = 30000 vertex entries. With the format I have mentioned, one
would have only 2000 entries.
It's the same amount of data. it just differents way, you suggest
2000 x 15
and it's currently
15 x 2000
but i am agree your solution produces less lines.
- - Support for animation priorities - an absolutely essential thing, but
doesn't seem to be there yet (I may be wrong). If there are multiple
animations playing and influencing the same parts of the rig, they need
to be weighted. For example a waiter carrying a tray with drinks - you
have a walk cycle animating the whole skeleton and a raised arm holding
the drink tray steady. The arm animation would have higher priority,
overriding the walk cycle for the part of the skeleton. Cal3D does this
using an animation mixer.
You are right, it's not yet here, it's the next thing i plan to do.
One cannot rely on having two animations affecting only distinct
portions of the rig - this is not feasible unless one animates
everything by hand and it doesn't look natural anyway - e.g. even the
waiter's hand above will be bobbing up and down a little in the rhythm
of the walk cycle, otherwise he would look like having a terrible cramp
in that hand and holding it completely stiff.
- - Support for animation blending - there needs to be a possibility to
transition smoothly from e.g. walking to jump and again to walking. This
is done using animation blending - interpolating between the end pose of
one key frame to the start pose of the next one. Without this jumps will
occur and it will look bad.
Of course it's essential too, it's in the pipe too
- - Hardware accelerated skinning - at the moment the skinning seems to be
done all in software, not using vertex shaders. There is code in osgCal
that does this already. I believe that there was also the osgCharacter
nodekit doing skinning in hardware.
Yes not yet inside osgAnimation. The current software implementation can be
optimized too. But i dont have time to do that right now. I have to
finish some functionnalities
before. If someone wants to help :)
Thank you for the list of remarks, don't hesitate to i would like your
opinion on the sceduler/mixer
i plan to do. I would like to make something like in flash, a timeline
where you can put at any frame
a callback. And when we could compose sequence of animation as timeline
too recursively. It can be confusing
but i have not found a good way to manager animation in time, even with
osgcal it was hard to plan animation in
time, and do introspection when you need.
Example when you click on mouse, you compose a squence of different
animation on a timeline and then you play this timeline.
(sitdown, drink a beer, ...). i mean to manage sequence it look very
interesting. and easy to make introspection like removing the last
animation of squence if an event is catch...
What do you think ?
Thank you so much for your report, it's helpful.
Cheers,
Cedric
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEiFPn11XseNj94gRAp7zAJ9GfVItg9/yMumJqKSG+vv6I/pLywCgq3X0
/K4ldjB6H5SMwfNCLyJJWEo=
=pJFv
-----END PGP SIGNATURE-----
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED]
http://www.plopbyte.net
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
