OgreXml loader fails to create a SkeletonSubMesh

[GoogleCodeExporter]

Hello,

I'm having a hard time to load a ogre mesh with shared vertices and bone 
assignments.

It seems that if you have a ogre mesh with shared vertices the bone assignments 
is global attribute for the mesh and not per submesh. Not sure actually how to 
make the bone assignments per sub mesh with the blender/ogre exporter.

The following check at OgreXmlLoader fails to detect this and always creates a 
StillSubMesh.

boolean hasSkeleton = ogreSubmesh.getBoneassignments() != null;

if (hasSkeleton) {
    subMesh = new SkeletonSubMesh("", mesh, GL10.GL_TRIANGLES);
} else {
    subMesh = new StillSubMesh("", mesh, GL10.GL_TRIANGLES);
}

Then you will get a exception at:

Caused by: java.lang.ClassCastException: 
com.badlogic.gdx.graphics.g3d.model.still.StillSubMesh cannot be cast to 
com.badlogic.gdx.graphics.g3d.model.skeleton.SkeletonSubMesh
    at com.badlogic.gdx.graphics.g3d.model.skeleton.SkeletonModel.<init>(SkeletonModel.java:39)

Maybe the following could be done to fix it, but then im not sure the bones 
will load correctly, only gave a quick look at the code:
boolean hasSkeleton = (ogreSubmesh.getBoneassignments() != null)||
(ogreMesh.getBoneassignments() != null);

Original issue reported on code.google.com by frust...@gmail.com on 24 Oct 2012 at 2:26

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Well it seems the current exporter 
(http://www.ogre3d.org/forums/viewtopic.php?f=8&t=61485) only supports shared 
vertices probably for performance reasons.
So alternatives would be to use older tools or fix the issue :)

Original comment by frust...@gmail.com on 24 Oct 2012 at 3:24

[GoogleCodeExporter]

Forgot to mention, i'm using blender 2.63 and libgdx trunk

Original comment by frust...@gmail.com on 24 Oct 2012 at 3:27

[GoogleCodeExporter]

Found out that this loop is just plain broken and fails with multiple animation 
tracks. Misspelled i for j.

private Skeleton generateSkeleton 
(com.badlogic.gdx.graphics.g3d.loaders.ogre.skeleton.Skeleton ogreSkel) {
...
for (int j = 0; j < perJointkeyFrames.length; j++) {
if (perJointkeyFrames[i] == null) throw new IllegalArgumentException("No track 
for bone " + skel.jointNames.get(j));
}

Original comment by frust...@gmail.com on 26 Oct 2012 at 12:25

[GoogleCodeExporter]

Also it seems that both OgreXmlLoader and G3dLoader.loadSkeletonModel forget to 
set the mesh/subMesh names.

Maybe we can have a rampage fix all at once. :)

Original comment by frust...@gmail.com on 26 Oct 2012 at 12:28

[GoogleCodeExporter]

The Ogre loader was modified/rewritten by some contributor via Github. I 
haven't had time looking into that and it's unlikely i'll have time in the next 
2-3 weeks. I plan on using the Gameplay SDK format in the future, as it's a 
binary format, easy to load, and the encoder work is done by the great folks at 
RIM who have more resources than we do. This would make the Ogre loader 
obsolete, you'd export to either Collada or FBX.

Original comment by badlogicgames on 26 Oct 2012 at 1:50

[GoogleCodeExporter]

Not sure about that new sdk, seems to be a "complete" solution for mobile games 
rather then something only for the models. Integration with libgdx is going to 
be a pain. Also RIM is going trough bad financial times. 

Then i have to quote you. "DAE (aka Collada): oh god, please. No." 
http://www.badlogicgames.com/wordpress/?p=1652

I think libgdx should focus on one solution that works well, dont need to be 
perfect on this, because right now 3d support is a mess of things that are 
barely working.

I would stick with Blender->Ogre->g3d. You can skip the whole ogre stuff as 
well by just making a complete exporter for blender that's totally under libgdx 
control.

Original comment by frust...@gmail.com on 27 Oct 2012 at 2:03

[GoogleCodeExporter]

As much as i like blender, only supporting Blender doesn't cut it. Also their 
API is i  constant flux and i have no intention following that every month.

The Gameplay SDK based solution means exporting fbx/collada from whatever app, 
and converting that to a game ready binary format via the Autodesk FBX SDK. 
This is what Unity and the UDK do as well, ans it's the most future-proof and 
generic solution. Folka would simply use the Gameplay encoder to convert their 
fbx/collada files and we only have to maintain a single loader for that format.

yes, the 3D Api is a mess, as i stAted numerous times. Sadly, i do not work on 
libgdx full time and i have to prioretize things accordingly. However, i always 
welcome contributions.

Original comment by badlogicgames on 27 Oct 2012 at 3:11

[GoogleCodeExporter]

Okey.. got inspired and fixed all the problems.

https://github.com/libgdx/libgdx/pull/92

My game is mainly 2d, but i'm using some 3d elements in the menu system and 
don't really need anything more fancy than blender-ogre stuff.

Original comment by frust...@gmail.com on 28 Oct 2012 at 7:20

[GoogleCodeExporter]

Original comment by badlogicgames on 3 Nov 2012 at 11:52

• Changed state: Fixed