12-04-2019, 01:59 AM
Hey Nayan,
So it's not a bug in the traditional sense of the word, it's merely a problem with the way floating point values are stored in a 32-bit format....you can end up with rounding errors in some situations and that's what you're seeing here. The value of 21 on that problem particle is actually being stored as 21.0000019. There's nothing I can do about that directly, however the reason for the imprecision may be the way you're storing the value inside of a Point3 value (the scale of the particle). Any particular reason you're not storing the values in custom float channels?
For example, in your script you can replace "tf.SetScale(sInx, scl);" with "tf.SetCustomFloat(sInx, "channelName", (float)u);", and in that case "channelName" can be whatever you want it to be. Then test the custom float in your Delete operator.
I notice that when the value is stored directly in a float channel, the rounding error issue no longer occurs...which leaves me to believe that it could be popping up during the conversion to Point3 for whatever reason (again, not something I have control over...seems to be a compiler optimization issue in this case).
So it's not a bug in the traditional sense of the word, it's merely a problem with the way floating point values are stored in a 32-bit format....you can end up with rounding errors in some situations and that's what you're seeing here. The value of 21 on that problem particle is actually being stored as 21.0000019. There's nothing I can do about that directly, however the reason for the imprecision may be the way you're storing the value inside of a Point3 value (the scale of the particle). Any particular reason you're not storing the values in custom float channels?
For example, in your script you can replace "tf.SetScale(sInx, scl);" with "tf.SetCustomFloat(sInx, "channelName", (float)u);", and in that case "channelName" can be whatever you want it to be. Then test the custom float in your Delete operator.
I notice that when the value is stored directly in a float channel, the rounding error issue no longer occurs...which leaves me to believe that it could be popping up during the conversion to Point3 for whatever reason (again, not something I have control over...seems to be a compiler optimization issue in this case).