Update blender_3dmigoto.py with QOL Export for modding

[2u843yt385592yjh]

Adds a new option "File->Export 3DMigoto Mod" Exports the selected mesh directly to the game without the hassle of creating new .ini files or making folder structures.

Sample body.ini (automatically created)

[DarkStarSword]

So, I already started work on something similar, which you can see write_ini_file() here: https://github.com/DarkStarSword/3d-fixes/blob/master/blender_3dmigoto.py#L1529

Enable that functionality by uncommenting this line: https://github.com/DarkStarSword/3d-fixes/blob/master/blender_3dmigoto.py#L1743

I was planning on just making that part of the existing export process - I don't see a particularly compelling reason to add it as a second export option - at best it might be a checkbox in the export dialog, but even then I'm not sure I really see a good reason not to enable it (besides maybe just being careful of not overwriting a manually edited ini file, but there are other ways we can achieve that). Was there any specific reason you added this as a separate export operator? (Edit: I see your one does batch export - that's probably a worthwhile addition, but let's either name it "batch" or bring it into the existing one if > 1 objects are selected, and see if we can reduce duplicate code)

Mine isn't finished - the main missing piece at the moment is that I hadn't got around to saving the shader and resource hashes yet, and we could maybe merge that piece from your pull request, however your method of obtaining the hashes is going to be unreliable - the filenames can vary based on the frame analysis options (hold and filename_reg in particular change it, though I'm happy to ignore filename_reg as that's pretty rarely used) as well as which objects were bound to the pipeline (e.g. the pixel shader hash might be missing if it was a geometry or depth only pass, and may be much later in the filename if domain, hull and/or geometry shaders were in use). This really needs to use a regular expression to match the correct hash in the filename by matching the appropriate prefix before each hash.

Also a bit of a heads up that part of the reason I haven't finished that, is the ongoing support to load additional vertex buffers from stream output pre-skinning stages (https://github.com/DarkStarSword/3d-fixes/issues/19) will have a significant impact on it. There is also a distinct possibility that the support to load related meshes will be changed to load them into the same mesh with different materials, which will also impact the ini generation.

[DarkStarSword]

            f"[ShaderOverride_{mod_name}_{ini_name}_{index}]",
           f"hash = {ps_hash}",
           "run = CommandListMod",
           "allow_duplicate_hash = overrule"

This is also something I really want to avoid. You can easily end up with the command list and checktextureoverrides running multiple times for the same draw call, which is bad for performance and can cause conflicts between mods. The allow_duplicate_hash is supposed to be there to explicitly warn about this, and to allow exceptions where you know better, not something that should be blanket overruled. At the moment that means all the hashes have to be added to a central ini file, but I have been planning for months to change this in 3DMigoto so that a mod can add an additional hash to an existing ShaderOverride section from a central ini file. Problem is my backlog is 5 miles long, and I still haven't got far enough through it to find time to make that happen.

Also, worth noting that I'm open to suggestions for any other ways we could solve that or improve 3DMigoto to make the process easier. Some other ideas I already have is limiting the number of times checktextureoverride can run in a single draw call (I think the above approach is better, but this might still help prevent mods that don't follow it from causing too many conflicts/performance issues), and maybe allowing ini files to reference sections in other ini files by relative path (currently this can only be done by absolute path, or by overriding the ini namespace, but then it's global), which might be useful for writing out a generated ini file with the [Resource] sections that can be referenced by another (possibly manually edited, possibly autogenerated) ini file in the same directory.

[2u843yt385592yjh]

Sorry, I did not want to complicate things.

The code is originally from the user Mawpius, a Nioh 2 modder. https://github.com/Mawpius/3d-fixes The bulk feature doesn't work, I think. I just merged and tweaked a bit of code with your latest version.

His intention was that the average Joe could make their own mod by just watching a 2 minute video https://www.youtube.com/watch?v=m5f6AACo30U

I was introduced to 3DMigoto from Nioh 2, so I got used to what everyone else did. All over nexusmods it became a meme to use allow_duplicate_hash = overrule for everything. There weren't many performance complaints, as far as I remember, and Nioh 2 was quite a resource heavy game.

I understand this is very dirty and not great to maintain. I will see if I can come up with something better and check your write ini function.

[2u843yt385592yjh]

I see the stuff you asked, I may have a better version soon.

About the central ini you mention, I will try to make the script make a new general folder called ShaderOverrides which will contain many .ini files with the pixel shader hash as filename and its corresponding [ShaderOverride] inside SS whenever someone exports a mod with that same hash, it already has existing .ini file and wont be duplicated. This way we may not execute it multiple times, If I understood you correctly.