Closed scurest closed 1 year ago
scurest
commented
1 year ago Woooah, this really wasn't ready to be merged lol.
About naming for materials: for deduping, the name has the depend uniquely on everything the materials depends on, including the combiner state, etc. I was planning on converting the matinfo tuple to string and hashing it with hashlib to get a material name, similar to how textures are IDed by hash.
Luctaris
commented
1 year ago Woooah, this really wasn't ready to be merged lol.
I figured I'd merge it since it was waaay more features and additions that I initially had planned for v2 and all existing v1 features seem to work under your refactored and added code.
As for the material de-duping, I noticed that most of the still existing duplicate material slots are setup the exact same way as far as the shader nodes go. The only difference I could find on most of them after closer inspection is that their other_mode value was slightly changed, which made them unique within the matinfo_cache dictionary.
Converting each entry into a hash and using that as the material name identifier will probably work, the only issue I have with that is that distinguishing what textures the materials have at a glance will no longer be possible. The current setup is formatted in a way that displays (TEXTURE0 file name)(wrapmode(s)) : (TEXTURE1 file name)(wrapmode(s)) | (materials flags [currently only no-culled, might add alpha channel later])
Given all the variations that are possible with the combiner states, I'm not exactly sure what the best way would be to go about implementing de-duping while keeping the existing naming format in-tact.
scurest
commented
1 year ago Yeah, the current matinfo is overly broad. There could be a get_matinfo() function that would take all that info, narrow it down to what the material actually uses (ie. what will get passed to setup_n64_material), and cache on that.
(As an optimization if the args to get_matinfo() are the same as on the previous tri, you could reuse the material index from the last tri right away of course.)
About names:
What about a name like (hash of matinfo) | (readable material info)? Since the first part uniquely IDs everything, you could put whatever subset of info you find most useful at a glance in the second part.
Luctaris
commented
1 year ago What about a name like
(hash of matinfo) | (readable material info)? Since the first part uniquely IDs everything, you could put whatever subset of info you find most useful at a glance in the second part.
That would work, although Blender only has a 64 character limit for material names. The current implementation already uses up 49 characters (assuming UV S,T modes are both different), so that'd only leave us with 14 characters to work with.
I suppose I can reduce the texture CRC hash value implementation from 64 bit to 32 bit to free up some of the space, but that would make all textures from the V1 release essentially worthless and could possibly introduce hash collisions in the future.
If duplicate material slots have identical shader node setups, why not just have them combined at some point?
scurest
commented
1 year ago You would only need to truncate the CRC for display in the readable part of the material name.
If duplicate material slots have identical shader node setups, why not just have them combined at some point?
That's what computing a narrower matinfo would do. Hold on, I'll do a commit so you can see what I mean.
scurest
commented
1 year ago Here's what I mean: https://github.com/Luctaris/blender-import-glr/compare/main...scurest:material-name?expand=1
The get_matinfo gathers a narrow set of info the material needs; two materials should be identical if they have the same matinfo. That's what's used in the matinfo_cache. The create_material function picks a name and just forwards the matinfo to setup_n64_material.
I made the human readable part of the name the texture CRCs to 6 hex digits but it's just an example, you could use whatever you want there (I have no real opinion about it).
Btw do you have a good test for this? On the scenes I tried it barely reduced the material count.
Luctaris
commented
1 year ago Btw do you have a good test for this? On the scenes I tried it barely reduced the material count.
The main game I've tested the plugin on up until this point is Zelda: Ocarina of Time, specifically in the middle of Kakariko Village since it makes good use of many different features, especially multi-textures which honestly seem to be exclusive only to official Nintendo releases. I know that area produces multiple duplicate material slots. The starting area in Super Mario 64 (Castle Courtyard) is another scene I tested which seems to have some duplicates.
The duplicates aren't easily detectable since it seems like Blender actually allows you to set identical material slot names. The way I check for duplicate materials is I go through each material slot and look for a number next to the shield icon.
Luctaris
commented
1 year ago On another note, I've also been experiencing a weird issue where scenes from OOT import fine initially, but the moment you try to switch to edit mode or do other actions, the entire scene (aside from a few tris) goes black. I didn't fully investigate this, but it's probably related to some of the still unimplemented features influencing the shader nodes somehow.
scurest
commented
1 year ago the moment you try to switch to edit mode or do other actions, the entire scene (aside from a few tris) goes black
Same. I figured it was a Blender bug. I can look into trying to repro and report it.
scurest
commented
1 year ago Btw what version of Blender are you targeting?
Luctaris
commented
1 year ago Btw what version of Blender are you targeting?
I'm personally working off of 3.3.1 at the moment, but I've gotten reports that the initial v1 release worked fine even up to the latest version. I'd like to have the plugin compatible with 2.80+ on wards, but I don't think it would be a big deal if it needed a higher version, so long as the changes work up to somewhat recent Blender releases.
As for the discussed Blender bug, I can confirm it seems to happen on almost any Zelda OOT scene I try to import.
scurest
commented
1 year ago Okay. I'm on 3.5 beta and I can confirm it works there. I know the PINGPONG mode used for faking mirror wrapping needs 2.82 at least though.
The bug seems to be some sort of limit on number of material slots or something. Separating out part of the mesh and deleting enough slots you eventually get to a point where deleting one more (any one) makes it work.
scurest
commented
1 year ago Reported the bug to Blender: https://developer.blender.org/T104370. Let's see how it goes.
edit: It's a bug starting in 3.3, so you can avoid it by going earlier for now.
WIP version 2 GLR importer. This is a ground-up rewrite of import_glr.py. The code is still a bit messy but it's fairly well commented I think. The ideal is: everything should "just work".
Stuff that still needs to be added back in
Things that work
Stuff that doesn't work and might require .glr format changes
Fog isn't implemented yet, but there would no longer be a fog box, fog would be done in the materials. On the real N64 the fog level is passed through the Shading Alpha value and combined with the pixel and fog color in the blender. The Shading Alpha is not baked in to the data in the .glr though, so when fog is enabled we'll need to (a) make nodes to compute the fog level and (b) use that for any inputs that ask for Shading Alpha.
The .glr file contains the fog scale, offset, and color, but I think it may also need some info about the viewing frustum to completely implement this.