Python mesh converter for mounts and siege engines

[AlphaDelta]

Bumping up the thread with a question.

I've been editing the serpentine mesh to reflect a later model of saker cannon but have come across a lighting problem.



Any idea what could be the issue? It looks like the normals have been flipped or something. I've tried the 'model information' trick but it didn't seem to help.

Cheers

[xanthipos]

I also have a question about horse mounts.When i import a vanilla horse the legs of the horse seems messed up, like the bones of the legs moved from the original place.I dont know if the problem is only in my imported model.But i have serious problem to match my horse model(new one, no modified) to the bones.The main problem is in the leg bones.Is there any way to fix this??

[KnightErrant]

@AlphaDelta
Sorry, on vacation last week. Did you try the Selection Editor plugin
under the Tools menu? That lets you look at the normals. Though
I don't know what you can do to fix them in Milkshape if that is the
problem, MS won't let you edit normals. Max will if that's an option.

@xanthipos
You can't change the skeleton in Milkshape and have it show up in-game,
the skeleton for the horse are in the .cas files in the directory
fs_horse. (I just copied the bone offset out and supply them in the
converter.) A lot of the vanilla horse models seem to have their meshes
slightly inside of the leg bones, like there was some disconnect at CA
between the modelers and whoever put together the animations. But it
doesn't cause any animation problems, the meshes will still deform properly
because the offset is so small.

[AlphaDelta]

@AlphaDelta
Sorry, on vacation last week. Did you try the Selection Editor plugin
under the Tools menu? That lets you look at the normals. Though
I don't know what you can do to fix them in Milkshape if that is the
problem, MS won't let you edit normals. Max will if that's an option.

No worries! Sorry for pestering!

Just tried the selection editor plugin. Nice tool but for some reason it displays the normal for the vertices and not the faces.

I guess I'm going to need to take my model out of ms3d, put it into 3dsmax, fix the normals and then put it back into ms3d.

Cheers

[KnightErrant]

But lighting for models is only done by the vertex normals. The
illuminance across a face is controlled by interpolation of the three
vertex normals to compute the dot product between the lighting vector
(assume the lights are at infinity) and the three normals.

Ah, but in Max you can really fix things. Select the mesh that has the
problem and put an EditNormals modifier on it. (The normals come out
huge but reset them to 0.1 so they look ok.) Now you can flip them if
they are inverted (this you can do in Milkshape), but if they just point
in bad directions so the lighting is off, you can make them explicit normals
and move them around. This is the best way to fix lighting seams, I hope
Milkshape 2.0 would have something resembling explicit normals. If I
can remember my forum password I'll submit it to Mete's wishlist thread.

[AlphaDelta]

But lighting for models is only done by the vertex normals. The
illuminance across a face is controlled by interpolation of the three
vertex normals to compute the dot product between the lighting vector
(assume the lights are at infinity) and the three normals.

No arguments here, but most 3D software will display the product of the 3 normals as a line extending from the face, rather than the normal of each vertex. It's a heck of a lot more useful to have a line from the face than each vertice. I can screenshot the difference between Max normals and ms3d selection editor normals if necessary.


Also when I brought the cannon into max, I noticed that while some of areas where lighting is bad, the normals are flipped, in some other areas where lighting is bad, normals look fine.

Cheers

[Rorarii]

@alpha

Not sure if this helps but i had a problem previously of Black-white minstral soldiers, parts were very bringht while others very dark ... I eventually found the normal file was only half the size of what it should have been .. I think GOM's util screws up sometimes. I assumed the meshes were reading crap-data for normals effectes.

Once I built the normal file from fresh, and checked the size, it seemed ok, and worked.

R

[AlphaDelta]

Thanks for the suggestion but I dont think this is the issue because if I use my edited texture with the original mesh, it looks fine.

Cheers

[AlphaDelta]

Now that I've released FKoC I've come back to try and get this cannon model looking right.

Today I exported the cannon to .obj format, and imported it into 3dsmax. I fixed up all of the normals that I could see were wrong, exported it back to obj and imported it back into the serpentine scene. Re-assigned the bones to the verts, saved and coverted it to mesh.

The result: No change on the in-game appearance.

Next I tried the "Planarize seams normals" tool in GOAT. Opened the ms3d and saw that the normals were fixed HURRAY!! So I converted the ms3d to mesh, crossed my fingers and started M2..

The result: No change on the in-game appearance.

hmmmm anyone have any more ideas? KE?

Cheers

[KnightErrant]

This is a long shot, but since it is very easy to do, I'll suggest it.
When I was making GOAT, I had a better reference for the math
for the tangent space basis and I slightly changed the calculation of
the tangents and bitangents. Now, supposedly they are only used in lod0
models for subtle interactions with the normal map, NOT for overall
luminosity. So I don't think this is the problem but try it anyway.
At least it will take this off the list if it does nothing.

Now you can't back convert your .ms3d model because GOAT
and the old Python converter aren't compatible; they store the siege engine
texture strings in different ways. However, since the tangents and
bitangents are recomputed on back conversion, you can use GOAT to
forward convert your "bad" mesh file and then immediately back convert
it again to mesh. This will give you, possibly, some new tangents and
bitangents. That's all I can think of to try.

[AlphaDelta]

Sorry, you lost me there KE! Just to double check

I should take my .mesh file, convert it to .ms3d with GOAT using the Mesh to Ms3d Converter button?

And then without editing it at all, convert it from .ms3d back into a .mesh using the Ms3d to Mesh Converter button?

Cheers

[AlphaDelta]

This is what happens when i try to convert the mesh to ms3d:

Read mesh file header, mesh is variant (siege engine)
Read mesh triangle section, number of groups = 1
Read mesh uv section
Read mesh weight section
Read mesh vertex section
Read mesh vertex normal section
Read mesh vertex tangent section
Read mesh vertex bitangent section
Read mesh assignment section
Read mesh first bounding sphere section, first bounding sphere: 0.94905436039 0.
568708539009 -0.648287773132 2.19931864738
Read mesh bone strings section
nch = 0
tell says 217857
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python25\lib\lib-tk\Tkinter.py", line 1403, in __call__
    return self.func(*args)
  File "F:\Games\Medieval II Total War\mod_work\tools\mount2mesh\GameObjectAppli
cationToolbox.py", line 2123, in mesh2ms3dConverterButton
    mesh2ms3dConverter( meshfilename, DEBUG )
  File "F:\Games\Medieval II Total War\mod_work\tools\mount2mesh\GameObjectAppli
cationToolbox.py", line 245, in mesh2ms3dConverter
    meshobj.fromfile( fnmesh, [] )
  File "F:\Games\Medieval II Total War\mod_work\tools\GOAT\GameObjectApplication
Library.py", line 8574, in fromfile
    self.boundingsphere = self.bigfootersection.fromfile( fid, fidtxt )
  File "F:\Games\Medieval II Total War\mod_work\tools\GOAT\GameObjectApplication
Library.py", line 8061, in fromfile
    self.texture3  = getstring( fid, nch )
  File "F:\Games\Medieval II Total War\mod_work\tools\GOAT\GameObjectApplication
Library.py", line 150, in getstring
    thestring              = fidin.read( nchar )           # Direct binary strin
g read.

[KnightErrant]

I just checked GOAT on a vanilla siege engine and it worked fine.
This is interesting, there's something wrong with your .mesh file
but it's playing in-game albeit weird lighting effects. Must be related.
Can you upload your saker cannon .mesh file somewhere? I'd love to
take a look at it.

Edit: Just checked against the serpentine. The converter is dying before
it reads the overlay texture path. This must be related to your in-game
effects.

[Rorarii]

This is what happens when i try to convert the mesh to ms3d:

Read mesh file header, mesh is variant (siege engine)
Read mesh triangle section, number of groups = 1
Read mesh uv section
Read mesh weight section
Read mesh vertex section
Read mesh vertex normal section
Read mesh vertex tangent section
Read mesh vertex bitangent section
Read mesh assignment section
Read mesh first bounding sphere section, first bounding sphere: 0.94905436039 0.
568708539009 -0.648287773132 2.19931864738
Read mesh bone strings section
nch = 0
tell says 217857
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python25\lib\lib-tk\Tkinter.py", line 1403, in __call__
    return self.func(*args)
  File "F:\Games\Medieval II Total War\mod_work\tools\mount2mesh\GameObjectAppli
cationToolbox.py", line 2123, in mesh2ms3dConverterButton
    mesh2ms3dConverter( meshfilename, DEBUG )
  File "F:\Games\Medieval II Total War\mod_work\tools\mount2mesh\GameObjectAppli
cationToolbox.py", line 245, in mesh2ms3dConverter
    meshobj.fromfile( fnmesh, [] )
  File "F:\Games\Medieval II Total War\mod_work\tools\GOAT\GameObjectApplication
Library.py", line 8574, in fromfile
    self.boundingsphere = self.bigfootersection.fromfile( fid, fidtxt )
  File "F:\Games\Medieval II Total War\mod_work\tools\GOAT\GameObjectApplication
Library.py", line 8061, in fromfile
    self.texture3  = getstring( fid, nch )
  File "F:\Games\Medieval II Total War\mod_work\tools\GOAT\GameObjectApplication
Library.py", line 150, in getstring
    thestring              = fidin.read( nchar )           # Direct binary strin
g read.

Hey! that's very similar to a error message I'm getting (see chariot posts) , not exactly but maybe pointing to a common rouge pointer bug on the GOAT?

R

[KnightErrant]

Here's the model with four bytes moved and should now convert.

http://rapidshare.com/files/15145668...ytes.mesh.html

It was very strange. At the bottom of a siege engine mesh file there are
those three texture strings. The third string is separated from the first
two by four zero bytes. In this file those four zero bytes were separating
the second texture string from the first so it couldn't be read correctly.
See how this file works in the game and if the shadows go away.

[KnightErrant]

Totally cheap shot to bump a post, but the Sox just took the division.
Anyway, I think this fixes the problem. Now the game can read the
overlay file.

[AlphaDelta]

OK here is the .mesh and .ms3d for the older version. Before I tried to fix to any issues with normal.

Thanks for checking this for me KE.

[AlphaDelta]

IT WORKS!! THANK YOU KE!!

I can now invest the time to re-build the other artillery pieces in the confidence that they will work. The English civil war will get the artillery pieces it deserves.

Thanks again for taking the time to chase this up and fix the problem.

Cheers

[AlphaDelta]

KE I've been working on editing the culverin to be more 17th century-esque and run up against the exact same problem so I'm guessing it's not a freak accident.

It's no problem though as your hex editor fix (moving 4 bytes after the first texture call to be after the final texture call) has been working fine.

Oh and one thing I've notice. With the bump texture being loaded lighting generally looks fine, however it's actually reversed..The side facing away from the sun is bright, the side facing the sun is dark. The vanilla serpentine/culverin light correctly.

3dsmax I believe generates normals for an object that is imported without any. So as a test I exported the model from MS3D int obj, imported it into MAX without normals, exported to obj with normals. Imported it into ms3d, re-assigned bones and exported to mesh. It didn't help.

Cheers

[AlphaDelta]

This screenshot was taken in the 'morning' and lighting is reversed.



This screenshot was taken at 'mid-day', the lighting on the gun and frame looks perfect.

However notice that as it rolls forward the wheels go from perfect lighting to incorrect lighting and back again.



And how about this, sudden strange lighting flash even though the cannon isn't moving at all!!



Cheers