I have pretty much exhausted all my ideas and attempts to solve this problem and I'm at a dead end. Something with my character model or animations must be incompatible with Esenthel.

I have successfully imported character models with animation in the past and been able to get them to work so I fully understand the workflow.

My problem is I have a character that I have animations for all of the standard esenthel animations created. I import the model and the animations and everything looks good in the editor. All animations play fine. I set the ones to loop which need to loop. I set the anim parameters in the object for each animation. However, when I run the code and put the character object in the world, the animations do not play completely. By this, I mean some of the bones animate and some do not. The head and body might animate but the arms and legs do not. In the editor, the entire skeleton animates correctly.

I also checked in debug that when the character object loads in the game, the sac animations are loaded for the character.

Any suggestions?

Can you post the code and animations you are using?

Actually, I realized I have not really exhausted all of my attempts at trying to make this work. I need to attempt to create this character object in the animations tutorial and see what happens there. That way the code can be eliminated as an issue.

There's also something you can think about (Esenthel, correct me if I'm wrong) : the engine seems to allow animation merging. You can play an head animation while the legs are playing an another cycle.
If it's true, I guess that if you play an animation cycle that doesn't have key frames set for a couple of bones, they might not get animated while the others do.
And the opposite can be a problem too... If you set an animation for your legs, and then an other one for your head... If the head animation cycle has some keyframes affecting the leg bones (maybe due to wrong baking animation export configuration?), you might overwrite the leg animation by something else.

I determined it is due to animation blending and I just need to fix some animations. However, I still have some issues that I don't really have a good solution for.

My model is in fragmotion format so basically my export options are fbx, b3d, or ms3d. When I export to fbx and import that to Esenthel, the bones look good but the animations get wacky. Exporting to b3d and importing to Esenthel results in messed up bones and I don't think animations export properly. Exporting to ms3d and importing to Esenthel works fairly well all the way around except for one problem. The base mesh has 4805 verts. In Milkshape3d, this is what is reported. When the ms3d is imported to Essenthel, it shows as having 23,192 verts. Using fbx and b3d, Esenthel shows 4805 correctly.

The best thing I can do right now (which has other problems I will have to solve) is exporting from Fragmotion to ms3d. Opening in Milkshape and exporting to b3d. This is the only way I am able to get the model in with correct animations. However, when I do this, the animation speed is doubled and the Y rotation is backwards. Things I can probably fix somehow but kind of a painful workflow process. Especially as I want to add more animations and cloth armor pieces, etc.

I decided to just use the ms3d format for importing to Esenthel. I get good results with that. The only thing that bothers me is the vertex count shown in the editor for any models imported from ms3d. It looks like any mesh imported from that format ends up with 3 * num faces vertices. However, many of those vertices should be shared with multiple tris. Is the import function truly creating duplicate vertices?

Greg - Can you confirm what the ms3d import does regarding shared verts?

Hi,

Can you attach all of the file formats?
FBX, MS3D, B3D
I'll check the vtx count once I have the file.

Since the model is part of a purchased pack, I cannot attach it in any format publicly. I can maybe put together something and attach in a PM to you.

As far as the ms3d vtx count, I can reproduce that very easily. I simply created a cube in Milkshape and imported into the editor. Milkshape reports 8 vertices and 12 tris. After importing into the editor, it shows as having 36 vtx. That would be 3 per tri. Some of those should be single vtx shared by multiple tris.

I have attached the test cube.

  test.zip (Size: 506 bytes / Downloads: 10)

Greg, I know you are very busy with lots of things so I'm not asking for you to put a priority on this. However, I just want to make sure it doesn't get forgotten. My concern with this thread is the vertex count with meshes imported from ms3d format. Just want to make sure you have this on your list to check when you get a chance.

Hi,
the difference in vertex count is probably due to "smoothing groups," or "face normals" or whatever it's called that causes the rise. The vertices get split to "preserve" the normals upon export to some file formats (also depends on the app itself from what I believe).
3x more vertices sounds about right, since each vertex connects 3 sides of the cube. As long as the triangle count stays the same and your normals look right, it's OK

Quote:However, seams in UVs, changes to shading/smoothing groups, and material changes from triangle to triangle... are all treated as a physical break in the model's surface, when the model is rendered by the game. The vertices must be duplicated at these breaks, so the model can be sent in renderable chunks to the graphics card.

Overuse of smoothing groups, over-splittage of UVs, too many material assignments (and too much misalignment of these three properties), all of these lead to a much larger vertex count. This can stress the transform stages for the model, slowing performance. It can also increase the memory cost for the mesh because there are more vertices to send and store.

...
polygoncount.com

I'll take a look at the importer I wrote for ms3d format in the past. If I end up with duplicated verts then I will let this go. If my importer ends up with the "expected" number of verts then I will have to still question this.

I just used my importer with the attached cube. My importer converts the mesh to a format usable by my custom engine. The result was the expected 8 verts and not 12. Therefore, I would have to say I still think there is an issue here.

I'm afraid you'll have to question this further...

Final vertex count depends heavily on the shading model used (flat, smooth), how you send your data to the graphics card (triangle strips, fans, indexed lists, etc), what you want to with the normals, how you have your uv's set-up, if you batch render by material, use limited file formats in the pipeline and so on..

   


While necessary for the cube (sharp corners), in the sphere's case Esenthel does come up with redundant vertices - which can be easily fixed in v1, but not so in v2 :(
   
-edit: the above picture and comment is talking about ms3d import, if I import the fbx version of the sphere the results are different (151 vtx, 224 tris) , also if i import a .obj (151 vtx, 32 tris, 96 quad) ... depending on the app exporting it, and various options selected at the time.. but ms3d importer does seem to produce higher than really needed vertex counts

(08-22-2013 03:29 AM)Rofar Wrote:  Greg, I know you are very busy with lots of things so I'm not asking for you to put a priority on this. However, I just want to make sure it doesn't get forgotten. My concern with this thread is the vertex count with meshes imported from ms3d format. Just want to make sure you have this on your list to check when you get a chance.

Hi!
Sorry for late reply

The answer:
MS3D importer imports vertexes directly from the file, so if it has more vertexes in the EE Editor than in your original program (Maya/3ds max), then it means that the extra vertices simply exist in the file, and that's how they were exported to MS3D.

However:
EE 2.0 when producing the meshes for the game, automatically optimizes the mesh, so once in the game, you will actually have the welded version

You can verify this by doing something like
Draw()
{
..
D.text(0,0,S+MeshPtr(id)->vtxs());
}

PS: I'll add auto vtx-welding in the importer to the next release, so you should be able to see the optimized number in the Editor as well.

Okay, I feel much more comfortable with using ms3d import now. So the verts displayed is the number of vertices in the file on disk, not the number that the game render data contains when the mesh is loaded? That's not a problem at all