Title. As specified, this is just the names - it isn't material composition (yet).
Material names are imported and exported using the names of the material nodes in the gltf format. No processing is done on these - they're kept exactly as the strings used by the game. This is primarily due to the mixed usage of material names in-game - for now, I'd like to keep the strings as a "black box" so to speak, to avoid dealing with all the different model type's material name semantics.
Attributes are imported and exported exported as "extras" - space reserved by the specification for arbitrary additional data. In particular, this is pretty handy for blender, as blender will import (and can be configured to export) these from it's "custom properties", which gives us a nice UX point for editing these values in 3d workspace tools.
I'm choosing not to assign any semantics to the names of attributes, as (as discussed), there are already plugins that use non-atr_ prefixes for logic
I'm choosing not to use a less-arbitrary storage (i.e. morph target names) for attribute storage to avoid overloading concepts and/or getting into semantics muddy water.
Title. As specified, this is just the names - it isn't material composition (yet).
Material names are imported and exported using the names of the material nodes in the gltf format. No processing is done on these - they're kept exactly as the strings used by the game. This is primarily due to the mixed usage of material names in-game - for now, I'd like to keep the strings as a "black box" so to speak, to avoid dealing with all the different model type's material name semantics.
Attributes are imported and exported exported as "extras" - space reserved by the specification for arbitrary additional data. In particular, this is pretty handy for blender, as blender will import (and can be configured to export) these from it's "custom properties", which gives us a nice UX point for editing these values in 3d workspace tools.
atr_prefixes for logic