How to avoid NAN/MaxFloat?

those are real annoying stuff.

Do you mind being more specific?

well for example if the quaternion slerp is fed with (0,0,0,0) instead of a valid quaternion it will output a spread of MaxFloats. even if it’s in a nasty framedelay system it’s more dangerous because the next frame the slerp will be fed with 4 MaxFloats and i have no idea how to do a = node with MaxFloat or NAN fed to one of its pins so i can switch to a default value or s+h like the AvoidNIL node

maybe a map node in clamp mode?

What about not feeding random stuff to nodes?

Just validate your quaternion before sending values to slerp.

now there is an AvoidSpecialNumbers. It outputs the last “valid” input

I am still getting weird results when using FFT and Decay in combination.

FFT seems to sometimes output crazy high values (>10^33) which effectively kills the decay, because it would take ages till it is back to a normalized range. This high value from FFT might be MaxFloat, but I am not sure.

This is a problem e.g. within FFT 4Channels, and equipping that module with AvoidSpecialNumbers does not help. A single frame with a high value like that will slip through your plugin and render the Decay faulty.
Interestingly enough, with the 4Channels, it will mess up only individual bands.

The problem occurs on multiple computers and setups, but I don’t know how to reproduce it, except by waiting a little.

use clamp (map set to clamp)

Anto, that was my first intuition too, but even with clamp on, this value slipped through the Map.

Fortunately this insight put me on the right track: this super high value must also have been a special value, just not NaN and MaxFloat (but also a faulty edge case to Map). And rightly so, there are things as PositiveInfinity and NegativeInfinity.

I haven’t had any issues after I added comparisons against them to gregsns filter plugin.
So as to the thread, would you think it worthwile to add them to AvoidSpecialNumbers by default?

Oh, and joreg, should I create a bug report for FFT? I am sure it didn’t spit infinity ever before, but I can’t find any changes to it in the change log.

@velcrome of course: if you have a patch that demonstrates that something is broken in a new version as compared to an older version we’ll be happy to check that.