Open Candoran2 opened 2 years ago
I believe this came directly from the engine serialization, looking at the decompiled EXE. Just because I followed Bethesda's byte alignment and packing from their serialization doesn't really mean it has to stay that way for the nifxml spec. Pretty sure there are fields all over the nifxml spec that don't follow their exact read operations because splitting them off was better conceptually for the spec.
If they're kept grouped to align with Bethesda serialization, not really sure what it should be named though. Lighting Influence and Env Map Min LOD very loosely fit into "Texture Properties". Env Map Min LOD chooses what cubemap convolution to choose from i.e. a cheap way of blurring reflections (e.g. chrome vs a rougher metal). Lighting Influence is how much the ambient lighting gets taken into account for lit effects.
Thanks for the response. "Texture Properties" makes sense, I'll probably update once the other major xml changes are out of the way.
TexClampMode in BSEffectShaderProperty is currently interpreted as an integer rather than an enum value. It cannot be intepreted as an member of the existing TexClampMode due to that being stored as an uint and the adjacent fields in the BSEffectShaderProperty.
Preferably, it should be possible to find a way to keep the access to the tex clamp mode uniform across the BSLightingShaderProperties and return the same type.
One possible solution would be to create a bitfield to be used in both places.
or even two, with the second one missing the extra members like so:
In order to prevent access to members that the rest don't have/are non-functional.
However, I want to hold off on this while the niftools addon is being overhauled. Also, since I don't actually know what the extra bytes do other than going off their name, I don't yet know of a meaningful name to assign to the field.