matl 1.5 support for ssbh_data

[ScanMountGoat]

It looks like this is identical to 1.6 other than different fields for rasterizer and blend state data. This is currently blocked because the rasterizer and blend state structs for v1.5 are completely undocumented and can't be converted to a unified representation in ssbh_data.

[ScanMountGoat]

Documenting the fields would require some way to map file changes to changes in the rendering pipeline state like cull mode or blend factors. The easiest is to run the game in an emulator using RenderDoc and find the pipeline state for the appropriate draw call. I don't have any games at the moment that allow me to test this, so this will require help from someone willing to investigate.

[AkaiiKitsune]

Thank you so much for taking a look at this ! I'm not particularly versed in using RenderDoc but i'm willing to help prodiving the info you need !

[AkaiiKitsune]

Ok, i did a capture of the main menu of the game where one of the models is loaded (Don-chan, on the bottom left).

Found the draw call and thus the pipeline state.

Do you want me to look at something in particular in here ? or perhaps share you the capture file ?

[ScanMountGoat]

Great. Do you have a way to load edited numatb files in game? We're going to need more than one capture. The basic idea is to record and save different renderdoc captures with only numatb field value changed for each capture. You can also keep renderdoc open if you don't want to save large capture files to disk. I would use ssbh_lib_json for edits.

This looks like DirectX/D3D, so you would look at the Rasterizer, PS, and OM tabs and see if any values changed between the last capture for the same draw call. It helps to memorize the input textures and draw call vertex count in case any changes make it invisible. If changing a single field from 0 to 1 changes fill mode from line to solid, then we can document one field name and start making a FillMode enum for v1.5. Repeating this process should document most of the remaining fields.

It also helps to know what possible values are used for each field. I only have a few files, so you'll have to run some sort of script to check what values are used. Trying to test invalid values might cause weird issues in game or crashes. If a field only has one value used across all files, we can just document that and move on. ssbh_data fills in defaults for a lot of fields when saving anyway.

[AkaiiKitsune]

The numatb files are all stored in a folder called "models", editing them won't be an issue ! i'll try to check what values are reused across all the different models we have (there's 150 different ones for all the character skins) though not being used to either renderdoc nor reverse engineering weird file formats i'm not sure i'll be able to do much 😅

Good opportunity to learn though.

[AkaiiKitsune]

i'm guessing i can just edit those values using ssbh_lib right ?

I've made a few python scripts to bulk convert all the models and dump all the unknown data to a spreadsheet.

Figured out a few fields already, will send a proper list when i'm done testing all the values.

[ScanMountGoat]

Nice! With the tools we have available, the process is more tedious than anything. Let me know if you find anything or run into any issues.

[AkaiiKitsune]

Nice! With the tools we have available, the process is more tedious than anything. Let me know if you find anything or run into any issues.

This is what i've got so far ! * means the game crashed

Matl V1.5

BlendState :

• Col Src (unk1_1) : 0: Zero 1: One 2: Src Alpha 3: Dst Alpha 4: Src Col 5: Dst Col 6: 1-Src Alpha 7: 1-Dst Alpha 8: 1-Src Col 9: 1-Dst Col 10: Src Alpha Sat 11: Src1 Alpha 12: Src1 Col 13: 1-Src1 Alpha 14: 1-Src1 Col (I have tested 0, 1, 2 and 14 to make sure it went all the way up there, didn't test all the values one by one this time though!)
• Col Op (unk2_2) : 0: Add 1: Substract 2: Rev. Substract 3: Minimum 4: Maximum
• Col Dst (unk2): 0: Zero 1: One 2: Src Alpha 3: Dst Alpha 4: Src Col 5: Dst Col 6: 1-Src Alpha 7: 1-Dst Alpha 8: 1-Src Col 9: 1-Dst Col 10: Src Alpha Sat 11: Src1 Alpha 12: Src1 Col 13: 1-Src1 Alpha 14: 1-Src1 Col 15: *
• Alpha Src (unk3): 0: Zero 1: One 2: Src Alpha 3: Dst Alpha 4: 5: 6: 1-Src Alpha 7: 1-Dst Alpha 8: 9: 10: Src Alpha Sat 11: Src1 Alpha 12: 13: 1-Src1 Alpha 14:
• Alpha Op (unk4): 0: Add 1: Substract 2: Rev. Substract 3: Minimum 4: Maximum
• Alpha Dst (unk5): 0: Zero 1: One 2: Src Alpha 3: Dst Alpha 4: 5: 6: 1-Src Alpha 7: 1-Dst Alpha 8: 9: 10: Src Alpha Sat 11: Src1 Alpha 12: 13: 1-Src1 Alpha 14:
• unk6 : 0
• unk7 : 0
• unk8 : 0 / 5
• unk9 : 0

unk6, 7 and 9 remained constant at 0 on the 400 models. those last 4 values i still don't understand what they do, i tried editing them and seeing if there were changes in renderdoc but i couldn't spot anything.

---

RasterizerState :

• Cull Mode (unk1) : 0: Back 1: Front 2: None

[ScanMountGoat]

That's probably as good as it's going to get without a lot more work. Thanks for looking into this. I should be able to add support in ssbh_data and ssbh_data_py with the information you've collected so far. How big is a zip/7z archive with all the numatb files? I believe I only have 1 numatb file from that game for testing the code.

[AkaiiKitsune]

That's probably as good as it's going to get without a lot more work. Thanks for looking into this. I should be able to add support in ssbh_data and ssbh_data_py with the information you've collected so far. How big is a zip/7z archive with all the numatb files? I believe I only have 1 numatb file from that game for testing the code.

Sick ! Thank you again for taking the time to do this. The 949 files are 40kb once compressed in a 7z file! do you have a place here i can share it with ya?

[ScanMountGoat]

You should be able to just attach it to a github comment by dragging and dropping if you don't want to upload to cloud storage.

[AkaiiKitsune]

Don't know how i feel about sharing game files from an arcade dump directly on github haha here's a link to the archive on my nas though : https://cloud.farewell.dev/s/KXoEG27ZxDnRPb3

Let me know if you need anything else from the game :)

[ScanMountGoat]

You can build ssbh_lib_json from source on the latest commit using cargo build --release with some field changes. The unk2 field for RasterizerStateV15 was a mistake and has been removed. The values you were seeing were just the start of the next string. I've also split the first unk1 field of BlendStateV15. I believe that it might actually be Col Src for unk1_1 and Col Op for unk1_2. Does that match up with your in game tests?

[AkaiiKitsune]

Gave it a try today and you're indeed correct, i should have played with unk1's value a bit more lol. unk1_1 is indeed Col Src and unk1_2 Col Op. I have updated the values on my post :)

[ScanMountGoat]

That makes more sense now and matches up with the v1.6 fields in Smash Ultimate. Thank you for doing all those in game tests. I've added support for matl v1.5 to ssbh_data now on the recent commits. Please let me know if you run into any more issues with any SSBH/HBSS files in the future.