Features Request

Hello. I have a few years experience with Unity and these are two problems that, in my opinion, just don't match the overall quality and capabilities of Unity.

1. Raycasting and Graphic separation of components. I'd bet Raycast Target was made a part of Graphic in order to be noob friendly. However, I think Unity's community is strong enough to move past this. You don't always want to raycast a graphic and sometimes you want raycasting without a Graphic and consequential draw calls. There are cheats, where you can inherit Graphic and override methods that create draw calls, however, this still introduces overhead. I wish Unity made this more modular.
2. Postprocessing Overlay Canvas. What if I want to have postprocessing on my UI and I wouldn't need a camera otherwise? I have found no solution to this and it's really disappointing because you either have to introduce a camera, which makes your game less lightweight or you have to settle with more minimalist UI. The best example of this is blur like in MacOS, which is currently not possible without cameras.

Feedback is welcome, thanks.

 

1. You refer to raycasts on UI, right?
Isn't UI the only place there this kind of raycast makes sense? Mean where would you want to use it without a visual component?
For other purposes there is Physics.Raycast.

2. The requirement of postprocessing is always to have all pixels rendered onto some texture (render texture) where you apply the processing. That's exactly what a camera achieves. What part of a camera's "overhead" do you think could be omitted?
A single second cam for UI is still fairly lightweight, I'd say.

 

These seem like UI requests. It's unlikely Unity will change anything here. The existing UI development is done with, and attention is focused on a new UI framework that's in dev. This does not have the same problems or even similar architecture.

So with respect I would just recommend you learn to work with it.

 

The issue is likely the one we've all be complaining about since time immemorial: raycasts and graphics using the same layer system for culling.

 

A good example is when you want to allow player to tap anywhere on the screen to exit temporary screen or exit a pop up. Currently, to achieve this without needless draw calls you would have to do this kind of trick:

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.UI;
3. /// A concrete subclass of the Unity UI `Graphic` class that just skips drawing.
4. /// Useful for providing a raycast target without actually drawing anything.
5. public class NonDrawingGraphic : Graphic
6. {
7.      public override void SetMaterialDirty() { return; }
8.      public override void SetVerticesDirty() { return; }
9.  
10.      /// Probably not necessary since the chain of calls `Rebuild()`->`UpdateGeometry()`->`DoMeshGeneration()`->`OnPopulateMesh()` won't happen; so here really just as a fail-safe.
11.      protected override void OnPopulateMesh(VertexHelper vh) {
12.          vh.Clear();
13.          return;
14.      }
15. }

You can read more about people searching for solution to this problem:
https://answers.unity.com/questions/1091618/ui-panel-without-image-component-as-raycast-target.html
https://forum.unity.com/threads/empty-rect-to-catch-clicks.383765/
https://forum.unity.com/threads/invisible-buttons.267245/
https://stackoverflow.com/questions/36888780/how-to-make-an-invisible-transparent-button-work

It could be solved if Raycasting logic and Graphic drawing logic were separate. Also, in many cases you do not want to raycast a graphic, so as a result we would leave out some overhead associated with raycasting a graphic and internal checking if we need to.

It would be nice if overlay canvases provided a way to postprocess their results too. I'm not very familiar with how it works so I don't know how possible it is. Camera calls OnRenderObject method, why is there no such method for overlay canvas?

It's nice to hear future UI framework will not have same problems! Could you guarantee these two specifically will be absent? Also, it sounds exciting. Do we have any date on when new UI framework will be released?

 

Ah thank you for clarification. I see what you mean.
Is an additional draw call just while the menu is up, really a significant disadvantage?

Fairly sure he means UI Toolkit. That does still lack some features and naturally you have to familiarize yourself with a web-style of UI development (tree structure and CSS (USS) files), but it's usable and it's definitely easier to support a wide range of screen resolutions with it. Personally I use it for the menus and classic UI objects for the in-game UI that require 3D elements and custom shaders (currently not supported by toolkit).
Not sure about those specific usecases here.
https://docs.unity3d.com/Manual/UIElements.html

 

Draw calls have bigger toll on performance on mobile devices. I don't know for a fact but it would also make sense if they were draining battery more. I would call it significant in two cases:

• You want to deliver great results to low-end devices.
• You want to have yourself some more room (in terms of performance) for blur, shadow, glow and such effects in your UI.

 

https://docs.unity3d.com/Manual/UIElements.html - It is available but as it's under development, it may lack some features. You can get involved here: https://forum.unity.com/forums/ui-toolkit.178/

It's called UI Toolkit these days but Elements was it's old name.

 

Yeah the docs do call it UI Toolkit too, but guess they kept the name in the URL "UIElements" to not break urls that were shared.

 

Would it be more or less performant in cases where both drawing and raycasting is needed if system layers were separated?

 

It's just enabled by default and can be ticked off. I think Unity explained somewhere their rationale for keeping it as it is (beginners expecting things to happen etc).

 

The performance difference would likely be entirely negligible. I'm talking "not even a microoptimization" levels here. The issue comes more from when you're dealing with more than a total of 26 user layers between graphics and physics, something that's actually very easy to hit in complex systems.

 

Then there is no reason we shouldn't have raycasting as a base class for Graphic (or as a separate component) which we could use in case we need raycasting but not drawing.