.cas to .mesh display error

**uanime5** · 05-08-2008, 22:57

I converted the Noh.cas file from Blue Lotus to a mesh file but it is not displaying correctly in M2TW (though it displays correctly in Milkshape). However their Naginata is not displayed correctly and they cannot use their arms. Does anyone know what is causing this or how to fix it?

**KnightErrant** · 05-09-2008, 21:23

If you upload the .ms3d file somewhere and post a link here I'd
be happy to take a look at it.

**uanime5** · 05-09-2008, 23:05

I've uploaded the Noh.ms3d here:

http://rapidshare.com/files/113774105/M2TW_ms3d.rar.html

This file also contains the Hanya (displayed correctly but moves wrongly) and two monk (displayed in a blocky way but seem to move correctly) ms3d files.

**KnightErrant** · 05-10-2008, 04:42

Hi uanime5,

Thanks for uploading the files. The one common problem is they
are all missing a model comment. When I back convert with Grumpy's
converter this isn't in the .mesh file so I'm sort of surprised they even
play. Load each into Milkshape and click the model tab. Click the comment
button and use these values (I just took them from armored_sergeants,
should be good enough.)

Code:

0.48
0.39
0.10
1.71
/

Enter each value and then hit the enter key to insert the carriage return/linefeed characters. Do the same after the / character.

For the hanya_lod0.ms3d do the same but it is also missing a group
comment for rfoot. Put in some appropriate group comment for that
mesh. I'm guessing, but that one is probably your Sonic the Hedgehog
result.

See if that gets you better results. If not, post back and I'll look deeper.

Regards,

KE

**uanime5** · 05-10-2008, 21:22

I tried copy and pasting the model comment you posted into the model comment box but every unit that I gave a model comment didn't show up in the mod (they were all invisible). Also as soon as I added a comment for the rfoot group to the Hanya it was displayed incorrectly in the mod and the unit still didn't move correctly. It's possible that these units would function better without these comments. Can you think of any reason why this is happening?

**KnightErrant** · 05-16-2008, 04:53

Sorry to take so long to look at this, hasn't been a slow week.
Let's just do the noh for now. If I use Grumpy's converter and back
convert I see this when I make a text representation of the mesh file
for the weighting. (Just a few vertices here.)

Code:

18 0  [ 10]  1 0 0 0
{222} (weights:  float pairs)
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995
    0.00000000    2.54999995

The first column is the primary weight and the second is the secondary weight.
Without the model comment the converter is finding the hex FF (in decimal
for a unsigned byte this is 255) meaning -1 for no bone assignment and putting
that in the weight vector. The game obviously isn't able to deal with this.

My simple-minded suggestion of putting in the model comment doesn't fix it
up correctly; something is still going wrong. Here's some of what I see after
the back conversion.

Code:

18 0  [ 10]  1 0 0 0
{222} (weights:  float pairs)
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000
    1.00000000    0.00000000

Same section of the mesh file. The weights are correct! Sadly, the bone
assignment section looks like this:

Code:

28 0 1 0 [ 14]  2 0 0 0 0 0
 {222} (assignments: byte quads)
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0
    0  255   20    0

The 20's in the third column are a primary assignment to Grumpy's
composite bone, bone_weapon_weapon01. That's ok (I think) but the
second column is the secondary assignment to bone number 255 which
is also signed byte -1. I don't think the mesh format likes that.

So I took that file and imported it into Gmax and exported again because
I know my import/export script fixes up secondary assignments and assigns
everything to bone_pelvis with a weight of 0.0. Now the same section looks
like this:

Code:

28 0 1 0 [ 14]  2 0 0 0 0 0
 {222} (assignments: byte quads)
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0   20    0
    0    0    4    0
    0    0    5    0
    0    0    5    0
    0    0    5    0
    0    0    5    0
    0    0    5    0
    0    0    9    0
    0    0    5    0
    0    0    9    0

( I showed a little more to show the assigments eventually go over
to regular bone indices like 4 and 5.)

The short story is: the back converted noh_lod0.mesh file with this
procedure is here:

http://rapidshare.com/files/11522983...lod0.mesh.html

Try this one in-game and see if it works. If so, I can do the same thing
to the other three files you posted and see how that goes. If not,
I think I'm stumped; I can't find anything else in the mesh format that
might be wrong.

**uanime5** · 05-19-2008, 22:53

I'm having a problem getting this file from Rapidshare (it keeps saying I've entered too manu wrong codes). Can you please reupload it or upload it to Megaupload.