[osg-users] Character animation in OSG
Dusten Sobotta
From what I understand, in addition to OSG/Cal, OSG has some animation features built in. Which animation libraries or extensions are ideal for handling .3ds models with skeletal animation?
Thanks in advance~
Cedric Pinson
Right now animation throw osgAnimation is limited and in a beta state,
in fact it's not really fully merge in osg, but it contains character
animation. There is today only a blender exporter that is capable to
export character/animation for osgAnimation.
I guess your best bet is to use osg/cal
Cheers,
Cedric
> ------------------------------------------------------------------------
>
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:morn...@plopbyte.net http://www.plopbyte.net
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Jan Ciger
Hash: SHA1
You can use osgCal or ReplicantBody. Both are based on the Cal3D library
for skeletal animation and allow you to provide custom skeleton. There
are mature exporters for all major modelers and animation packages - 3DS
Max, Maya, Blender.
However, both Replicant and osgCal have their advantages and drawbacks,
especially Replicant has quite slow rendering - if you need only few
characters it will work, but will not scale very well.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEUWwn11XseNj94gRAnuXAKC9+EbaOmNrPIgWFIOS4R5T6kih3ACgy7CU
z0zEpJf5YPnnUG9WGTwgPsQ=
=3rO4
-----END PGP SIGNATURE-----
Robert Osfield
On Wed, Nov 5, 2008 at 7:05 AM, Jan Ciger <jan....@gmail.com> wrote:
>> From what I understand, in addition to OSG/Cal, OSG has some animation
>> features built in. Which animation libraries or extensions are ideal
>> for handling .3ds models with skeletal animation?
>>
>
> You can use osgCal or ReplicantBody. Both are based on the Cal3D library
> for skeletal animation and allow you to provide custom skeleton. There
> are mature exporters for all major modelers and animation packages - 3DS
> Max, Maya, Blender.
>
> However, both Replicant and osgCal have their advantages and drawbacks,
> especially Replicant has quite slow rendering - if you need only few
> characters it will work, but will not scale very well.
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.
Robert.
Cedric Pinson
Yes it would be great to have feedback. After writing osgCal (the gpl
version) i decided to re design everything to make something new now
called osgAnimation. I would like very much to have report from osgCal
community and replicant body.
osgAnimation is young and need lot of work. Don't hesitate to contrib or
to comment it
Cheers,
Cedric
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:morn...@plopbyte.net http://www.plopbyte.net
Laurent Di Cesare
> Hi,
> Yes it would be great to have feedback. After writing osgCal (the gpl
> version) i decided to re design everything to make something new now
> called osgAnimation. I would like very much to have report from osgCal
> community and replicant body.
>
regards export format and error handling.
It's very common for my graphist to make a model, animate it in 3ds,
export it and then it just doesn't work, usually due to material-related
errors, which are extremely hard to understand (particularly for a
graphist). So whatever osgAnimation does and whatever format it uses,
I'd say the most important things are:
- Not GPL
- Reliable export tools (cal3d xml/compiled versions are nice since xml
is easier to debug) (ideally import too)
- Verbose/understandable error reporting when a model doesn't load so
you can know what part of the model (sekeleton, material, ...) fails
Brian R Hill
Thanks for you contributions!
The biggest issue I have with osgCal is that you have to load models
differently, you can't use osgDB::readNodeFiles and you can't clone
existing models. It complicates the applications loading routines.
We typically preprocess all our models and convert them to .ive format,
which we deliver and use for runtime. It would be nice to be able to do the
same with the animation models.
Brian
-----osg-user...@lists.openscenegraph.org wrote: -----
To: OpenSceneGraph Users <osg-...@lists.openscenegraph.org>
From: Cedric Pinson <morn...@plopbyte.net>
Sent by: osg-user...@lists.openscenegraph.org
Date: 11/05/2008 06:21AM
Subject: Re: [osg-users] Character animation in OSG
Jan Ciger
Hash: SHA1
Hi Cedric,
Cedric Pinson wrote:
> Hi,
> Yes it would be great to have feedback. After writing osgCal (the gpl
> version) i decided to re design everything to make something new now
> called osgAnimation. I would like very much to have report from osgCal
> community and replicant body.
>
> osgAnimation is young and need lot of work. Don't hesitate to contrib or
> to comment it
What is the license for the code (cannot use GPL, LGPL is OK) and where
to get it? I would give it shot.
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEbhln11XseNj94gRAns/AKCfOdSj2qQkhSCpsZ/Ds1zYmJFWwgCg6cgs
fddf4PwGkxyDG8UNJpUXWcY=
=FRua
Jan Ciger
Hash: SHA1
Laurent Di Cesare wrote:
> - Verbose/understandable error reporting when a model doesn't load so
> you can know what part of the model (sekeleton, material, ...) fails
I think this can be fixed - did you report the issues to Vladimir or
Ruben who are maintaining the library?
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEbjIn11XseNj94gRAkAGAKC/b6FLFVkTKbEkdGb0RgDZjn06KgCaAtVq
lfeVl/23wltowavJ8EM+NkQ=
=5ZvP
Robert Osfield
> -----BEGIN PGP SIGNED MESSAGE-----
> to get it? I would give it shot.
Cedric's has changed the licensing of osgAnimation so that it's OSGPL,
compatible with the rest of the OSG.
Robert.
Jan Ciger
Hash: SHA1
Hi Brian,
Brian R Hill wrote:
> Cedric,
>
> Thanks for you contributions!
>
> The biggest issue I have with osgCal is that you have to load models
> differently, you can't use osgDB::readNodeFiles and you can't clone
> existing models. It complicates the applications loading routines.
>
> We typically preprocess all our models and convert them to .ive format,
> which we deliver and use for runtime. It would be nice to be able to do the
> same with the animation models.
>
Unfortunately, that probably cannot be really helped. The osgCal
characters are really only a thin front-end to the Cal3D animation
library, it is not an OSG project and not something developed for OSG.
It is possible to fork Cal3D and convert it to use extensions to osg/ive
formats (osg/ive do not have anything for character
animation/skeletons), but that would also mean redoing the whole
production pipeline - exporters, loaders, etc. I am not sure the benefit
would outweigh the cost, especially because you would have to maintain a
forked version. Feel free to go ahead and do that, but I do not see much
benefit in it.
If you want to distribute a single binary file to the end-users, I would
look at things like loading from zip/pak files containing all your
assets together instead of shoehorning everything into an ive file.
Moreover, the ive format is more-or-less a dead end according to Robert,
not designed to be really extensible and will be probably replaced
sometime in the future.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEbo1n11XseNj94gRAq1LAJ9raq+e+U/IrYciaXekrlUC4lfcrACg6Pw5
SDQ/6SS2cVX5ghKlBQFThZ8=
=s/TS
Laurent Di Cesare
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Laurent Di Cesare wrote:
>
>> - Verbose/understandable error reporting when a model doesn't load so
>> you can know what part of the model (sekeleton, material, ...) fails
>>
>
> I think this can be fixed - did you report the issues to Vladimir or
> Ruben who are maintaining the library?
>
>
Brian R Hill
My comments were directed towards the osgAnimation discussion - Robert
asked for feedback on what people thought would be useful for an integrated
animation capability. They weren't directed at osgCal or cal3d and aren't
meant to be critiques of either. I appreciate both osgCal and cal3d and the
work people put into their development - I use them all the time with great
success - Thanks!
Brian
-----osg-user...@lists.openscenegraph.org wrote: -----
To: OpenSceneGraph Users <osg-...@lists.openscenegraph.org>
From: Jan Ciger <jan....@gmail.com>
Sent by: osg-user...@lists.openscenegraph.org
Date: 11/05/2008 10:22AM
Subject: Re: [osg-users] Character animation in OSG
-----BEGIN PGP SIGNED MESSAGE-----
Jan Ciger
Hash: SHA1
Robert Osfield wrote:
> On Wed, Nov 5, 2008 at 3:14 PM, Jan Ciger <jan....@gmail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> What is the license for the code (cannot use GPL, LGPL is OK) and where
>> to get it? I would give it shot.
>
> Cedric's has changed the licensing of osgAnimation so that it's OSGPL,
> compatible with the rest of the OSG.
>
OK, great. I will try to get it working here. Indeed, something newer
and better integrated than the venerable Cal3D would be good to have.
> our 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.
Well, I didn't see the new library yet, but as always, the main problem
is not to make the code work - basic keyframe playing and skinning is
not that difficult to do. The problem is to have the full pipeline from
the modeler to the screen and a way to use existing data. I will try to
get the osgAnimation to work and look at what would need to be done.
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEgWFn11XseNj94gRAkqkAJ4i4IqWr01PkRyAwx6x0c09vEBdxwCdE3Zt
f0PsfNktAwqPm1NJB+6CwmY=
=icJe
-----END PGP SIGNATURE-----
Jan Ciger
Hash: SHA1
Laurent Di Cesare wrote:
>> Actually I think it's more of a cal3d issue than an osgcal issue.
Well, the loading is done via osgCal, so if the underlying library barfs
on the data, it should report the error better.
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEgZYn11XseNj94gRAt8hAJ9FPp9MnFp4K3XhwNkqxaF38YW9OACdE7lm
BVWrsi+VeK+6pjgpaPndueI=
=Gu/g
Jan Ciger
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.
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.
- - 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.
- - 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.
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.
- - 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.
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.
- - 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.
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-----
Cedric Pinson
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-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:morn...@plopbyte.net http://www.plopbyte.net
Jan Ciger
Hash: SHA1
Hi Cedric,
Cedric Pinson wrote:
>> 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.
OK. My concern is not so much optimization (osgAnimation compressing the
keyframes), but the fact that the library can deal with sparse keyframes
for some bone and will correctly interpolate between them. If it can do
that, despite of the current naive exporter, then fine, but I didn't see
the timestamp/offset anywhere in the exported animation. How does it work?
>> 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.
OK, that is what I suspected too.
>> 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.
Sorry, but that is *NOT* acceptable. That is related to the issue with
the keyframes above. You need to allow to either specify a duration of
the animation or a frame rate. You cannot rely on the density of the
keyframes to do this - that would require that every animation has keys
even for frames where nothing is moving, just to maintain the framerate.
That is extremely inefficient. Also, conversions from one framerate to
another would be extremely difficult, requiring resampling and
re-interpolation of possibly thousands of keys.
The way to go is to say:
duration 30
time 0 bone 1 x y z qx qy qz qw
time 15 bone 1 x y z qx qy qz qw
time 17 bone 1 x y z qx qy qz qw
With just three keys I have fully specified the animation, without any
implicit assumption about the duration or framerate. Moreover, there is
no need to maintain a long stream of interpolated keyframes anywhere -
the animation engine still needs to interpolate between them in real
time, so why not exploit this for storing the animations too. With your
approach I would need 30 keys (assuming one key/second) - 10x more data.
Your naive approach will simply not scale once you have to deal with
many animations coming from different sources with different framerates
(mocap, hand-animated, procedurally generated, different project, online
repositories, etc.). You cannot assume that everything will pass through
a converter that will normalize the framerate and pre-calculate the
interpolated keys for you - that is just impractical and costly.
Also, I have noticed that you have included scale keys. If you want only
rigid bones (the most common case, one rarely models something like the
"Gummi bears"), then you can drop both scale and translation. The
quaternions/rotation matrices/rotation vectors are enough, together with
the binding pose of the skeleton. You just apply the transformations
recursively from the root of the hierarchy each time. That allows a very
compact representation.
>
>> 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.
I am not concerned about readability of the osg files - those files are
intended to be machine readable, not necessarily human readable.
However, the amount of memory and the efficiency of manipulation of the
data is a problem - do realize that a practical scenario can have
2000-3000 characters visible and animated at any given moment. I have
done this with osgCal before and it worked, even with software skinning.
>
> 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.
Not really - it makes a difference to have to parse all that and also to
keep that in memory. E.g. if you want to add a new bone that will affect
your vertex group, with my approach I just add a new weight to the
relevant vertices. With yours I need to duplicate the whole list of
vertex IDs and add new weights. The format I am proposing is equally
generic as what you have, but more efficient in practice, IMO. The idea
of vertex groups is really important for the modeler/exporter, but not
at all while you are actually rendering the animation (there you care
just about the weights and bone matrices), so I do not see why to keep
it there.
Your format will be also pretty hard to translate to a vertex shader -
there you need for each vertex all the bones and weights that are
affecting it so that you can transform it. However, what you have is a
list of vertices for each bone instead, requiring a costly run-time
conversion.
>
>> You are right, it's not yet here, it's the next thing i plan to do.
OK
>> Of course it's essential too, it's in the pipe too
OK
> - 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 :)
Well, as I said - with your current architecture this will be hard to
do. Look at how Vladimir did it for osgCal (Cal3D does software skinning
only). I know that the GPL version of osgCal had hw skinning as well.
>> 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 ?
I think you should realize what is the goal - making an animation
composer/editor or an engine to actually *play* the animations? What you
have designed is very complex and not needed for replacing osgCal alone.
A simple mixer takes a list of active animations and blends them using
their weights. This is done by calculating the corresponding poses for
all active animations, weighting the resulting bone positions using the
animation weights and summing them. If you want to make it more
sophisticated, you can add code ensuring that the bones actually stay
rigid (i.e. do not stretch or shrink - that is usually unwanted while
mixing).
The animation scheduling what you are asking about is a different issue
and typically not something you need to really bother too much with.
What is important for the higher level code is to be able to know
whether and which animations are active, have a
callback/signal/something to know when an animation has stopped and good
ease-in, ease-out capability, with blending between the finishing
animation and the one starting next. Then it is the responsibility of
the higher level code to sequence the animations.
Pushing this into the low level code is not going to be practical unless
you want to "pre-script" the whole activity, which is rare. A typical
case could be a character walking, sometimes jumping and turning to
avoid obstacles. The obstacle avoidance is driven by the user (e.g.
using cursor keys/mouse to steer it like in a shooter) or by some kind
of AI and will not be deterministic - I cannot make a timeline/schedule
when to schedule a jump or turn. Typically, the user/AI needs to turn
*now* because it has detected an obstacle/incoming bullet/whatever, not
sometime in the future when you have scheduled it.
ReplicantBody is implemented as described above - Cal3D deals with the
low level stuff and Replicant strings the animations together into
actions, including things such as proper walking without sliding and
similar. I think that this division needs to be maintained - you will
not be able to devise a "one size fits all" scheduler that will be
efficient, sufficiently flexible and not a crazily complex monster.
The end-of-animation notification/callback is important for the AI or
animation driver to know when to start a next action - that could be an
animation or something else. This is something Cal3D doesn't have and
one needs to resort to inefficient polling.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEsdFn11XseNj94gRAoenAJ9nQCfD4jBEoU2+LRgEtPB2XQqyPgCgsN/+
VqfggL06xVJ5F0rr0eS9Dco=
=20Eq
Cedric Pinson
is valid today but will play 17 seconds because duration is last key time - first key
I can add a method animation->setDuration(30); then it will be what you want. And if you
want it in the osg file there is no problem to add it too.
>
> With just three keys I have fully specified the animation, without any
> implicit assumption about the duration or framerate. Moreover, there is
> no need to maintain a long stream of interpolated keyframes anywhere -
> the animation engine still needs to interpolate between them in real
> time, so why not exploit this for storing the animations too. With your
> approach I would need 30 keys (assuming one key/second) - 10x more data.
>
> Your naive approach will simply not scale once you have to deal with
> many animations coming from different sources with different framerates
> (mocap, hand-animated, procedurally generated, different project, online
> repositories, etc.). You cannot assume that everything will pass through
> a converter that will normalize the framerate and pre-calculate the
> interpolated keys for you - that is just impractical and costly.
>
> Also, I have noticed that you have included scale keys. If you want only
> rigid bones (the most common case, one rarely models something like the
> "Gummi bears"), then you can drop both scale and translation. The
> quaternions/rotation matrices/rotation vectors are enough, together with
> the binding pose of the skeleton. You just apply the transformations
> recursively from the root of the hierarchy each time. That allows a very
> compact representation.
>
>
I think you did not read the examples code, there is not need to fill
the time with a lot of keys...
code from osganimationskinning:
osgAnimation::Animation* anim = new osgAnimation::Animation;
{
osgAnimation::QuatKeyframeContainer* keys0 = new
osgAnimation::QuatKeyframeContainer;
osg::Quat rotate;
rotate.makeRotate(osg::PI_2, osg::Vec3(0,0,1));
keys0->push_back(osgAnimation::QuatKeyframe(0,osg::Quat(0,0,0,1)));
keys0->push_back(osgAnimation::QuatKeyframe(3,rotate));
keys0->push_back(osgAnimation::QuatKeyframe(6,rotate));
osgAnimation::QuatSphericalLinearSampler* sampler = new
osgAnimation::QuatSphericalLinearSampler;
sampler->setKeyframeContainer(keys0);
osgAnimation::AnimationUpdateCallback* cb =
dynamic_cast<osgAnimation::AnimationUpdateCallback*>(right0->getUpdateCallback());
cb->setName("right0");
osgAnimation::QuatSphericalLinearChannel* channel = new
osgAnimation::QuatSphericalLinearChannel(sampler);
channel->setName("quaternion");
channel->setTargetName("right0");
anim->addChannel(channel);
}
3 keys for 6 seconds it's what you want isn't it ? and it animate only
the quaternion, not the scale and not the position.
{
osgAnimation::QuatKeyframeContainer* keys1 = new
osgAnimation::QuatKeyframeContainer;
osg::Quat rotate;
rotate.makeRotate(osg::PI_2, osg::Vec3(0,0,1));
keys1->push_back(osgAnimation::QuatKeyframe(0,osg::Quat(0,0,0,1)));
keys1->push_back(osgAnimation::QuatKeyframe(3,osg::Quat(0,0,0,1)));
keys1->push_back(osgAnimation::QuatKeyframe(6,rotate));
osgAnimation::QuatSphericalLinearSampler* sampler = new
osgAnimation::QuatSphericalLinearSampler;
sampler->setKeyframeContainer(keys1);
osgAnimation::QuatSphericalLinearChannel* channel = new
osgAnimation::QuatSphericalLinearChannel(sampler);
osgAnimation::AnimationUpdateCallback* cb =
dynamic_cast<osgAnimation::AnimationUpdateCallback*>(right1->getUpdateCallback());
cb->setName("right1");
channel->setName("quaternion");
channel->setTargetName("right1");
anim->addChannel(channel);
}
3 keys for 6 seconds it's what you want isn't it ? and it animate only
the quaternion, not the scale and not the position.
But the code i know is not very easy to read, some effort will have to
be made in this direction.
This format is used as source then depending of the skinning you want
software or hardware,
there is format generated that fit better for each implementation.
Currently there is only software.
For software it builds a set of matrix by set of vertex, then after it
means only one matrix per vertex. do optimize
like that It requires to pre process a little the source vertex group.
The format you propose is better for hardware
skinning ready to play. But less for software preparation of data. so
because i started with software skinning
i did it in this way.
> Your format will be also pretty hard to translate to a vertex shader -
> there you need for each vertex all the bones and weights that are
> affecting it so that you can transform it. However, what you have is a
> list of vertices for each bone instead, requiring a costly run-time
> conversion.
>
It's not so costly, and even in cal3d there is process to prepare that
for gpu (even if i guess it's less expensive than what i would need to do).
It's not new. Because source of my data is less prepared than what you
suggest, it will be little harder.
Anyway the format can't be adapted for all ready to use case, so yes
there will be code that will prepare data for gpu.
>
>>
>>
>>> You are right, it's not yet here, it's the next thing i plan to do.
>>>
>
> OK
>
>
>>> Of course it's essential too, it's in the pipe too
>>>
>
> OK
>
>
>> - 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 :)
>>>
>
> Well, as I said - with your current architecture this will be hard to
> do. Look at how Vladimir did it for osgCal (Cal3D does software skinning
> only). I know that the GPL version of osgCal had hw skinning as well.
>
No it will not so hard.
Ok i listen when you say that what you want is only to manipulate a
mixer. I always
need to prepare sequence, so i guess it was right for most usage, but ok
i understand what
you want.
> ReplicantBody is implemented as described above - Cal3D deals with the
> low level stuff and Replicant strings the animations together into
> actions, including things such as proper walking without sliding and
> similar. I think that this division needs to be maintained - you will
> not be able to devise a "one size fits all" scheduler that will be
> efficient, sufficiently flexible and not a crazily complex monster.
>
> The end-of-animation notification/callback is important for the AI or
> animation driver to know when to start a next action - that could be an
> animation or something else. This is something Cal3D doesn't have and
> one needs to resort to inefficient polling.
>
Yes
> Regards,
>
> Jan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFJEsdFn11XseNj94gRAoenAJ9nQCfD4jBEoU2+LRgEtPB2XQqyPgCgsN/+
> VqfggL06xVJ5F0rr0eS9Dco=
> =20Eq
> -----END PGP SIGNATURE-----
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:morn...@plopbyte.net http://www.plopbyte.net
Alberto Luaces
> Also, I have noticed that you have included scale keys. If you want only
> rigid bones (the most common case, one rarely models something like the
> "Gummi bears"), then you can drop both scale and translation. The
> quaternions/rotation matrices/rotation vectors are enough, together with
> the binding pose of the skeleton. You just apply the transformations
> recursively from the root of the hierarchy each time. That allows a very
> compact representation.
I think scaling bones is an important feature at least meanwhile a morphing
system is not available (face gestures, breathing movements, etc)
Regards,
Alberto
Jan Ciger
Hash: SHA1
Alberto Luaces wrote:
> I think scaling bones is an important feature at least meanwhile a morphing
> system is not available (face gestures, breathing movements, etc)
>
If you need that then you are better off implementing morphing and not
deforming the skeleton. Doing it by scaling bones will break lot of
things that rely on the fixed bone length - e.g. inverse kinematics,
walking cycles, the skin will look bad etc.
Furthermore, morphing gives you better control over subtle movements
like face animation than the rather rough and coarse skeleton skinning.
BTW, my comment to Cedric was a suggestion only, I am not sure what
exactly is his goal. But for about 90% of applications rigid bodies are
sufficient, if you add morphing you are almost completely covered minus
some really special cases.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJEx/Vn11XseNj94gRAn/4AJ91PpPWBPgWYwupNMtnBbJKg4FnawCeOYSV
YnhZkDWhVjam2U70NZLkIms=
=jVW6
-----END PGP SIGNATURE-----
Alberto Luaces
> Alberto Luaces wrote:
> > I think scaling bones is an important feature at least meanwhile a
> > morphing system is not available (face gestures, breathing movements,
> > etc)
>
> If you need that then you are better off implementing morphing and not
> deforming the skeleton. Doing it by scaling bones will break lot of
> things that rely on the fixed bone length - e.g. inverse kinematics,
> walking cycles, the skin will look bad etc.
Well, I was referring to dedicated bones, not the principal ones from the
skeleton. Think of an arm whose biceps changes its shape when bending: you
might put a special bone to reflect the "growth". Therefore you get the
effect of a deforming body without affecting IK, etc. I've seen places where
this is done so. However I admit that this could be the "poor man" approach,
useful when one has memory or cpu constraints.
Regards,
Alberto
Jan Ciger
Hash: SHA1
Alberto Luaces wrote:
> El Jueves 06 Noviembre 2008ES 17:48:24 Jan Ciger escribió:
> Well, I was referring to dedicated bones, not the principal ones from the
> skeleton. Think of an arm whose biceps changes its shape when bending: you
> might put a special bone to reflect the "growth". Therefore you get the
> effect of a deforming body without affecting IK, etc. I've seen places where
> this is done so. However I admit that this could be the "poor man" approach,
> useful when one has memory or cpu constraints.
I see your point, however, I think doing skinning is more expensive than
just a simple interpolation between morph targets, due to more data
being processed. You save a bit on implementation time, but the skinning
math at runtime is not free.
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJFAf9n11XseNj94gRAi/hAJ0c17f1VDQoYchSmjLG3M3DQy16xwCg5ijh
noRAjNvRgfnzv1X+Se2TgVA=
=tGL4
-----END PGP SIGNATURE-----