Make G_PM_NPRIMITIVE a world default for fast64 exports

[gheskett]

HackerSM64 should not be reverting back to 1prim if ever overridden in fast64 (for some reason)

[arthurtilly]

this is not a simple addition because this will make ALL existing models now add a revert to 1prim when exported again, same as the dither situation, and the only way to fix it is to change the mode manually to nprim for every material

[gheskett]

Why would they? The only place HackerSM64 sets NPRIM is when initializing the RDP (and never sets 1PRIM ever). The change to this config is for world defaults, not default export preferences (or at least it should be, otherwise that's just silly). Might be a good idea to confirm this though first.

[gheskett]

Or wait, are you saying fast64 models override world defaults within the blend files themselves, even when influenced by the config? For that matter, forcing each world default to override the config? If that's true, that's IMO something fast64 absolutely should not be doing in the first place.

[arthurtilly]

if materials in a file were created prior to this, then the materials will individually have 1prim set on them. therefore if the world default is changed then it will make all the materials set 1prim directly because the material setting and the world default no longer match

[gheskett]

That doesn't make sense to me either; if that's true, it implies to me that the fast64 config doesn't take effect unless you point the model to the repo immediately, which to me is a much bigger problem. (It would additionally make cross-repo support potentially problematic, especially for reuse between different games.)

[arthurtilly]

i cant say i know how the fast64 config works to begin with tbh

[arthurtilly]

but i do know when a similar issue was resolved (dither setting being fixed to be defaulting to disabled instead of noise) it caused a lot of these problems with old models

[gheskett]

The dither thing was caused prior to this config existing (in fact iirc the config was one of the proposed solutions to it).

[gheskett]

Seems like fast64 needs to make it such that both material presets and Blender-side world defaults can assume 'unset' values, which both need to default to the world defaults in the repo's fast64 config file for exports or Blender previews. Until or unless that happens, this PR should not be merged.

[gheskett]

Repointed to 3.0