Legal values for weight map vertices?
I've just been comparing a clothing figure with weight maps saved from Poser Pro 11 with an original cr2 saved in P10 and just happened to notice the following lines in one of the weight maps:
v 63 1.000000 v 64 -154621041715724210000000000000000.000000 v 70 -2406089395467317800000000000000.000000 v 83 -0.900000 v 84 0.999992
the HUUUGE negative numbers are present in both the original and the re-saved CR2 file and were not actually directly highlighted as differences in the comparison.
Prior to seeing this, it was my, perhaps erroneous, belief that weight maps could only take values between 0.0 and +1.0 (at least in the sense that all of the weight map editing tools in Poser maintain that restriction AFAIK). Without having seen it happen, I can only imagine that unless there are specific protections built into Poser, this could cause some severe "Cactusing" of the clothing figure when those weight maps are applied. (I have not seen such an instance with this clothing, yet)
I'm hoping to make some sense of this, in order to make sensible suggestions to the clothing creator as to whether this can be ignored or should be urgently fixed and the source of such strange values identified and rectified.
It looks indeed as if there is something corrupted there. Weight values should be between 0.0 (vertex not affcted by bending) to 1.0 (vertex fully follows bending). I can imagine values not far outside that range can be used to get specific effects. Values between -1.0 and 0.0 could be used to hack symmetrical deformation, values above 1.0 could give exaggerated movements.
Unless the iten you are inspecting has any such 'special effects' I suggest you advise the maker.
@fverbaas I've PM'd the creator on another forum once I worked out that they only occurred on actors with no geometry, so they're totally redundant and probably acquired through copying joint zones from a figure or mannequin. The garbage values are still a mystery, though.
So, not set and therefore containing garbage. Classic issue.
@F_Verbaas yep. So much garbage, that I had to use the following GREP expression to match the weight map values:
Not just one, but two different variations of Not A Number indications, in addition to possibly negative floating point digit strings!!!