Graphic Raycaster used to have a priority?

Graphic Raycaster used to have a priority to allow ordering of input.
Has this functionality changed in p1? Could not find in notes?
Thanks.

this has been removed in new 4.6 and new local docs

Hmm i might have missed adding that to the release notes :(. That being said yes its been removed as its all handled internally now based on render order. Before you had to specify on each canvas the priority which at times could differ from the rendering order. This could cause confusing so now its handled for you.

I should remove the documentation though :slight_smile:

I have a full screen button on a [screen space - camera] canvas and a button in the corner on a [screen space - overlay] canvas
the button on the overlay canvas is not clickable!?
i used to be able to fiddle with GraphicRaycaster.priority to make this button clickable in last build rc3

interesting once i get a build working again i’ll take a look might be a logic issue with how those two canvas types work together. Did you file a bug by chance?

I can confirm rakkarage’s bug.

yea :frowning: a bug would just make sure it doesnt get lost/ forgotten about.

http://fogbugz.unity3d.com/default.asp?653443_ie63dd82vta4mpl9

Thanks :slight_smile:

I have same problem. I’m waiting for p2 passionately!

1 Like

So as we dont know when the fix will be publicly available in a official release (its missed 4.6.1 at this point) please check out https://bitbucket.org/philip_cosgrave/philunity-uibugfixes and update to the 4.6.0p1 branch. It contains the fix that is required.

1 Like

I’v checked 4.6.1 and it is not fixed yet.

I’ve checked https://bitbucket.org/philip_cosgrave/philunity-uibugfixes and it is fixed there if you checkout and build and copy the dlls

we’ve rushed a 4.6.1p1 to get this out asap (4.6.1 was already in the final stages when the bug was mentioned).

I have also troubled by this problem.
In particular, if I set the RenderMode to WorldSpace or ScreenSpaceCamera, when using the same time, problematic.
Has been ignored that ScreenSpace-Overlay is always the front.
Whether Depth of Camera is reflected, I do not know well.

Did you pull and build the patch that is mentioned above?

Sorry. I have not yet done.
I can not immediately. Please wait at a later date

What’s happening here is that the default raycaster priority is int.maxValue and gets applied to any GraphicRaycaster on a non-Overlay canvas. The way I fixed it was to create a new component that extends GraphicRaycaster and overrides the sortOrderPriority property:

public class WorldRaycaster : GraphicRaycaster {

    [SerializeField]
    private int SortOrder = 0;

    public override int sortOrderPriority {
        get {
            return SortOrder;
        }
    }
}

But presumably the correct way to do this is to have GraphicRaycaster let us set the priority ONLY in cases where its canvas is set to something other than overlay.

2 Likes

That pretty much is the issue along with some other things. the changeset above will resolve the issue until 4.6.1p1 is out.

Its not required to have the priority at all as the other canvas types fall back to a distance sort so the closer one will receive the event first.

Hi Phil, thanks for your responsiveness on this issue. I’ve tried pulling your branch, but unfortunately my issue still remains. It’s a slight modification of rakkarage’s. Instead of a screenspace-camera canvas and screenspace - overlay canvas, all my canvases are screenspace-camera. The canvases don’t seem to be sorting correctly in the event system.

Changing the if statement in GraphicRaycaster.sortOrderPriority to…

if ((canvas.renderMode == RenderMode.ScreenSpaceOverlay) || (canvas.renderMode == RenderMode.ScreenSpaceCamera))

…seems to fix the issue.

I’ve attached a sample project that demonstrates the issue.

1881824–121043–ButtonClickTest.7z (31.2 KB)