I noticed the buttons I had with a script that tweens the color on hover suddenly started flickering heavily. It appears to be due to a change in 1.47.0 as running the project in 1.46.5 and below does not have this issue.
I tore apart my project to make a simple repro here:
Launch the project and move the mouse over the buttons in the scroll area. Notice how the buttons flicker when the mouse moves over them, even when the mouse does not leave the button area.
Then launch with 1.46.5. Notice how the buttons do not flicker and the color tween works as intended. Any ideas?
Starting from https://github.com/playcanvas/engine/pull/3482 , we started to correctly ‘sort’ the element for input handling on 3D screens. This means that elements placed in the 3D world will behave correctly depending on the camera angle and which element is in front of the other.
As a side-effect, if 2 elements are in the exact same depth from the camera (in this case, the buttons and the background), the engine may not be consistent in choosing which one is on top of the other. I see 2 different options to resolve your particular use-case:
it seems to me that this particular UI is more suited as a 2D screen, rather than a 3D screen anchored to the camera;
use the Z coordinate to place elements in front of / behind the other. In this case, your background needs to have a smaller Z value than the buttons.
I will take a stab at adjusting the Z value of the necessary groups. This does make grouped items pretty inconvenient in 3D screens now. Unfortunately, converting this bit of UI to a 2D screen would not work, as I need 3D models that live in that environment to appear in front of it.
So I got the buttons to work by physically moving them, but something still does not sit right with me. I created a new layer for this particular set of elements and made sure that it was being sorted manually on render. In this case, I’m not sure why we would still be calculating what is the closest to the camera if the intent is made clear by the created layer that the UI should be sorted manually.
This could especially pose a problem for 3D screens that can be interacted with by a user in a 3D environment that they can walk around in. If each element needs to stick out above the screen, it may be readily apparent to the user that it isn’t a flat screen as it should be.
Looking back through the previous posts, I now understand the reason for the pull, but it looks like the original forum post had problems with the fact that he created a distance sorted layer that did not fire events correctly based on the distance based sorting. I would think that those that are using manually sorted layers should be able to continue creating their UI in the same way.
edit: It looks like mine isn’t the only project affected. @gnormanlippert 's project is also affected by this change:
That’s a very good point. The input should follow the same logic as the rendering for different orderings of the different layers. I’m looking into this and will provide updates here.