Settlers 7 Models help

[finale00]

I can't think of how they might be referencing the materials.

For example, in some formats you have a bunch of different meshes and each mesh gets a material.
Other formats have a single mesh, but each face has a material index.

There doesn't seem to be an obvious way how to determine, for example in the tavern, which vertices/faces correspond to the roof and which correspond to the door.

The texture names and the order they appear might be a clue, but then looking around I was hoping to find some sort of index that that matches the number of textures.

btw, if the UV's are in 0|2 space how do I map them to 0|1 space? Just divide everything by 2?
Is the lower-bound always a 0? Can it be -1|1 space? Or n|m space for arbitrary integers n and m?

[Sammie]

I can't think of how they might be referencing the materials.

For example, in some formats you have a bunch of different meshes and each mesh gets a material.
Other formats have a single mesh, but each face has a material index.

There doesn't seem to be an obvious way how to determine, for example in the tavern, which vertices/faces correspond to the roof and which correspond to the door.

The texture names and the order they appear might be a clue, but then looking around I was hoping to find some sort of index that that matches the number of textures.

I think every face has a material index. We only have to figured out, how they have stored the data in the file

btw, if the UV's are in 0|2 space how do I map them to 0|1 space? Just divide everything by 2?
Is the lower-bound always a 0? Can it be -1|1 space? Or n|m space for arbitrary integers n and m?

They use repeating-UVs.. its standard in every gameengine or 3D program. The texture you see in 0|1 is the same as in 0|-1 or -2|5 or 10|10 (even if you don't see any texture in the other UV spaces). Every UV space use the same texture, so it doesn't matter where the UVs are.

Of course you can disable the repeating UVs in your 3D programm and put individual textures in the seperate UV-spaces. 3D-Shooter-Games made this normally for characters. You can put the UV for the body in 0|1 and for the head in 0|2. If both UV spaces use a 512x512 texture, the head has more pixeldetails, because same pixelspace but less surface than the body. See here. But games like settlers don't use this feature.

Btw.. the numeration has no standard - 3D Studio Max, Maya, Mari, ZBrush and other programs use different startnumbers when creating UVs. Some start at 0|0 other at 0|1. Some count from left to right on multiple UVs, other from the bottom upwards. Its often confusing if you use multiple UVs in different programs.

[Sammie]

I don't seem to have a Half Precision Floating point in c#... :/

Look @ this tiny function: http://www.criticalsecurity.net/index.p ... ntry233825

@finale00
I have print out the chunks in a table. You see x,y,z as halffloats, 2 junkbytes and uv x/y as halffloat. The data behind (displayed as Hex) is unknown. Seems to be two blocks á 3 bytes. Some values of U1 matching always the X value. If U1 = 7FA706, then X = 64.1875. If U1 = DCD685 then X = 65.9375. But no idea what this is good for. U2 and U4 is unknown, too. Any idea?

Musketeer


Building

[TaylorMouse]

@sammy
Hey, thanks man

I think I will make an extension method for the BinaryReader class in C# so you can get it by doing this :

Code: Select all

BinaryReader reader;

reader.ReadHalf();
or 
reader.ReadFloat16();

btw the tabmle you printed out, does it come from a object that has more than 1 texture?

Edit: ( paste it in a new .cs file)

Code: Select all

using System;

namespace System.IO
{
    public static class ExtensionMethods
    {
        /// <summary>
        /// Read a Half Precision Point Float and advance the reader by 2 bytes.
        /// </summary>
        /// <returns>Returns a full precision point float </returns>
        public static float ReadHalf(this BinaryReader binaryReader)
        {
            UInt16 u = binaryReader.ReadUInt16();
            int sign = (u >> 15) & 0x00000001;
            int exp = (u >> 10) & 0x0000001F;
            int mant = u & 0x000003FF;

            exp = exp + (127 - 15);
            
            int i = (sign << 31) | (exp << 23) | (mant << 13);
            byte[] buff = BitConverter.GetBytes(i);
            
            return BitConverter.ToSingle(buff, 0);
        }

        /// <summary>
        /// Convert a precisioin point float to a half precision Point
        /// </summary>
        /// <returns>Returns a half precision point of 2 bytes in the form of a UInt16</returns>
        public UInt16 ToHalf(this float f)
        {
            byte[] bytes = BitConverter.GetBytes((double)f);
            ulong bits = BitConverter.ToUInt64(bytes, 0);
            ulong exponent = bits & 0x7ff0000000000000L;
            ulong mantissa = bits & 0x000fffffffffffffL;
            ulong sign = bits & 0x8000000000000000L;
            int placement = (int)((exponent >> 52) - 1023);
            if (placement > 15 || placement < -14)
                return ToHalf(-1.0f); //Whatever counts as error

            UInt16 exponentBits = (UInt16)((15 + placement) << 10);
            UInt16 mantissaBits = (UInt16)(mantissa >> 42);
            UInt16 signBits = (UInt16)(sign >> 48);
            return (UInt16)(exponentBits | mantissaBits | signBits);
        
        }
    
    }
}

T.

[Sammie]

btw the tabmle you printed out, does it come from a object that has more than 1 texture?

Nope, its the musketeer. I have add another table for a multitexture-building. Only more FFs at the end

[TaylorMouse]

mmmm....

there is no other value for the J value anywhere in the Building table??

T.

[Sammie]

mmmm....

there is no other value for the J value anywhere in the Building table??

T.

No. just a junkbyte. Always 00.

Thats another table from VST1. Musketeer left, Building right. Can't see something special. Every 2nd and 4th column has a specific value (displayed as decimal & hex) (57,58,59,60),(3A,3B,3C), but can't figured out what this is good for. Nothing of this looks like a material-id or something. VST2 is uninteresting.. usually only FF, 00 alternatingly - sometimes another value.


Btw: The 2-Byte Value at offset 00000014 is the total number of textures (01 for the musketeer, 04 for the noble residence building). I'm sure the 28 unkown bytes in the middle are relevant for the textures, but I can't figure out how to read them.

Thats my current fileheader-info:

Code: Select all

// Start of chunk (64 bytes)
$fileHeader = $file->readChars(4);					// Fileheader
$majorVersion = $file->readUInt32LE();				// Major Version
$minorVersion = $file->readUInt32LE();				// Minor Version
$nVerts = $file->readUInt32LE();						// Number of Vertices 
$nIndexes = $file->readUInt32LE();					// Number of Indexes
$nTextures = $file->readUInt16LE();					// Number of Textures
$lTextures = $file->readUInt16LE();					// Number of Chars for Textures
$unknown = $file->read(28); 							// Unknown bytes
$lTexturesTotal = $file->readUInt32LE();			// Number of Chars for Textures + Filename
$empty = $file->read(8);								// 0-Bytes Padding
# End of chunk
# offset 00000040
$chunkSize = $lTexturesTotal - ($lTexturesTotal%16) + 16;
$lFilename = (int)$lTexturesTotal - $lTextures;

$textures = $file->readChars($lTextures);				// Texture-Infos splited by 0-Bytes
$filename = $file->readChars($lFilename);				// Path to .s7m File
$file->read(($chunkSize-$lTexturesTotal)%16);			// 0-Bytes Padding to fill the chunk
# Start of VST0

[Sammie]

1 - VST0
2 - VST1
3 - VST2
4 - faces
5 - that VBIN chunk, skeleton or whatever "Shadow" could refer to
6 - textures
7 - small chunk, not sure

16-byte aligned

Hm, I never saw a chunkType #6. But i found out, chunkType 7 is between 3 and 4. His size varied and depend on the numbers of diffuse-textures. If the model has only one texture the chunksize is 32 bytes. if the model has 3 textures the chunksize has 64 bytes, and with 4 textures 80 bytes. So it could be relevant. Hint: if you add the last both values (e.g. the tavern f1 0e & 55 5f = UInt 28230 / cannon b2 0b & d8 00 = Uint 3210) - its same value as the Indexes of the model. Maybe the single values are the numbers how many polygons have a specific texture.

I have parsed some models as HTML-Tables (open in a browser - takes a few seconds to load ), so you can better look at the data-structure.
Download

[finale00]

6 is at the top where the texture names are.

Btw good find.

[Sammie]

6 is at the top where the texture names are.

Btw good find.

Ahh.. damn.. I have parsed this header-part manually, 'cuz it has a fix size.
But I still can't see any informationen about which polygon has a specific texture.
Have you take a look at my parsed html-Files?

[finale00]

No. Can you upload it to google docs or something since it's an html file?

[Sammie]

No. Can you upload it to google docs or something since it's an html file?

Why? The files are to big to load them via internet. Just download the .rar and look this html-files on your local system. Every browser can load local files.

Btw chunkType 7 describes how to read chunkType 6

Texture-Data from chunkType6:
B_NobleResidence_01_Windows Textures\Buildings\G_Windows_02_D.dds Textures\Buildings\G_Windows_02_N.dds Textures\Buildings\G_Windows_02_M.dds Textures\Buildings\G_Windows_Backdrop01_D.dds
B_NobleResidence_01_FabricRoof Textures\Buildings\G_Fabric_Roof_01_D.dds Textures\Buildings\G_Fabric_Roof_01_N.dds Textures\Buildings\G_Fabric_Roof_01_M.dds
B_NobleResidence_01_building Textures\Buildings\B_NobleResidence_D.dds Textures\Buildings\B_NobleResidence_N.dds Textures\Buildings\B_NobleResidence_M.dds
B_NobleResidence_01_ShingleRoof Textures\Buildings\G_Shingle_Roof_02_D.dds Textures\Buildings\G_Shingle_Roof_02_N.dds Textures\Buildings\G_Shingle_Roof_02_M.dds

Data from chunkType 7:
01 00 1d 00 43 00 69 00 8f 00 00 00 69 00 00 00 00 00 00 00
bd 00 dc 00 06 01 30 01 00 00 00 00 3c 00 00 00 69 00 00 00
5a 01 77 01 a1 01 cb 01 00 00 00 00 a6 47 00 00 a5 00 00 00
f5 01 15 02 40 02 6b 02 00 00 00 00 9b 01 00 00 4b 48 00 00

Translated to numbers (model with 4 textures)
1 29 67 105 143 => 105 & 0
189 220 261 304 => 60 & 105
346 375 417 459 => 18342 & 165
501 533 576 619 => 411 & 18407

The first 4/5 Numbers are byte-offsets to jump to every texture name (name, diffuse, normal, material, backdrop). The first number behind must be the number of polygons with this texture. The second number is the summary of the polygons above - so the summary of the last line must be equivalent to the total numbers of polygons. But still no material-ids here.

[finale00]

lol sorry maybe I got you thinking too much about material indices.
You actually already found the answer.

Chunk 7 is composed of a sequence of "mesh info" structs, each totaling 20 bytes in size. So the Tavern example has chunksize of 60, so that's 3 meshes.

It describes what kinds of material is used on a mesh, and which indices form that mesh.
The name offsets are relative to the start of the texture chunk (well, it includes matName as well and something else I think it's the mesh name).

Code: Select all

struct meshInfo {
   short matNameOfs
   short diffName ofs
   short normal_name_ofs
   short matte_name_ofs ?
   short backdrop_name_ofs 
   short another_ofs
   int32 numIdx
   int32 idxStart
}

Material index is not needed in this case.
So like if matName = "blah", idxStart = 0 and numIdx = 30, that means the faces formed by indices 0 to 30 use "blah".

I have updated the noesis script with your findings.



Also, if you look closer at the texture chunk, you'll notice that the very last filename is actually the path of the current model. Not really sure what it's for, but there's probably some reference to it somewhere.

So I might call chunk 6 the "names chunk" since it just has a bunch of paths that could be anything.

btw, I imagine a building can have bones and weights. Maybe the doors and windows can open or close.

And the textures are "mirrored" in my previews, forcing you to rotate the model. Why is it stored like that?

[Sammie]

lol sorry maybe I got you thinking too much about material indices.
You actually already found the answer.

Chunk 7 is composed of a sequence of "mesh info" structs, each totaling 20 bytes in size. So the Tavern example has chunksize of 60, so that's 3 meshes.

It describes what kinds of material is used on a mesh, and which indices form that mesh.
The name offsets are relative to the start of the texture chunk (well, it includes matName as well and something else I think it's the mesh name).

Material index is not needed in this case.
So like if matName = "blah", idxStart = 0 and numIdx = 30, that means the faces formed by indices 0 to 30 use "blah".

I have updated the noesis script with your findings.

Oh I'm glad that I'm the only one, who can't see the wood for the trees.
I've tried your script but can't see any textures in Noesis. What do I wrong?
filename.s7m
Textures/Buildings/*.dds

Also, if you look closer at the texture chunk, you'll notice that the very last filename is actually the path of the current model. Not really sure what it's for, but there's probably some reference to it somewhere.

Don't think, its relevant for us. It's just filepath to the .s7m-file after unpacking the .bba-archive.

btw, I imagine a building can have bones and weights. Maybe the doors and windows can open or close.

Yes, thats correct. In older settlers-games the doors can be opened too and bones were used.

And the textures are "mirrored" in my previews, forcing you to rotate the model. Why is it stored like that?

I don't know. But I saw this in many games before. Normally I flip the UVs vertically instead of mirroring the building.

[finale00]

I don't know sometimes I just cross my fingers and hope noesis finds the textures >_>
Try putting them in the same folder.