Object in front not responding to 'pointerdown'

[shot]

I don’t understand why the Screen Capture symbol doesn’t respond to pointerdown events when the Touch Trigger object is visible - especially since the former is in front (on top) of the latter in Z-space.

The problem is that they both need to be visible at all times. The Touch Trigger is a transparent plane that captures pointerdown events to trigger a simple animation when the user touches the screen. The Screen Capture object is for capturing the screen (which is what the 2D Photo Feature subsymbol does).

Can anyone shed some light?

[shot]

After fiddling with the object hierarchy, I discovered that the following arrangement works, although I don’t understand why. There are obviously some ZapWorks fundamentals that I’m missing.

Even though the Screen Capture object is now “behind” the Touch Trigger (including visually when rendered on screen), it now handles pointerdown events before they reach the Touch Trigger, which is exactly the behavior I want. If the Touch Trigger needed to be anything but completely transparent, however, it would not look right.

If anyone can explain why this works the way it does, I’d appreciate it, as it seems a little counter-intuitive.

[simon]

For anything relative to Z.screen the range of Z values goes from +10 as “nearest” to the camera to -10 as “farthest”. If hierarchy order matters, that implies the planes are probably set at the same Z value.

Planes by default render with the “overlay” layerMode, so ones later in the heirarchy render in full over the top of everything else, even if their z value would be behind things. Setting the planes you’re interested in to full_3d layerMode and making them different colours should visualise the “true” Z ordering of them, and in that case hierarchy order shouldn’t affect the rendering of those planes. NB: That just helps you visualise the ordering that should be used for pointerdown events - the layerMode setting has no impact on how pointerdown is actually determined, so you don’t need to leave them set to that.

Note also that setting relativeTo on a node effectively ignores all the transforms on the parent groups / nodes, so if you’ve adjusted the Z position of the “Screen Capture” instance in your root symbol that may well not have an impact on the final Z value of whichever plane you’re trying to use to do the screen capture.

If you want the “Touch Trigger” to be the hotspot with the lowest priority, try setting it relativeTo(Z.screen) and position([0, 0, -9.99]).

HTH

[shot]

Thanks, @simon - super useful info!

I did experiment with a different Z value, but at that time, I was just floundering without the benefit of your insightful reply. At least now I have a better understanding of the intended behavior, and it will surely come in handy in the future.