Hi Jason,
Thanks for answering. As I said I'm looking into osgAnimation, the goal
is to see if it would fit our needs to do some basic character
animation. Our needs will probably grow with time, of course, which is
why I want to see if the content-creation pipeline would work for us and
also if osgAnimation would scale well enough to be future-proof for a
reasonable amount of time.
We were also looking into DIGuy, they say it integrates easily into OSG
but I'll have to see if it does hardware skinning, and also the runtime
licensing costs seem pretty high. I would prefer osgAnimation, but only
if it can be proven reasonably stable and if we can get our content into
it easily.
We don't use osgAnimation (yet),
What do you use? Your own code?
The Collada spec is kind of flexible on
how multiple animations are handled on a single character in the same
document. It seems as if it's up to the application to determine how it
wants to interpret the library_animations hierarchy.
I've been investigating the fbx format as a way of getting the models
and animation into OSG, and something similar to the above seems to be
happening with that format too. It's giving me a bit of trouble right
now... Here's what I'm seeing:
1. The fbx sample model (with the walk cycle) downloaded from the XNA
site works well in osganimationviewer (I have to convert it to .osg and
set all Material diffuseColor alphas to 1, see the other thread, but
osgconv understands that fbx model well)
2. If I import the fbx file into XSI Mod Tool and re-export it in fbx
format, then the fbx plugin (either through osgconv or
osganimationviewer) asserts when trying to read it. The file size is
similar but not the same as the original fbx file I downloaded, so I
assume XSI moves things around in the hierarchy when importing or
exporting the file that makes the fbx plugin not understand the file
anymore...
I don't have time to debug the plugin right now to see what changes in
the file's structure between step 1 and 2, but I'd like to, just so that
the plugin would work with XSI (which is my personal favorite 3D app,
even though I'm not a modeler/artist in any way).
From my experience, hardware skinning is critical. For models of decent
complexity (a couple thousand verts), the CPU just isn't up to the task
if you get more than a couple of them on screen (at least not without
significant efforts to optimize the code, but writing a vertex shader is
a lot easer).
That's what I thought. Hopefully Cedric will be able to find and fix the
problem that makes it crash and I'll be able to have a look.
Thanks,
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
