next »

[kukanani]

Marvin,

I have some files that I need committed for COLLADA.  They are attached.  The files are:

org.xith3d.loaders.models.impl.dae.DaeLoaderTest
org.xith3d.loaders.models.impl.dae.Model
org.xith3d.loaders.models.impl.dae.Converter

Could you commit these, please?

Thanks.

[Marvin Fröhlich]

Of course I would do this. But you attached the .class files instead of the .java ones .

Marvin

[kukanani]

Oops. 

Here are the JAVA files.

But, also, I have to say that I'm putting down this project.  I am spending expansive amounts of time getting nothing done on this loader.  So, we now have a COLLADA loader that works in about the same way as the rest of our model loaders...except that animations are loaded, just not shown.

Can someone else please pick this up?  I know that Xith needs it done so badly, but I don't have the expertise to finish it.

[Marvin Fröhlich]

I have committed your files.

Marvin

[Marvin Fröhlich]

With which model do you test the loader? The ones to be chosen through the testcase don't load at all for me.

Marvin

[kukanani]

Sorry...I forgot to commit my last fix.

All of the models should work now.

[Marvin Fröhlich]

Yap. Works now. Thanks.

Well, transparency looks odd. But this shouldn't be too hard to fix. Maybe I will find some time to have a look at the loader in the next weeks. But I cannot promise anything. I don't know, how much time I will have and I don't know too much of animations.

Marvin

[t_larkworthy]

If I understand your question about influences, I think in most skeletal vertex formats the influence of a bone on a vertex dictates how much the vertex moves in relation to the bone. So verteces at joint positions like the elbow will both move in relation to both nearby bones. Their position is like a weighted average. This essentially means that their positions cannot be neatly hung off a transform group. Any vertex whose position is 100% determined by a single bone position could be neatly hung of a transform group, but those are the special cases (still optimizeable tho).
Not sure if you could manage a way around this. You would need a special tranform group that could have multiple logical parents. On the surface that seems impossible, but their might be a cheating way a bit like the link scene node.

EDIT: Just popped in becuase I was struggling to get Xith working since I resynced my JOODE, Xith, Openmali setups. Eventually with a few restarts my IDE started playing game again. Err, so I will probably dissapear again like a ghost. See ya!

[Marvin Fröhlich]

If I understand your question about influences, I think in most skeletal vertex formats the influence of a bone on a vertex dictates how much the vertex moves in relation to the bone. So verteces at joint positions like the elbow will both move in relation to both nearby bones. Their position is like a weighted average. This essentially means that their positions cannot be neatly hung off a transform group. Any vertex whose position is 100% determined by a single bone position could be neatly hung of a transform group, but those are the special cases (still optimizeable tho).
Not sure if you could manage a way around this. You would need a special tranform group that could have multiple logical parents. On the surface that seems impossible, but their might be a cheating way a bit like the link scene node.

Well, this kind of special TransformGroup would only be faster than transforming each vertex and sending it to the card, if there were at least some (let's say 50 or 100) vertices, that could be put into the same TG. I don't think, this would be a feasible solution.

Thanks for clearing me/us up, Tom.

Marvin

['n ddrylliog]

Marvin, oh marvin, why do you want do everything CPU-side ?

Skeletal animation is particularly interesting when it is run on the card, with vertex shaders.
The shader program should know :
- The skeletal structure / connection information (e.g. bone hierarchy & length and initial transformation matrix)
- The animation that you are trying to play, and the current time

One can find a good example of such a shader here : http://animadead.sourceforge.net/ (in CG and GLSL, but only the GLSL one is working, which should be fine for you, Marvin).

[Marvin Fröhlich]

Yes, this would be better.

Marvin

[Marvin Fröhlich]

I have investigated the current state of the COLLADA loader. And I think, I understood it up to a certain point. I found the code, that handles the animation part, but it is less finished than I expected. the influences are not applied to the vertex data. Unfortunately I don't know, how to do that. If that is done, the animations should already work. Well, not very efficiently, since data is copied through the whole world all the time. This MUST be improved to make this loader usable with animations.

@Kukanani or Amos: Can you tell me, how to apply an influence to the vertex data? An influence has a bone-index. But how do I get the correct bone from the skeleton by this index? Is it done through a depth-first-search through the skeleton's bone-hierarchy? In this case we should cache the resulting list of bones in a flat array to avoid depth-first-searches again and again.

I think, I know, how to handle the weight parameter. I guess, I just have to multiply the transformation by that factor. That should be it.

Any thoughts?

Marvin

[Marvin Fröhlich]

A little update...

Now I do understand, how to assotiate the bone-index to the actual bone. but I don't get, how to compute the actual transformation for that bone.

Any help is greatly appreciated.

Marvin

[kukanani]

Can you tell me, how to apply an influence to the vertex data? An influence has a bone-index. But how do I get the correct bone from the skeleton by this index? Is it done through a depth-first-search through the skeleton's bone-hierarchy? In this case we should cache the resulting list of bones in a flat array to avoid depth-first-searches again and again.

Unfortunately, I got stuck in this exact same place.  I wish I knew the answers to those questions...in that case I would have probably finished the loader long ago.

['n ddrylliog]

Well, usually, I'd answer RTFM (here, it's rather the f*cking specs), but for COLLADA, your mileage may vary since implementations all have they very own personality.

So.. my advice is simply to reverse-engineer. Make several test models under Blender with particular hierarchy of bones, and different anims, you'll soon figure out how bones are indexed. Isn't it possible ?