@SimGuruModSquad looking for cross reference between catalogobject or object definition and material

IngeJones

We have kind of deserialised the types 0x319E4F1D and 0xC0DB5AE7 as invited to do so, and I can see the fields in the Model resources embedded MaterialSet (MTST) chunk, as well as the Material Definitions (MATD), and I can see there is both a seperate object definition for each color variation as well as a different set of MATDs (default, dirty, burnt) for each color variation. But I am totally failing to make a reference connection between either of the first resource types and the fields in the MTST.

I tried hashing any strings (only fnv64 and 32 though, not 24) and matching numbers and no luck so far. Can you speed me on my way please?

SimGuruModSquad

Hi Inge,

I may not fully understand your question, but here goes:

Inside of the object definition (0xc0db5ae7) there are strings referring to the material variant which when FNV1ed (32 bit lowercase) and should identify the material in the MTST block.

For example:

Object definition resource c0db5ae7:00000000:00000000000073f2 has the variant of set1-materialVariant which hashes to 0xf4bd1ce9. The object definition also specifies a model of "sitLivingGEN_02" which hashes to 0xa4e4eb340d8e3d93. In the model resource 01661233:00000000:a4e4eb340d8e3d93 you will find a reference to 0xf4bd1ce9 in the MTST block.


I think you guys have this figured out but another thing worth mentioning is the Object LOD resource (type 0x01d10f34): That same material ID in the object definition (i.e. 0xf4bd1ce9) is referenced in a material table in the Object LOD resource which specifies the resource keys ofthe actual textures used.

i.e. there are 3 LOD resources for this model used in the example:

01d10f34:00010000:a4e4eb340d8e3d93
01d10f34:00000000:a4e4eb340d8e3d93
01d10f34:00010001:a4e4eb340d8e3d93

Inside of these resources you will find a reference to 0xf4bd1ce9. As well as the texture keys used for this object, which are:

00b2d882:00000000:07a66e272fb524c0 set2 diffuse
00b2d882:00000000:07a66e272fb524c1 set3 diffuse
00b2d882:00000000:07a66e272fb524c3 set1 diffuse
00b2d882:00000000:a0e24d77c786de8c normal
00b2d882:00000000:a0e24d77c786de91 specular

Hope that helps.

IngeJones

You've given me a lot of material there, thanks. I shall explore today using this information and get back to you with whether that solved the mystery for me

(PS also I meant Material State I think not Material Set)

IngeJones

Later... No I don't see that reference, even though our hashing tool does create the same FNV hash as you stated, which I had already tried as being the fairly obvious string to hash. This means there has to be a problem with our MTST analysys lol. I shall go away and try to sort that out in a hex editor.

Should that 0xf4bd1ce9 reference also equate to the material names on one of the MATD material definitions? Cos I am not spotting it there either! Or is it purely referring to a MTST entry which will lead on to a differently numbered MATD?

A little later: I cant find 0xf4bd1ce9 as a hex value in 01661233:00000000:a4e4eb340d8e3d93 or any of its companion LODs even in the hex editor.

SimKuree

And it looks like you guys changed the MTST format from TS3. Would you please tell us what's the new uint field used for? Thanks in advance.

SimGuruModSquad

Hi Inge, look at offset 1844 to see 0xf4bd1ce9 in 01661233:00000000:a4e4eb340d8e3d93. Note that because the data is stored as little endian, it will appear in the raw hex as E9 1C BD F4.

SimKuree, I actually don't know the differences between Sims 3 and Sims 4 MTST format offhand, can you be more specific about what uint field you are referring to?

IngeJones

Edited as irrelevant now

IngeJones

Ok, I didn't understand your byte offset was in decimal. I have now located those bytes. The conclusion is we have a serious problem with s4pe's MTST wrapper which I shall start work on now Thanks!

IngeJones

@SimKuree if you mean what I think, it appears to be indicator of whether the set is for default, dirty or burnt etc. And the other Uint32 is the indicator of what materialVariant it is for, so you get the range of states for each variant. The first set of 4 bytes appears to be a combination of block offset and reference type (eg probably "private" "public" etc like we have always had in RCOLs)

SimKuree

@SimGuruModSquad Please look at 0x01D10F34-0x00000000-0x2437AB67AC116B5B in fullbuild0.package. There is an embedded MTST chunk that has version number 0x300, rather than 0x200. In additional to the 0x200 structure, 0x300 has an unknown uint field. Would you please explain it to us? Thanks in advance.

SimGuruModSquad

Here is the definition of the MTST block:

typedef struct 
{
    char mSignature[4]; // MTST
    UINT32 mVersion <format=hex>;
    UINT32 mHashedName <format=hex>;
    UINT32 mDefaultMaterial;  // UNUSED in V0x300
    UINT32 mCount;

    typedef struct 
    {
        UINT32 mMat <format=hex>;
        UINT32 mStateID <format=hex>;
        UINT32 mVariantID <format=hex>;
    } Materials;

    Materials mMaterials[mCount];

} ModelMaterialSet;

I believe the int you are referring to is the default material field which is actually unused in v300. In v200 the default material was special cased with this field, in v300 it is just included in the list.

SimKuree

Thank you. That's very helpful to us as we're re-implementing the RCOL.