A start on the .MESH file format

[Casuir]

Casuir reported
about a few instances where the fourth byte was non-zero,
should I assume that might be a case where the albedo
is being encoded in the alpha channel, assumed to be
the fourth byte?

Just having a look back on the files I looked at before some of them are indeed the base figures, others are ingame and while they do have blanks in one of the first three values I havent seen anything in the fourth yet, its possible I was looking at a bone stream as I dont think I'd noticed that they came last in some files at that time.

So we have all the info now to make a mesh? Where do we stand on formats, is milkshape able to handle the normal/tangent/binormals?

The first block shouldnt be the same if the geometry is different btw

[KnightErrant]

@Casuir
Sorry, I might be misattributing from my faulty memory.
I got the transformation to go both ways but its really
highly tied to feudal_knights_lod0. In my slightly dazed
condition from all this texture mapping information people
have been giving me I can't make a determination but
I THINK if we sort it out we, I mean GrumpyOldMan, can
make a converter that goes both ways. The mystery
data seems computable, I do vertex normals, and a few
posts back was some C++ math about the tangents and
binormals that seems doable so maybe if I can compute this
and stuff it back into the mesh we have a demo of the
process?

Could you try a different unit and see if it crashes or works.
The bones stuff is way out of my league, I keep seeing funny
blue lines for bones so I don't know if this is my basic ignorance
of Milkshape or if I've reversed the vertex normals in my conversions.

[Suraknar]

@ KE

Edit: Sorry, if you're asking if the first mystery block is the same for
each lod I don't know. I can find out but I have to run some examples.

Yes, reading above from what Caliban has posted in combination with the excelent information Re Berengario linked, thank you RB :), I would assume that the block of information in question here would indicate a somewhat different information for eahc LOD.

Now, if this is indeed the case, then a second peace of information here would be to confirm if that information is the same between all lod0's, lod1's etc...

In other words, if the info from one unit's lod0 is the same with the info of another units lod0, and the info of one unit's lod1 is the same with anotehr unit's lod1, while being different from another lod level.

It would mean that the engine uses a uniform scheme for each lod across the board, which can simplify the task of the converter to reproducing (copy-paste) these values for each lod instead of trying to calculate them on a per modded model.

As I said before I am no programmer, so I cant verify the validity of all this but from what RB linked, I understand the process conceptually. So before continuing on what I am trying to say I'll post the relevent info.

----

So this..

What are the tangent and bitangent vectors used in tangent space normal mapping? A plane's normal is perpendicular to the plane, while the tangent and bitangent are parallel to the plane. Their direction is determined by the UV coordinates, one points in the direction of U-axis in 3d space, the other in the direction of the V-axis.

The tangent space normal map stores in each component the distance along each of these vectors. For example, one component of the normal map (usually stored in the blue part) points directly away from the mesh triangle, ie. along the triangle normal. This allows the same normal map to be reused on different parts of a mesh.

with this...

Blending the Tangent/Bitangent Vectors

Let's say you are creating smoothed vertex normals, by adding the face normals of adjacent triangles for each vertex, then normalizing the vector. You can do the same thing with tangent and bitangent vectors.

Note that the 3 vectors (normal, tangent, bitangent) may not form an orthogonal basis since the tangent & bitangent directions are based on texture uv coordinates and possibly averaged from multiple vectors. What you can do is use Gram-Schmidt orthogonalization. This is performed simply by subtracting the part of a vector in the direction of another vector then renormalizing. For example the code to make the tangent orthogonal to the normal is:

tangent -= normal * tangent.dot( normal );
tangent.normalize();

Once you have two orthogonal vectors you can use the cross product to compute the 3rd. The orthogonalization step seems to be mainly necessary on complex curved models or places with texture seems. Many texture seems however will cause weird lighting no matter what, so if the tangent/bitangent vectors are too far apart you'll probably be better off leaving a split at the seem and not smoothing them together.

And finally this...

Using Tangent Space with Shaders

To use tangent space normal mapping, we need to send the tangent and bitangent vectors to the vertex shader. Then we can create a 3x3 rotation matrix from them that can be used to rotate vectors such as the light vector and half-angle vector into tangent space.

float3x3 objToTangentSpace = float3x3( IN.Tangent, IN.Bitangent, IN.Normal );
OUT.halfVec = mul(objToTangentSpace, halfVec );
OUT.lightVec = mul(objToTangentSpace, lightVec);

Now we can dot these vectors with a normal from our tangent space normal map, using the same pixel shader as with object space normal mapping.

Are important steps to come to this information in the .mesh format that you see, as I understand it.

Added to all this is a process that the documentation calls normalize in order to better use Tangent Space with vertex and pixel shading.

----

Now returning to the idea here, that after reading page 6 of this thread I think GOM also had.

If, it is proven that the game uses a uniform scheme for handling the units and their various lod's.

Then in the converter we need to not worry about calculating and producing these values ourselves.

The converter could simply insert that information in the appropriate lod.

So the modder would start by loading an lod0.mesh file, make their desired changes, and save as .ms3d.

Then when converting to .mesh, the converter could produce 4 files instead of one.

lod0, lod1 and lod2 and lod3 respectivelly with the appropriate tangent space mapping information to each level.

maybe this is a simpler approach for all?

[Casuir]

@KE I wont be able to do anything with the script you sent me till later but I'll try it out on a few other models with different makeup later and see if anything looks odd.

@Suraknar, the normal/tangent/binormals are calculated per vertex so two different models are going to have two different sets of values, i.e pasting the data from a file with 4000 vertices into a file with 5000 vertices will crash the game.

[Suraknar]

@Suraknar, the normal/tangent/binormals are calculated per vertex so two different models are going to have two different sets of values, i.e pasting the data from a file with 4000 vertices into a file with 5000 vertices will crash the game.

So in other words that mysterious byte information is the actual per vertex calculations and not the information required by the rendering engine on how to handle them.

I was under this impression that this information was pertaining to instruct the engine on how to handle the per vertex calculations whose information is stored elsewhere in the file and would depend on each different model (obviously).

Well in that case yes it is not feasable. Continuing to read with interest here, I am a 3D artist(Maya and the older SoftImage), I understand what we talking about, yet, not necessarilly the coding parts.

[KnightErrant]

Okay, I want to return to tangent space normal mapping but
I'll leave out the mathematics.
Many thanks to Re Berengario I and Suraknar for pointing out
tutorials on this and data cube normalization. Caliban has told
us that the 3 0 0 0 mystery block is vertex normals, 10 0 0 0
is tangents, and 11 0 0 0 are binormals. The vertex normals
are computed by averaging over the face normals by iterating
over the triangles, the tangents are computed by conditioning
the face tangents by the uv coords according to the formulas
in the refs in the previous posts, and the binormals can be obtained
from the cross products. The confusing part is mapping to RGB
values. Basically you take all the normalized vectors, add 1.0
and divide by 2.0 to map the components onto a [0,1] RGB float
space. You then multiply by 255 and truncate to map to a
byte-valued RGB space on [0,255]. This is called cube normalization
(learned at lunch time). This is the format of the mystery
data's block 1, 2, and 3 (along with a fourth byte that looks
like an unused albedo value).

Anyway, if you do this you can get the following .mesh to .ms3d
and .ms3d to .mesh conversion for the feudal_knights_lod0.mesh.

(I'm repeating bits of post #160 and I'll use thumbnails this time,
still learning the fine points here.)

First step: Convert mesh to ms3d and modify in Milkshape:
All I've done is broken the lances.




First try, zero out the mystery data:




Okay, you can see the Milkshape mod has shown up in the game but
the shadows on the lod0 rendered knights shows the mystery data isn't
being applied.

Finally, use the data cube normalization along with the vertex normals,
tangents, and binormals to compute the mystery data out of the
data pulled from the .ms3d file and put into the .mesh format to get





and there you have a forward and backward mesh conversion.



Slight but solvable problem: People might notice the lighting looks wrong.
That's because there's still an unresolved coordinate system problem.
Here's the vertex normals (in tangent space normal mapping) from
the original feudal_knights_lod0.mesh

(first ten of them anyway)

189 238 116   0  
 253 127 106   0  
   5  95 110   0  
 136   3 100   0  
 251 116  98   0  
 193 236 129   0  
 209  31 108   0  
 139   1 115   0  
  50  25 118   0  
   2 108 115   0

and here's my computed ones:

116  238  190  0   
107  128  253  0   
111  95  5  0      
103  5  100  0     
99  116  251  0    
130  236  194  0   
109  36  215  0    
114  29  208  0    
119  26  51  0     
116  108  2  0

You can see that the x and z coords are reversed and that they
don't exactly match. Too tired to work this out tonight, I'll hit
it later. Must be a coordinate system thing.

Anyway, the mechanics of this are getting really clear now.
More stuff tomorrow.

[GrumpyOldMan]

Hi Guys

Lots of real life things happening , The first un-mystery block is normals, stored byte fashion as z y x 0, the algorithm to extract them is MS3D normal(x,y or z)*127.5+127.5. Remember to reverse any Milkshape 'x' values to take into account the different axes. It's not exact but close enough. This means that with the right frame work we can now extract lod1 and below meshes from Milkshape - including any new groups . M2TW will run without lod0 meshes but you won't get the eye candy.

@KE and Casuir - The Milkshape meshes that I've been extracting don't have valid normal info, I've been relying on Milkshape to update them. To update them, after loading the MS3D, go to Menu/Tools/Model Information V1.7 and after it comes up, hit the Close button rather than the 'x' in the top righthand corner and this will update the normals.

I'm going to work on the tangent and binormal/bitangent using the first triangle/vertices of the Feudal_knights_lod0.mesh. The info is as follow:-

155 154 143 (vertex number)
0.794555 0.558303 -0.0330388 0.330422 0.127918 (x,y,z,u,v)
0.794555 0.431023 -0.0131331 0.315904 0.127895
0.794555 0.482091 -0.0767073 0.322253 0.127879

I'll get out the tangent and bitangent figures later, I'm assuming that it runs z,y,x,0 as per normals.

Well when GrumpyOldMan comes online he'll understand this
so I guess I shouldn't be too worried about my ignorance.

You wouldn't have been so confident if you'd known that I had hot flushes after I was dragged kicking and screaming from my DX7 comfort zone, with shader stuff!!

Cheers

GrumpyOldMan

[KnightErrant]

Hi GrumpyOldMan!

We almost simultaneously posted! RE I and Suraknar straightened
me out and steered me to the right tutorials for tangent space stuff
and cube normalization. Caliban really came through for us on the
mystery data. I'm feeling really good about getting this to work now.
Is my coordinate space problem because Milkshape uses a system I
didn't pay attention to?

[Suraknar]

Many thanks to Re Berengario I and Suraknar for pointing out
tutorials on this and data cube normalization.

I did not do much really, except read the docs RB linked and point to various areas, while making assumptive hypothesis. :P

The great thing here is that there is much progress which is extraordinary!