search

niftools / nifxml

A repository for the nif.xml file, which contains the nif file format description.
http://www.niftools.org
GNU General Public License v3.0
37 stars 43 forks source link

Num UV Sets split #25

Closed ttl269 closed 10 years ago

ttl269 commented 10 years ago

@neomonkeus @skyfox69 @jonwd7 @Ghostwalker71 @throttlekitty @nexustheru @amorilia Changed definition of Num UV Sets (for >= 10.0.1.0 only) and get rid of BS Num UV Sets. Num UV Sets defined as byte containing number of UV texture sets. Added definition of Extra Vectors Flags stored in byte. Only known function of that flags by that time is 4th bit representing flag for Tangents/Bitangents arrays - this is defined in bitflags type ExtraVectorsFlags. As there is no certainity that number of UV Sets can be stored in all 8 bits, I have left AND function on line 2731 where "arr1" is getting a number of UV Sets only from lower 6 bits (i.e. max number of UV Sets is 63). There is a note about that on line 2725 (although it is for old version 4.0.0.2).

As there is a bug in Nifskope not allowing to "untick" an item of bitflags in case that there is defined only one option, I changed ExtraVectorFlags type from bitflags to enum.

neomonkeus commented 10 years ago

The format is the foundation for the tools, not the tools dictating how the format should be described. Just because it is broken doesn't mean it shouldn't be correct in the nif.xml. Its not just NifSkope which uses it. in fact we should remove all the NifSkope specific info just to see @jonwd7's head spin :P

Also would it be possible to use a boolean, I presume not but just another thought?

ttl269 commented 10 years ago

@neomonkeus

  1. You are absolutely right - tools can't dictate how the format should be described. But at this time we don't know a function of any other value (bits) than 16 in ExtraVectorFlags, so we actually can't be cartain if type of this ExtraVectorFlags should be bitflags or enum. So, why don't use enum?
  2. boolean can't be used as setting to "yes" in nifskope stores value 1, but we need 16.
neomonkeus commented 10 years ago

Yeah I was thinking about this later that the storage size would be an issue. The problem as you said is if there could be other values in which case then you can't use the values. Like any other enum value you will have lots of space. I think the main issue in my head is that the value is 14 rather than 1 or 0 as one would normally expect for a boolean, unless I am completely misunderstanding what ExtraVectorFlags is mean to be and do.

ttl269 commented 10 years ago

@neomonkeus Storage size in this case would not be a problem - bool is stored in byte and ExtraVectorFlags is also a byte. And value we are talking about is not 14 but 16. And right that fact (value 16 means only one bit is set - bit 4) plus fact that for now we don't know if any other value has some function, is the source of uncertanity if ExtraVectorFlags is bit flag (so, it could store 8 various flags that could be combined) or certain value (256 various values but only one is applied). I have already explained what I mean by ExtraVectorFlags - look here (In that post the Flags are not yet called ExtraVectorFlags but Flags or Additional Vector Flags). In short: original Num UV Sets was stored as ushort, i.e. in two bytes and I think, that it is misleading because each byte is different parameter, so original Num UV Sets was mix of two different parameters. What I did is, that I have split it into two parameters: Num UV Sets as byte and Flags (now called ExtraVectorFlags) also as byte.

neomonkeus commented 10 years ago

Ah sorry, misunderstood so. Have we found any other value than 16 in that case so? If not, then we can merge this is as an enum until such time that we find some other value or we can get the issue fixed in NifSkope.