• Advertisement
Sign in to follow this  

Correctly parse Skeleton info from COLLADA file

This topic is 1331 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I faced with problem, that I don`t yet understand how to correctly parse data from library_controllers from COLLADA file and bind it to geometry info.

 

Could someone explain me some points on simple example with animated mesh? (Unfortunately I cannot upload here my file for some reason)

 

Note: for parsing I use autogenerated classes from xsd file for 1.4.1 version.

 

I have the following questions:

  1. which datatype I must create to correctly handle parsed info? I mean which struct must be for contatining bones info, weights and other
  2. help me understand <vertex_weights>

in <vertex_weights> there are at least 2 inputs - Joint and weight. Its OK. but what I must do with <vcount> and <v>?

What does they mean?

I have already successfully parsed geometry data from COLLADA, but here I feel myself as noob because have no idea how to correctly handle parsed info including matrices from <library_visual_scenes> for animated mesh.

 

Till now I worked only with static meshes.

 

 

Share this post


Link to post
Share on other sites
Advertisement

Hello, I had to tackle the COLLADA problem a month ago, so I can offer my experience :)

 

I have 5 structs which work together:

COLLADA - The main class holding everything together, contains arrays and methods to use the following classes...

MESH - The class containing the vertices, texture coords, faces, and a method to render them

CONTROLLER - Reads the matrices for binding and skinning

ANIMATION - This simply contains the animated matrices and methods to bind them to a skeleton

BONE - A simple class with 2 matrices, a local matrix, and a world matrix. These have children bones and a parent bone.

 

Now, to the vertex weights -

 

Every vertex is bound to 1 or more bones, so <vcount> is actually bone count per vertex, the following:
1, 3, 1, 2, 3, 4, 1, 2

would mean the first vertex in the mesh is bound to 1 bone, the second vertex is bound to 3 bones, etc

and <v> is the actual data for that binding, using the counts listed above, <v> would be layed out like:
[vertex 1: boneindex, bone weight]

[vertex 2: boneindex, boneweight,      boneindex, boneweight,       boneindex, boneweight]

[vertex 3: boneindex, boneweight]

[vertex 4: boneindex, boneweight,     boneindex, bonewieight]

Etc.

 

I hope I could help. My skype name is on my profile name if you need any more help!

 

 - Jonathan

Share this post


Link to post
Share on other sites

And <v></v> means number of value in weights array? Am I right? 

 

But what if I already optimized mesh and delete extra vertices? What then?

Edited by BlackJoker

Share this post


Link to post
Share on other sites
When you optimize the mesh, you must do one of two things - add the bone indices and weights to each vertex first, or create a map of old vs. new vertex indices. It may be less painful (less chance for error) to do the former. If you optimize before adding the bone weights to the vertices and generate a map (list) of old v. new indices, be sure to include an indication in the map for vertices that you delete. Then, for each entry in the bone info array, lookup the new vertex index in the table (checking whether that vertex survived the optimization), and add the bone info to the vertex at the new index position.

Share this post


Link to post
Share on other sites

I think also about such thing:

 

do optimization after skeleton will mapped with vertices. Then I will just delete all extra vertices with bone indexes and weights at one time. 

Share this post


Link to post
Share on other sites

I think also about such thing:
 
do optimization after skeleton will mapped with vertices. Then I will just delete all extra vertices with bone indexes and weights at one time.


IMHO that's the way to go. It may take just a bit more memory but the code is cleaner and less susceptible to a typo or index error. I can speak from experience that, if you have a few vertices with slightly incorrect bone indices or weights, you'll spend a lot of time finding the error.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement