UISprite and Anchoring

[Maxii]

I'm trying to anchor a UISprite in the UI Layer to a gameObject on a world layer in code. I've successfully done this with UILabel using SetAnchor(gameObject). In that case, I relocate the label to the same location as the world object, setting z to 0, then call SetAnchor(gameObject), followed by ResetAndUpdateAnchors(). This results in the proper unified offsets and the label in the UI layer follows the gameObject.

Doing the same thing with a Sprite has me stumped though. The 32x32 sliced sprite resizes to 2x2 (smallest possible I know) as a direct result of SetAnchor(gameObject) being called. As a result, the anchor offsets are all zero (which makes sense, given such a small sprite). I can see the now tiny sprite is in the right position, but it is too small to be useful. Interestingly, calling MakePixelPerfect() after this increases the sprite back to 32x32, but propels it to never-never land, aka enormous offsets. It is now the right size, but way off the screen.

The gameObject itself is simply an empty child GameObject of my real moving target which acts as a relative offset positioned where I want the label/sprite to be anchored.

Thanks for your excellent support. I always spend a few hours myself trying to figure these things out reading other threads before I ask.

As an aside: I can tell the anchoring system is extremely powerful and flexible, but it has a pretty steep learning curve, at least for anything more than basic concepts.

[ArenMook]

Not sure what values you're passing to the SetAnchor function, but why not just use transform.OverlayPosition? This way nothing needs to be anchored.

[Maxii]

Yes, I could use .OverlayPosition which is what I had been doing, but I've been trying to make use of the expanded capabilities of UIWidget and anchor was one of those. I'm guessing that anchoring is more involved (performance-wise)?

To clarify, I'm using SetAnchor(transform) without any additional absolute values. I'm aware that the comments say the Rect will take on the size of the transform (which in this case is 00 as it is just an empty GameObject), but it worked on UILabel without shrinking the widget. On UISprite though it shrinks the widget to 2x2, the smallest. As this is Widget(Rect) behaviour, shouldn't UILabel and UISprite exhibit the same behaviour?

[ArenMook]

Anchoring is more expensive, yes. Left, right, top and bottom all need to be calculated individually, so setting OverlayPosition once is going to give better results.

If you wish to still use the anchoring, SetAnchor sets up your transform, but you still need to pass valid values to it. SetAnchor(transform, left, right, bottom, top) and such. Examine what values you end up with in inspector afterwards, and remember that you can adjust each anchor individually -- widget.leftAnchor.Set, etc.

[Maxii]

1. I've changed now to transform.OverlayPosition but it results in the Z of my UIElement (parented under UIRoot) going off the charts (> 200K).

My UIEement heirarchy is:

UIRoot
- UIPanel
--UIWidget

I'm guessing the z grows so large because of the scale of UIRoot, but shouldn't that already be accounted for or is OverlayPosition only for use when the UIElement is parented in the 3D world?

Edit: I can see now that OverlayPosition can be useful with UI2D, World3D and other elements. An idea: rather than have the need to (post-process) set the z to zero with a UI2D element, how about adding a optional parameter that allows the user of the method to tell the method what kind of element it is dealing with? That way the localPosition could be set correctly within the method rather than need to be adjusted afterward. Just an idea.


2. With the above UIElement heirarchy, should I be using the UIPanel transform or the UIWidget transform when doing transform.OverlayPosition() performance-wise or does it matter?

[ArenMook]

Depends on what you want to move. If your panel only has that one widget, then it makes sense to move the panel as it's faster. If there is more stuff in there, then move the widget.