Given all the problems with the ASE converter, I wrote my own. It properly supports nodes, hierarchy, multiple materials, etc. It does not support vertex colors (although that would be easy to add). It also doesn't derive from the converter superclass/interface, mostly because I haven't bothered yet. I wanted to include the source below, but there's a 20,000 character limit. It also would require my recent patch to the binary capsule nio array writing.
I then looked at supporting animation with skinning, but it appears that the ASE exporter in Max in broken. When I export animation, the translation of a node comes out just fine, but the rotation doesn't export correctly. Bummer!
So… I'm still up the creek without a paddle when it comes to getting animated, skinned objects out of 3ds Max and into jME. The COLLADA importer doesn't support DAE files exported from Max. 3ds doesn't have it. There's no .X importer. Max can't write Milkshape files (well, duh!).
Help?
Btw: it turns out I was mis-understanding the ASE export format. The rotation keys are each relative to the previous key. Thus, it is possible to export an animated ASE. However, ASE doesn't support skinned meshes, so only rigid animations are supported (wheels spinning on cars, turrets on tanks, etc). I might still add that support to my ASE exporter.
Oh, and now that my BinaryOutputCapsule patch is in, I might be able to contribute the code somehow.
I have done some work on creating a working Blender->jME skeletal animation bridge. Not by using collada, but a custom xml format for simplicity. Unfortunately I ran into some problems which seem to be at the level of jME's internal skinning system, documented here:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=6277.new;topicseen#new
If I am right assuming that at the root of my problems there are one or more bugs in jME's skinning system, you will most probably run into those problems too, that's one reason why I linked the thread here. The other is, to shamelessly plug my cry for help into a more recent thread. Sorry.
I read the code for the animation controllers and the skinning implementation last night, and the system is not how I would implement it. Can't say I saw an obvious bug, unless you count the fact that it's not currently possible to put skinning into vertex shaders with the way it's done in jME.
Regarding the "last frame index" bit, that's actually how I would implement it, too. Just like arrays of length N don't contain the N-th element.
jwatte said:
Regarding the "last frame index" bit, that's actually how I would implement it, too. Just like arrays of length N don't contain the N-th element.
But that's not really the problem, it was only somebody else misunderstanding me. The actual problem is that the last, or (N-1)-th element, is not accessible.
Maybe you're right, and yet another skeletal animation system is needed. Animation blending isn't exactly easy to implement with the current system either, from what I've seen.
Hm, so a new skeletal animation system should be added to the jME 2.0 todo list?
I don't care if it's "new" or "re-worked," but something that caused less cache misses, and also could be used to drive a vertex shader, would be swell. The basic loop of transforming vertices is very easy, assuming you're given indices and weights per vertex, and an array of transform matrices. Another part is the generation of that array of matrices – that's the job of the animation system, but right now it's not set up to do that in an easy way.
Here's some code for doing skinning animation: OpenGL Skinned Animation Sample
The hard work is all in the art path (exporter tool, etc).
Once the skeletal animation system and XML format are implemented it shouldn't be too difficult… I think that the system should be centered around how skeletal animation works in the current modeling tools (3dsmax, blender, maya) so that most compatibility issues can be eliminated.
Well I have a proof of concept blender exporter, xml format, and jME importer for the current animation system. That's something that can be used for now, and I can easily improve it to work better/faster/more complete in the future. Maybe we should start a new googlecode project or something?
sounds cool hevee… more jme addon projects please! 
We, of the MD5 Reader 2 team, are really interested in the bone animation system. So if we could help…
The only problem is that I am not C expert, so if it is necessary to investigate example C code (Blender 3D sources, for example) to understand what way to approach it could be hard for me.
Anyway there are a lot of 3D software we can learn from. 3D Ogre, Crystall Space, Blender…
The MD5 file format actually is not set up to be skinned in a vertex shader. The reason is that DOOM 3 needs the mesh outline on the CPU so that it can extract stencil shadow contours. Thus, DOOM 3 characters are also fairly low poly, but with lots of normal/gloss mapping to make it look OK anyway.
Regarding the initial request: I have now completed my own ASE converter; it supports animation, although only a custom animation controller, not the JME controllers (I didn't have time to make that work – it was faster to write my own
The source is available, MIT license, from googlecode: http://code.google.com/p/jmefromase/downloads/list
It also comes with a simple MeshViewer that lets you pick a mesh and look at it, playing the animation if present.
Actually, I haven't tried it with textures in a while (been too busy with the animation), so if that's broken, there might have to be a release 2…
Textures work, but there's some weirdness with certain nodes in a hierarchy when their base transform is rotated off kilter. There is no ASE documentation, so I'll have to reverse engineer this some more. It's still a heck of a lot better than the built-in barely functional ASE converter, though!
nice! seems like something we should replace the old stuff with when it's "done", if that's something you would agree on…
Oddly enough, we did a much better (but I'm sure still incomplete) version of the ASE loader (separate from jmex.model) here but got too lazy to integrate it with CVS :( Maybe I can salvage parts of that to help if you have any holes in what you are working on.
The only thing missing now is a full understanding of what model space the normals are exported in. Because vertices and node translations are exported in world space, I go through and apply the inverse world transform to all vertices when baking the trimesh. I also apply the inverse transpose of that inverse transform to the normals, but they don't come out quite right for some nodes – and come out perfectly for others.
So – do you know what space the normals are stored in?
jwatte you seem like somekind of 3d graphics guru 
Might one ask what kind of project you are working on?
Flattery won’t get you anywhere
My day job is here. But I don’t do much graphics there anymore; it’s more like Powerpoint and Outlook run my life these days. Gotta get my coding itch scratched somewhere, which is why I’m trying to learn as many game engines as I can.
Btw: I came to the conclusion last night that the information to recover the normals transform space isn’t actually in the ASE file. Thus, I have to use the smoothing groups to do it myself. Sigh.
>jwatte you seem like somekind of 3d graphics guru
No, jwatte seems like some kind of guru at practically everything :)
He also has no idea (yet) that he and I have actually met in person - about an eternity ago at a MacHack, if I remember correctly.
Sorry though, to see he's just poking around looking at jME, when I thought he might be preparing a super fantastic import/export tool using jME as a starting point. Oh well, I know his contributions to the community will be valuable.
Stan
jwatte said:
The MD5 file format actually is not set up to be skinned in a vertex shader. The reason is that DOOM 3 needs the mesh outline on the CPU so that it can extract stencil shadow contours. Thus, DOOM 3 characters are also fairly low poly, but with lots of normal/gloss mapping to make it look OK anyway.
Did I misunderstand or some of the participants to this thread spoke about changing jME bone animation system? I never spoke about using MD5 system.
Moreover, if you really plan to change jME bone system, what I only ask is to maintain support for some older OpenGL versions. I am not expert but some code could be broken in some systems with poor OpenGL support, if you base your code only on newer OpenGL features.