Closed ScanMountGoat closed 4 months ago
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.
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 !
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 ?
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.
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.
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.
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.
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
BlendState :
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 :
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.
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?
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.
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 :)
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?
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 :)
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.
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.