make sure to filter your float values before using them or saving them !

Started by RemiD, October 19, 2023, 10:47:56

Previous topic - Next topic

RemiD

i had some weird behaviors / errors with collision detection using linepick and pickable meshes (Blitz3d), and i did not understand why...

well the reason is the same that i have encountered in the past (october 2019).

in Blitz3d, sometimes a float value is given in a weird format, like '1.0e-004' or '3.20119e-005' or '-2.30033e-006', etc... this is the case for normals...
and this may produce errors in your code if you use / save these float values with this format.

the solution to prevent that is to filter your float values before using them or saving them :
https://www.syntaxbomb.com/miscellaneous/rounds-a-float-value-to-0-001-or-more-else-it-becomes-0/

Derron

the weird format is only given during "textual representation" (printing ...)

So if you write out the bytes of the float you wont have the exponential form (1.0 * 10^-4 = 1.0e--04 = 0.0001).


Could you explain how the "weird format" ("1.0e-004") creates issues with linepick?
It is either not working with "very small numbers" - or you missed to tell us that you store the floats into files and have issues when reading them back (you are writing about "save these floats values").
For saving it means - you should need to repair the "loading" instead of changing values.


bye
Ron

RemiD

Quoteor you missed to tell us that you store the floats into files and have issues when reading them back
yes it is after having read float values from a binary file, (i wrote the float nx,ny,nz values in the binary file, before) that i have noticed that some markers (for debugging normals) were not oriented correctly.

but if i 'round' the float values at 0.001 or more, there is no more issue.


other than that : i have noticed that the pickednx(), pickedny(), pickednz() have sometimes a total value of more than 1.0, which is incorrect for a normal...