Printable View
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?
https://img237.imageshack.us/img237/...bentsc0.th.jpg
If you upload the .ms3d file somewhere and post a link here I'd
be happy to take a look at it.
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.
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.)
Enter each value and then hit the enter key to insert the carriage return/linefeed characters. Do the same after the / character.Code:0.48
0.39
0.10
1.71
/
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.:book:
Regards,
KE
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?
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.)
The first column is the primary weight and the second is the secondary weight.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
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.
Same section of the mesh file. The weights are correct! Sadly, the boneCode: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
assignment section looks like this:
The 20's in the third column are a primary assignment to Grumpy'sCode: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
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:
( I showed a little more to show the assigments eventually go overCode: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
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.
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.
Yeah, rapidshare has been driving me crazy with the codes.:furious3:
Let me just PM you my e-mail and send to that and I'll just
attach the noh to the reply.
Regards,
KE