I wanted to fix one thing about Unity editor Handles, and accidentally ended up fixing some more. So here’s more random things about Handles than you can handle!
What I wanted to fix
For several years now, I wanted built-in tool (Move/Scale/Rotate) handle lines to be thicker than one pixel. One pixel might have been fine when displays were 96 DPI, but these days a pixel is a tiny little non-square.
That’s way too thin for my taste. So I looked at how other similar programs (Maya, Blender, 3dsmax, Modo, Unreal) do it, and all of them except 3dsmax have thicker tool handles. Maya in particular has extremely customizable handles where you can configure everything to your taste – perhaps too much even :)
That by itself is not remarkable at all (well, except that I spent way too much time figuring out how to do something, that is placed in world space, to be constant size in pixel space, LOL). But while playing around with handle thickness, I noticed a handful other little things that were bugging me, I just never clearly thought about them.
Here they are in no particular order, in no other reason than an excuse to post some pictures & gifs!
Hover indicator with yellow color is not great
When mouse is hovering over or near enough the handle axis, it changes color to yellow-ish, to indicate that when you click,
the handle will get picked up. The problem is, “slight yellow” is too similar to say the green (Y axis) color, or to the
gray “rotate facing screen” outline. In the two images below, one of them has the outer rotation circle highlighted since I’m
hovering over it. It’s not easy to tell that the highlight is actually happening.
Move/Scale tool cap hover detection is weird
In some cases, the mouse being directly over one cap still picks another (close, but further from the mouse) axis. Here,
the mouse is directly over the red axis cap, yet the blue one is “picked”. That seems to be fine with axes, but
the “cap” part feels wonky.
I dug into the code, and the cause turned out to be that cone & cube caps use very approximate “distance to sphere”
mouse hover calculation. E.g. for the Move tool, these spheres are what the arrow caps “look like” for the mouse picking.
Which does not quite match the actual cone shape :) For a Scale tool, the virtual spheres are even way larger than cubes.
A similar issue was with the scene view axis widget, where axis mouse hit detection was using spheres of this size for picking
Now, I get that checking distance to sphere is much easier, particularly when it has to be done in screen space, but come on. A sphere is not a great approximation for a cone :) Fixed this by writing “distance to cone” and “distance to cube” (in screen space) functions. Underneath both are “distance to a 2D convex hull of these points projected into screen space”. Yay my first convex hull code, I don’t remember ever writing that!
At almost parallel viewing directions, axis is wrongly picked
Here, moving the mouse over the plane widget and try to move, poof the Z axis got picked instead (see
this tweet too).
What I did: 1) when the axis is almost faded out, never pick it. The code was trying to do that, but only when the axis
is almost entirely invisible. 2) for a partially faded out axis, make the hover indicator not be faded out, so you
can clearly see it being highlighted.
Cap draw ordering issues (Z always on top of X etc.)
Fixing this one is easy, just sort the axis handles before processing them.
Free rotate circle is barely visible
Move tool plane handles are on the opposite side in Ortho projection
Turns out that was just a sign bug.
And that’s it for this round of Handles tweaks! There’s a ton more that could be done (see replies to
Will’s tweet), but that’s for some other day.
above has shipped or landed to mainline code branch yet, by the way. So no promises :) Update: should ship in Unity 2020.2 alpha 9 soon!