Rendering/raycast order of World Space Canvases (since Unity 4.6.1)

Unity Engine
1

Unity 4.6.1 removed the priority from GraphicRaycaster. Before that, a Canvas could render behind another but still block clicks to it, due to different render (Canvas) / raycast (GraphicRaycaster) sortings. If I understand correctly, now the order defined in the Canvas is both the rendering and raycast order. This is totally fine. :slight_smile: But…

Question 1: If two World Space Canvases use the same camera, is their rendering/raycast order well defined?

I ask this because Unity 4.6.1 broke a scene of ours where that happens (yeah, we can and will change that). One of the Canvases is always blocking clicks to the other, even if its layer order is lower (in that case it renders behind but still blocks clicks).

Question 2: If two World Space Canvases use different cameras (which see different layers), what defines rendering/raycast order? Camera depth? Canvas order? Both? Only one?

This should be documented. My tests seem to imply that Camera depth is used, and if both cameras have the same depth we have the behaviour of the 1st question, where one Canvas is always “in front” regarding clicks but can render behind or in front based on Order.

Can anyone enlighten me, please? :slight_smile: Thanks!

2

So there is a new change coming soon as well to make it even more robust. but FYI i’d use 4.6.1p1 as 4.6.1 had some issues with ordering.

Answers
Q1: If they use the same camera the distance to the canvas is what is used to determine the hit. They likely should never be at the same distance.

Q2: the order if first determined by the camera depth, then by canvas order

3

Thank you for the explanation. :slight_smile: We were actually using 4.6.1p1 already, because we’ve seen the issues you mention in 4.6.1.

OK, in our case we had in fact the two Canvases at the same position (0,0,0), so it seems they were not “officially” sorted. We’ll change our setup anyway, as the use of the same camera for both of our Canvases is not the best of things, but there seems to exist undefined behavior in this case. It’s an edge case, after all.

Thanks again.

4

There is a branch i’ve mentioned in other threads (https://bitbucket.org/philip_cosgrave/philunity-uibugfixes) that may take care of this issue but it also may not