mathutils precision issues and bool, round, debug, sockets etc

[og76]

This is not a An issue per se. But implications lead to several issues or non functional AN things. We need to deal with these somehow.

Core issue: mathutils.Vector and alike are converting (even rounded) values to floats so:

• boolean comparison not working, false negatives
• any rounding of vec/eul/quat .. is spoiled
• debugs show false positives visually or are useless for such cases (cause of formatting)

generally, precision is spoiled by the float representation if u use mathutils Vec etc.

Specific issues / use cases so far

• I made Vector/Eul/quat round node and it does not work. mathutils.Vector((round(a, decimals) for a in vec)) etc Even worse, it partially works if you use the round node on both entries You can compare tuple to tuple or mathutils.Vector(tuple) to vector but not a straight value to a mathutils generated one
• boolean does not work otherwise on such arrays
• debug rounding is not helping, but on the contrary I eventually converted to string to see...

Note that it does work inside nodes etc where functions/operations accept tuples or other triplets, but there too, mathutils spoils the bool if used (so don't use it, feed plain tuples if bool..)

Solutions?

• We can use this round node but it needs some explanation/help/warning. I wonder if it's enough. Better than today's not working bool. (you have to round both entries and to the same digit! kinda sucks..)
• We can have advanced precision opt in Bool node (thus internally comparing the rounded tuples) but it's just for bool
• We can have advanced Compare values or so in Bool (allowing comparison of different types, hm) not very clear here
• We can allow more flexible input/output on sockets, like cycles etc are allowing (even float plug in vec does like vec from value..) I will not develop more as this goes against the logic today (and you are already throwing garlic and waving crosses at me)
• maybe there is a way decimal module could provide a general/context precision, again huge work and small results. Not even sure it's possible (guess it is) and usually this leads to lots of traded issues (vectors match but angles not, accumulated etc)
• on debug, I don't like that format happens at socket level now. precisely for these cases
• debug is one thing, viewer should be another. What we have today are kinda viewers.

round data node example blend and img from it

ps bumped first into this and more with bvh tree and others, but that is another (sad) story. :)

[JacquesLucke]

I implemented rounding in the debug node because otherwise you get these weird numbers everywhere and in most cases you don't care wether a number is 1.2 or 1.20000000001

Comparison between floats is always difficult. Most of the time you just check if the distance between two values or vectors is smaller than a specific epsilon.

[og76]

ok

• does round node make any sense here? it only partially works..
• what about boolean compare?

[JacquesLucke]

Hm I think rounding a vector doesn't make that much sense. And the Problem with comparison can appear after that as well. Changing he Compare node to have a Special behavior when comparing vectors and floats is possible but not suuuper nice from the coding point of view. Also, when do you really need a vector comparison? I never needed it.

[og76]

first time I needed it was when doin object inside/outside mesh tests the bvh nearest or mesh closes point are very unreliable up to a point, cause they consider only polygons etc (long story..) so I extended them with sort of is on edge/is on vert variants for that I was comparing vectors. eventually I have fallen to vectors distance, but first I tried to make a node setup involving bool

another area is the geometry part, where sometimes you need to see if the point is on line or in plane etc. there also I'm trying to avoid this ..

they are marginal cases and with some doc we can skip implementing that

however, I see an issue if boolean compare supports vectors and the result is wrong, even if only in comparison to some debug

Note that rounding floats is ok! only vector/euler/quat arrays of floats are wrong when after rounding if u use mathutils... of them

[og76]

or maybe boolean should not support vector euler quat and matrix ...

[JacquesLucke]

Well, a real comparison seems to work but in cases you described I think you should always use proximity or so. I don't think we should drop the support for comparing vectors etc...

This is a problem everyone who does something like you did has to deal with eventually. I don't see how we can solve this fundamental issue in a nice way.