volzh commented 13 years ago

I have a md5mesh file that represents a human charactor. When it's rendered by away3d, it's broken.

but with any other viewer supports md5 type, it's fine.

Here is the md5mesh file i used. It's exported by 3dsmax 2010 with md5 exporter plugin. http://volzh.springnote.com/pages/8209962/attachments/5331290?download=true

volzh commented 13 years ago

I solved this problem by following method.

Modelling & IK animation in 3dsmax 2010
export to .fbx file format
import fbx file in 3dsmax
export to .md5mesh file format

http://volzh.springnote.com/pages/8209962/attachments/5341894?download=true so this is final md5mesh file for nice rendered by away3d 4. I hope this will help for development.

ghost commented 13 years ago

Which exporter script / plugin did you use? There are a few out there and they support different features. Was it an editable mesh? What modifiers are on its stack?

Best regards.

richardolsson commented 12 years ago

I'll have a look at this, but we might end up just leaving it and requiring users to do the workaround suggested above.

richardolsson commented 12 years ago

I've spent a couple of hours investigating this issue, and although I greatly appreciate the two examples files, I haven't been able to find the issue with the broken one.

@DerSchmale Please have a look and see if you can spot anything obviously wrong with the broken file. I have come as far as to conclude that it's related to the animation/binding, because if I comment out the geometry.animation assignment the mesh looks as one would expect. However, the joint bind poses are identical as far as I can tell. The only differences I can find (without inspecting every vertex/weight 1:1) are:

The broken one has two sub-meshes, but removing one does not solve the issue (the smaller, second sub-mesh does actually not seem to contain the offending geometry anyway).
The broken one has a different joint definition order, but the actual hierarchy is the same so that shouldn't be the problem as far as I can tell.
The broken one has an extra joint ("Prop1"), but as far as I can tell nothing is bound to it, and removing it doesn't fix the issue.
The broken one has at most 5 joints per vertex, the working one has 4.

If you feel that this is not worth further effort, seeing as how there is a working workaround explained in a comment above, please just close the issue.

DerSchmale commented 12 years ago

I did some investigating, turns out the error is because some programmes don't output sanitized data. According to the following spec (http://tfc.duke.free.fr/coding/md5-specs-en.html), weights are in the half-open range (0, 1.0] - so 0.0 weights are impossible - which makes sense as they'd only add calculations and not affect the result. The spec is not exactly official - but looking at the Doom3 models, I'm assuming that was the original idea. I usually hate to cater to broken data outputs, but we may have to make an exception for this one.

richardolsson commented 12 years ago

Got it! Nice work. Seems to be easy enough to just skip those, right? Either during parsing, or during translation. I'll leave it to you to sort it out and close this ticket then. :)

ghost commented 12 years ago

Jupp, I'm always telling my artist coworkers to use the "Remove zero weights" button before exporting. :) I should have written about it the other day (I did write about it on the Away4D forum). :(

away3d / away3d-core-fp11

md5 parsing problem #65

CaptainHindsight