next »

[kukanani]

At this point, I don't know how many different people have worked on the JaGaToo COLLADA loader...at least 3.  But anyway, I have realized that the "1.0 Features" thread, the two remaining things un-implemented are COLLADA animation and network code.

Pandemonium is working on net-code, so to COLLADA...

I've kind of hit a brick wall with the loader.  My math and XML knowledge doesn't reach far enough to finish that last bit of un-done code.  Does someone else want to pick up the project, finish it, and be hailed as "the guy who finally finished that COLLADA loader"  ? 

Here's the current info on the loader: all animation is loaded correctly AFAIK.  The problems are in the actual animation implementation...which means that the mesh vertices aren't moving.  That is the main thing left to be finished.  The only other thing that is incomplete is the list of actions, which means that the skeleton cannot play a specific animation, but this is trivial compared to the actual lack of movement by the models.

So, any takers? 

--Kukanani

[Marvin Fröhlich]

Hmm... I don't say, I want to take over this subproject. But maybe I can help with some simple tips. The problem about non-moving vertices doesn't sound like a real problem. But could you please explain it a little more in detail?

Are you applying any kind of transformation to the vertices? Are the vertices transformed, but the transformation is simply not visible? If this is the case, you might want to try disabling the geometry optimization. If this helps, we can see, how to get it working with geom-opt or if it is even better to live without.

Marvin

[kukanani]

The problem about non-moving vertices doesn't sound like a real problem. But could you please explain it a little more in detail?

Well, It's not exactly a problem, it's just not implemented.  The truth is that I can't find out where the mesh vertices are stored, and so I can't transform/adjust them.  From what I can tell, here are about 20 possible places for the vertices' locations to be stored, and I can't find out exactly which one is the "right" one.

--"Kuk"

[Marvin Fröhlich]

Well, It's not exactly a problem, it's just not implemented.  The truth is that I can't find out where the mesh vertices are stored, and so I can't transform/adjust them.  From what I can tell, here are about 20 possible places for the vertices' locations to be stored, and I can't find out exactly which one is the "right" one.

Ah, ok. I could possibly have a look at that tomorrow, if you tell me, where I should start looking at.

Marvin

[kukanani]

Hehe...actually, I think I found which one it is.  I have comitted changes to JaGaToo, look at line 250 in SkeletalGeometry.

Edit: it now starts at line 242 - I cleaned the code.

[Marvin Fröhlich]

ok, I will. Thanks.

Marvin

[Marvin Fröhlich]

I had a look at the code. And apart from the fact, that no transformations seem to be applied to the vertices so far, your actual problem seems to be, that you don't know how to apply the transformed vertex data back to the Xith-Geometry. Is this correct?

I would suggest to have a look at org.xith3d.loaders.models.impl.md5.MD5Model.interpolateAnimation(float). In the last for loop of this method the vertices are transformed by the internal model, which is triggered in line #167. Then the buffers are  simply set to the Xith Geometry. Alternatively you could also set the buffers' data by calling something like geom.setCoordinates( 0, myFloatVertices ) and geom.setNormals( 0, myFloatNormals ), etc.

Does this help?

Marvin

[AotFSteven]

Kukanani I had a question for you, I don't know if the COLLADA stuff has made it this far, but will there be support for animations that are not stored in the object?  In other words, can animations and/or transformations be done dynamically at run time.  I don't really know anything about COLLADA or any 3D modeling for that matter, but I imagine that being able to dynamically store animations in a database rather than the model object/file(s) itself would be quite powerful.  Good job by the way, I am looking forward to messing around with modeling, COLLADA and your new loader once I get some free time.

[kukanani]

...I imagine that being able to dynamically store animations in a database rather than the model object/file(s) itself would be quite powerful.

Yes, it would be quite powerful.  Perhaps something like storing all-purpose animations for multiple characters to avoid repetition.  I'll tell you what.  I will assess that...after I'm done getting the standard loader to work.

--Kuk

[Marvin Fröhlich]

Oh, this brings an idea back to my mind, that I had multiple times. Why do all advanced loaders directly manipulate the vertex coordinates? When I ported the MD5 loader to JAGaToo I discovered the same behavior and all, that was applied to the coordinates was a uniform transformation (the same for all vertices).

This could also be done through a TransformGroup. Therefore the animated part of the model would have to be split from the rest of the geometry and put into its own shape, which is then put into a new TransformGroup, which handles the animation's transformation. The more vertices are affected by an animation, the greater the advantage of this way will be.

And there is another very important advantage, that this solution would give us: What if you want to use many copies of the same model? This is a very common situation as you all know. To do this in the most efficient way we have to share the model's geometry. But we cannot share the geometry, if it is directly manipulated by an animation.

Additionally we were able to use optimizations like display lists or VBOs, if the geometry was static (only transformed through matrices).

Is there a good reason, why this is/isn't done like this? Are the "influences" - as they are called in the COLLADA loader - not always uniform transformations?

Marvin

[kukanani]

Actually, I have no idea why it's done this way.

I guess it might be because it's easier to code that way...that's all I can think of.

"influences" are just how each bone affects each vertex.  I don't know how that relates to what you are talking about.

Oh yeah, also, I just can't seem to see any changes on the model's geometry, even though I'm trying to do everything I can to adjust the vertices...I want to see any change right now, not necessarily as dictated by the bones.

[Marvin Fröhlich]

How do these influences look like? That's the interesting question. If they are simply transformations (matrices or quaternions), it would be much simpler to achieve a good result and much better in the end.

Marvin

[kukanani]

Well, the Influence class stores only two values: a Bone and a float weight.  Then the function XMLSkin.buildInfluencesForVertex(int vertex) is called to set up the influence for that particular vertex...from there, it all depends on what the bone's keframe is.  So, no, the Influence is not a transformation or matrix.  See org.jagatoo.loaders.models.collada.datastructs.controllers.Influence.

Hope this helps.

--Kuk

[Marvin Fröhlich]

Well, the Influence class stores only two values: a Bone and a float weight.  Then the function XMLSkin.buildInfluencesForVertex(int vertex) is called to set up the influence for that particular vertex...from there, it all depends on what the bone's keframe is.  So, no, the Influence is not a transformation or matrix.  See org.jagatoo.loaders.models.collada.datastructs.controllers.Influence.

Yes, I know this class. And the question was not, if the influence IS a matrix, but if it can be described as a matrix. Sorry, that I wasn't clear enough. A 4x4 matrix describes a full projectional transformation in a 3-dimensional space. A Quaternion and a vector describe the rotational and translational parts of a full transformation.

You can describe describe the whole "move" from vertex(index, time1) -> vertex(index, time2) by a transformation matrix, if the transformation is equal for all affected vertices.

So let's say, vertex A is translated by (-1,0,0) for time span dt while vertex B is translated by (+1,0,0) and vertex C is rotated by 0.123pi about some axis at the same time. Since these three vertices are transformed by completely different rules, yiou cannot describe all these rules at once by a single uniform transformation (-matrix). You see?

I guess, it would be hard to tell, if the COLLADA influences for a set of vertices can be described as transformation matrices, since you would have to know, where the influences come from. But I was hoping, it is described somewhere in the COLADA docu.
But since the influences seem to be made for non-uniform transformations, we will not be able to treat them like uniform onces. But maybe you can detect that. It really would help with performance.

Directly manipulating the vertex coordinates and normals means to send these data over the bus to the graphics card each frame. This is the worst case and should be avoided. It also makes COLLADA relatively useless for complete scenes, where most of the geometry is completely static. Except if we would manually detect the static parts or assume, that the whole model is static (detectable by no animations being found) and manually enable geometry optimizations.

Well, I would prefer to do as little as possible manually. So it would be nice, if the model would give us enough information about being static and/or being dynamic and in what way. Got my point?

Marvin

[kukanani]

Yes, I know this class. And the question was not, if the influence IS a matrix, but if it can be described as a matrix. Sorry, that I wasn't clear enough. A 4x4 matrix describes a full projectional transformation in a 3-dimensional space. A Quaternion and a vector describe the rotational and translational parts of a full transformation.

You can describe describe the whole "move" from vertex(index, time1) -> vertex(index, time2) by a transformation matrix, if the transformation is equal for all affected vertices.

So let's say, vertex A is translated by (-1,0,0) for time span dt while vertex B is translated by (+1,0,0) and vertex C is rotated by 0.123pi about some axis at the same time. Since these three vertices are transformed by completely different rules, yiou cannot describe all these rules at once by a single uniform transformation (-matrix). You see?

Ok, now I get what you're saying.

I guess, it would be hard to tell, if the COLLADA influences for a set of vertices can be described as transformation matrices, since you would have to know, where the influences come from. But I was hoping, it is described somewhere in the COLADA docu.
But since the influences seem to be made for non-uniform transformations, we will not be able to treat them like uniform onces. But maybe you can detect that. It really would help with performance.

Well, unfortunately, I don't think there's a way to find that out.

Directly manipulating the vertex coordinates and normals means to send these data over the bus to the graphics card each frame. This is the worst case and should be avoided. It also makes COLLADA relatively useless for complete scenes, where most of the geometry is completely static. Except if we would manually detect the static parts or assume, that the whole model is static (detectable by no animations being found) and manually enable geometry optimizations.

I agree entirely.  The current COLLADA loader implementation already will notice if there are no animations and assumes it's a static model, so that can be addressed a bit later.

Well, I would prefer to do as little as possible manually. So it would be nice, if the model would give us enough information about being static and/or being dynamic and in what way. Got my point?

Right, I got your point.
Unfortunately, I don't know where to find this info.  I know that you're busy with studying for your examination, so I won't ask you to help.  Good luck for the 15th  .

--"Kuk"