Compute Bounding Box triggers FireOnChange repeatedly for certain values of Rotation and Scale.

[NukiRaccoon]

Describe the bug?

Sitting here with TeknoCatron in his headless, messing with bounds calculations, we put a FireOnChange on a ComputeBoundingBox because I said we should store its outputs in variables. He puts a Pulse Display on it, and it's constantly spitting out lines (even faster than my framerate, when I drop it to 5)

After messing around, we find that it is NOT firing any of the Slot Events OR the Global Transform stuff, and it only happens when the rotation is not at specific values like 0,0,0, or 90,180,180 (tried putting numbers like 1 and 45 in the X and it does this) or when the scale is at specific values (I believe 1.1 did it but 1.3 did not? It was erratic.)

TLDR: ComputeBoundingBox is firing its FireOnChange event repeatedly when it's not perfectly aligned with the root.

To Reproduce

Make a standard Box. Put some protoflux on it

• ComputeBoundingBox with the box slot as input.
• FireOnChange from the ComputeBoundingBox.
• Pulse Display for the FireOnChange output.

Mess with the Box's transforms, watch the Pulse Display go nuts.

Notes:

• Setting the Include Inactive to false and Coordinate Space to Root does not fix this.
• Pulling a visual on the BoundingBox output shows unchanging values.
• Setting the FireOnChange to only be for a specific user OR using FireOnLocalChange seems to fix this behavior.
• For some values, a FireOnChange will fire like this for the GlobalTransform node's Rotation value, but it's not common like it is for ComputeBoundingBox.

If this does not reproduce, go check in with Tekno, as he made this happen in front of me.

Expected behavior

The FireOnChange should ONLY fire when the bounding box is changed, which should ONLY happen when a Transform is changed, a SlotEvent happens, or some spatial code inside the box is changed.

It's firing when the box is on Root and there are no drivers even linked to any of that, meaning NOTHING should be happening to this box to change the Bounds.

Screenshots

Resonite Version Number

Beta 2024.6.11.74

What Platforms does this occur on?

Windows

What headset if any do you use?

Desktop

Log Files

I do not have the log files for Tekno or the server. Please ask him for those if you need them.

Additional Context

I am concerned that this may be happening within a deeper part of the engine, as EVERYTHING has a bounding-box of some kind, and I don't know where the Bounding Boxes are calculated from.

Reporters

TeknoCatron, Nuki

[Nytra]

Can't recreate this in a world by myself. Must be something with the headless or when multiple users are in the session.

[art0007i]

have you tried plugging in a user into the FireOnChange node? if you want to do it locally use FireOnLocalChange

Bounding box calculations may be different for each user and the FireOnChange node has a global state that each user is constantly overwriting which would cause a lot of repeated pulses.

Edit: after reading the original post I see you did try these, but my answer is still a valid explanation of why it happens. In general FireOnX nodes should always have a user plugged in to avoid this or similar behavior, if you don't want a user plugged in then use the Local versions

[Banane9]

Bounding box calculations may be different for each user and the FireOnChange node has a global state that each user is constantly overwriting which would cause a lot of repeated pulses.

yup, you can even get the same effect with a simple boolean value that's different between two (or more) users. I suspect in this case it's ever so slight floating point inaccuracies or such that cause the issue, despite it otherwise being supposed to be the same.

[Frooxius]

This does sound like it's because each user computes slightly different bounding box, so they think that the value is out of date.

You could work around this by specifying a single user to compute the value - this might be better idea in general for any values that are more complex and won't necessarily be completely identical for all users.

However we could look into adding approximate checks to skip the updates if the values are extremely close. It's not guaranteed to work/help, but we could try.