Stack overflow > looping in onHoverIn > EQ > Branch ->

[robertdorn83]

Hey,

There is an issue with the onHoverIn node:
The branch node is clearing all evaluated values, which causes the onHoverIn node to trigger his flow out again. Which results in an endless loop between these nodes.

I'm not sure how to fix this behaviour in this special case.

File:
20251110-HoverabilityPropagation.zip

[mattmacf98]

its not supposed to re-evaluate, the system checks if the node has values set already and only re-evaluates them if they are not set. Flow and event nodes should all set their default out values on init so a out value evaluation should never trigger them, the issue was I was setting selectedNodeIndex and not hoverNodeIndex on these nodes so the value evaluation could not find the desired out value and triggered a process node. Fixed here 3399677

@robertdorn83 there is no stack overflow issue anymore but this asset doesn't really do anything, is it still wip or is the intended behavior not executing in the tool? (will leave open until you confirm)

Screen.Recording.2025-12-01.at.7.51.50.PM.mov

[robertdorn83]

just for update: still in investigation why is not working as indented.

but one issue could be the activeCamera rotation, test it with other samples, and i guess it must returned this way:

any opinions about this?

[mattmacf98]

the order has to be returned in xyzw order, it is written in the spec https://github.com/KhronosGroup/glTF/blob/interactivity/extensions/2.0/Khronos/KHR_interactivity/Specification.adoc#422-active-camera-state:~:text=camera%E2%80%9D%20rotation%20quaternion%20(-,using%20XYZW%20notation,-)%3B%20the%20identity%20quaternion

could you not do a swizzle op after using decompose and compose to get your desired order?

[robertdorn83]

yeah, but is activeCamera.absoluteRotation using the same coordinate space as in Gltf? Especially with the flipped camera/light direction?

[mattmacf98]

Yes it uses left handed ness which is why I negate the x here https://github.com/KhronosGroup/glTF-InteractivityGraph-AuthoringTool/blob/main/src/decorators/BabylonDecorator.ts#L207

I may have messed up the rotation mapping though, let me check the Babylon docs

[mattmacf98]

@robertdorn83 I have a branch that switches babylon's scene to use RHS here https://github.com/KhronosGroup/glTF-InteractivityGraph-AuthoringTool/tree/FEAT-use-rhs-babylon-decorator can you see if this makes your asset behave as expected? If so, I can do another pass and convert all my expectations of babylon to be RHS instead

Screen.Recording.2025-12-03.at.9.29.13.AM.mov

[mattmacf98]

friendly bump to confirm if the above is expected @robertdorn83

[robertdorn83]

hey, sorry for late response, i not forgot it ;) i would just wait for the babylon interactivity update. So we get another implementation to test with and so we have here a 3th opinion basically ;) I'm also not 100% sure if my implementation for the export is correct, because we also need a conversion from Unity to Gltf.

and yeah, testet it with your branch, but was not working well.

[mattmacf98]

sounds good, will wait for the babylon update then

[robertdorn83]

Hey, happy new year to you!

Babylon is up to date! It basically works there, only the camera-forward is flipped when getting the activeCamera rotation.