Idea for v2?

[scurest]

Hey, I'm loving the ripper. Reusing texture dumping to get the textures was really brilliant!

I was hacking on the importer though and pretty much right away I ran into wanting more data than is in the .glr file, namely the combiner/blender state when each tri was drawn. I know it just released but what do you think about doing a version 2?

Basically this is what I'm thinking

• The .glr format would bump to version 2. The RipTriangle would contain much more of the data from Debugger::Triangle, in particular the muxes for the color combiner and blender.
• The imported materials would basically do a (simplified) high level emulation of the RDP processor as it was configured for each tri, eg. the color combiner formula would be done with math nodes, etc etc. Ideally the import options would be unnecessary and the importer would always just "do the right thing" for every model.

Here's an example showing how it works. The left is with main (default options), the right with a prototype I've been working on.

The left uses a standard Texture * Shade Color formula, which isn't correct for Mario. The right uses a group node that does the (a - b) * c + d formula from the N64's color combiner. In this case, you can see it was configured to do (Texture Color - Shade Color) * Texture Alpha + Shade Color, ie. the texture alpha blends from the shade color to the texture color.

Would you be interested in going in this direction? I have a working prototype that can do two cycles of the color combiner and a little bit of the blender that seems promising. I can probably have the code banged into a state where someone else can look at it today or tomorrow. One caveat is that since v1 .glrs are missing so much info it's basically not feasible to be backwards compatible with them though.

I think this is a good direction for v2, let me know what you think and if you're interested. And thanks again for the ripper!

[Luctaris]

Thanks for trying out my ripper and giving me feedback. I'm aware that there is some missing triangle information along with some incorrect UV calculations, particularly with the multi-textures. I tried to cover the basic information shared between games with the existing code, but it seems after more testing that a decent amount of games require more information to be 100% accurate.

I was actually planning on modifying and pushing the glr file format to v2 before you posted here soon, so if you have a working prototype with the proposed changed I'd appreciate if you created a pull request so that I can check it out. Incompatibility with importing v1 .glrs would not be an issue as it would be expected that people work off the most recent released version.

[scurest]

Okay great, thanks! I'm putting a PR together. In the meantime, do you mind explaining the texture blacklist and wrap override stuff? How is that meant to be used?

[Luctaris]

The Blacklist checkbox indicates whether or not the import mode is in blacklist or whitelist mode. Checked for blacklist, unchecked for whitelist. By default it is checked with no textures specified in the Textures filter string (ie. no textures blacklisted, all textures allowed.). Leaving the blacklist option unchecked will make the filter function as a whitelist, where only the specified textures in the Textures filter string will be allowed during import. If you leave the Blacklist option unchecked and don't specify any filter textures, basically nothing will get imported (aside from NO_TEXTURE triangles). The Remove NO_TEXTURE Triangles option will allow you to exclude triangles that have no texture assigned to them.

If you select 1 or more .PNG files from the import window file browser and press the Add Textures button, the selected textures will get added to the filter string. The naming scheme for textures is their base name without the extension. the ',' character is used to separate multiple entries. (example: FFE10B53D143C728,FF209342DDB23668,FEE3340A2C97B068)

Rather than sitting in the import window and manually searching for and selecting all the textures you want to filter, I added a Blender operator to generate a filter list based on the materials of the triangles you have selected in Edit Mode. You can see instructions on how to use the operator on the README.md

[scurest]

I mean, what's it for though? When would I want to use it?

[Luctaris]

I mean, what's it for though? When would I want to use it?

The main reason I implemented it was for continuous ripping support. Ideally if you're trying to rip multiple sequential frames of a scene, you wouldn't want to include the entire scene part of the animation data. Using the blacklist option set to whitelist mode and only allowing the materials of the animating object(s) will allow you to do that.

There's also situations where most games import with not needed UI/skybox textures that commonly get deleted by people using the tool to port levels to other engines. Rather than deleting the triangles after the fact, a person can create a blender preset to exclude those textures from every future scene import via the blacklist function.

[Luctaris]

The wrapmode override option is meant to be used to basically change/override any of the reported imported modes with a different mode. When importing a scene, the materials are defined in the format 0000000000000000(XX):1111111111111111(XX), where 0000000000000000 and 111111111111111 represent the calculated hash values for the textures 0 (base) and 1 (detail) respectively, and the XX represent the current wrapmode used for that texture. If you notice a specific game is constantly importing a texture with the wrong wrapmode, you can specify a new wrapmode and the importer will internally change it to your selection.