This splits interp_weights_face_v3 into interp_weights_tri_v3 and interp_weights_quad_v3, in order to properly handle three sided polygons without needing a useless extra index in your weight array. This also improves clarity and consistency with other math_geom functions, thus reducing potential future errors.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
Event Timeline
Comment Actions
I’m a bit reluctant to accept that kind of change… It’s adding hidden-into-code potentially dangerous behavior in a lib function (assuming that no one will use w[3] when passing v4 == NULL is a bit speculative). At the very least, that new behavior should be documented clearly in function's doc comment (which has to be created here :P ).
But I would only accept that if you have a good reason making new behavior mandatory?
In fact, on second thought, I would only accept that if you split into two public functions (interp_weights_tri_v3 and interp_weights_quad_v3 e.g.), which only accept non-NULL vn arguments (and then you can of course make them both call the same private function with the new behavior - which shall still be documented there).
Comment Actions
Yes, I understand that it is undesirable to assume things, even though this is a fair assumption, as the fourth weight is meaningless for any polygon with three vertices, and setting it to 0 is actually just as random as any other value...
I did it this way, in order to minimize code changes, and keep them localized. Like I said before, I was interpreting the meaning and intended behavior of the code that was already there. But I agree that two separate functions might make more sense, if not simply for clarity and code correctness, at least for consistency with pretty much all other math_geom functions we have, which have separate versions for tris and quads...
I've made the required changes for splitting the function into tri and quad versions. In fact, as interp_weights_face_v3 was already outsourcing the actual math to the barycentric_weights function I mentioned earlier, I have just changed it to not handle a NULL v4, and made another function for tris. I don't think this requires any further documentation, as this is now simply following exactly the same behavior as basically all other math_geom functions...