Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Maxii

Pages: 1 [2] 3 4
16
NGUI 3 Support / Re: Visibility Changed delegate?
« on: October 06, 2014, 08:59:03 AM »
Thanks for considering it. I take it you are referring to a script that polls isVisible during Update?

17
NGUI 3 Support / Re: Visibility Changed delegate?
« on: October 05, 2014, 10:23:48 AM »
Would you consider a feature request then?

18
NGUI 3 Support / Visibility Changed delegate?
« on: October 04, 2014, 03:35:22 PM »
I'm looking for a way to be notified when a widget or panel transitions into/outof camera line of sight like MeshRenderer.OnBecameVisible/Invisible does for meshes. As UISprite doesn't use a MeshRenderer, I don't have that notification available to me.

19
NGUI 3 Support / Re: UISprite and Anchoring
« on: September 30, 2014, 11:16:55 AM »
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?



20
NGUI 3 Support / Re: UISprite and Anchoring
« on: September 29, 2014, 08:39:45 AM »
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?

21
NGUI 3 Support / UISprite and Anchoring
« on: September 26, 2014, 02:47:41 PM »
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.

22
NGUI 3 Documentation / Re: UILabel
« on: September 26, 2014, 08:51:08 AM »
From reading the different threads here, I was expecting MakePixelPerfect (from code) and the Snap Button to adjust the size of the label (widget dimensions) to fit the size of the font and Text currently present in the Text box. It doesn't seem to be doing the above, aka what I expect.

Can you give me a rundown of what I SHOULD expect, since obviously my current expectation is erroneous. I'm using the built in Arial Regular 12 (UIFont).

Does the Overflow setting make a difference in what to expect?

23
NGUI 3 Documentation / onMouseMove delegate
« on: September 18, 2014, 11:50:42 AM »
I'm about to start using UICamera's onMouseMove delegate. Thanks for adding it!

In reading the code, it seems that the delegate gets raised every update() whether there has been movement or not. I know I can test delta to see if there was any movement, but wouldn't it be more efficient to only raise the delegate when posChanged = true? Just curious. ???

24
NGUI 3 Support / Re: UICamera.current vs UICamera.currentCamera
« on: September 17, 2014, 01:30:45 PM »
The first one you are referring to here then would be the one that processes first, aka the one with the lower depth, in my case being the UICamera on the World3D camera, or do you mean the first one I referred to in my message, that being the UICamera on the UI2D camera?

25
NGUI 3 Support / UICamera.current vs UICamera.currentCamera
« on: September 17, 2014, 11:52:50 AM »
I have a Camera2D limited to the UI layer, set to orthogonal with depth = 1. It has a UICamera script with the eventType set to 2D UI and an event mask also limited to the UI layer.

I also have a MainCamera that excludes the UI layer, set to perspective with depth = -1. It also has a UICamera script with the eventType set to 3D World and an event mask that excludes the UI layer.

When I click on a 3D gameObject (not on the UI layer), I print out UICamera.current.name, UICamera.current.eventType and UICamera.currentCamera.name.

I get back, in order: "Camera2D", "2D UI", and "MainCamera". I was expecting MainCamera, 3D World and MainCamera. Shouldn't UICamera.current be the mainCamera's UICamera that can see the gameObject, rather than the Camera2D which can't? How can UICamera.current and UICamera.currentCamera refer to 2 separate cameras immediately after an event is received?

EDIT: I've also now printed out the event mask from both UICamera.current and UICamera.currentCamera yielding respectively: UI layer only, and other layers excluding UI. This seems to confirm that the event must be coming from the MainCamera, even though UICamera.current returns Camera2D.

26
NGUI 3 Support / Re: UICamera Event occlusion
« on: September 12, 2014, 07:56:06 AM »
I think I'm missing something here.

How do all the delegate-subscribing script instances figure out which of them is the target of the raised delegate when the included GameObject is always the fallthrough? Without a collider associated with the subscribing script, Raycast returns nothing and therefore the gameObject included in the raised delegate will always be the fallthrough, won't it? It has been my assumption so far that each subscribing script instance would have to compare its gameObject to the delegate's included gameObject to determine that it was the object clicked on...

When Notify is called to run through the delegate invocation list, doesn't that also generate an unused SendMessage to the fallThrough?

27
NGUI 3 Support / UICamera Event occlusion
« on: September 11, 2014, 10:54:59 AM »
I have a mostly transparent plane with a trigger collider in 3D space that I use to detect onScroll events, allowing me to scroll in/out to/from it. It has no other purpose besides this.

There are other 3D gameObjects with colliders behind the plane that I want to be able to detect onClick/onSelect/onHover, etc. As is right now, the plane collider intercepts these events, but does nothing with them of course. The only way I've been able to figure out how to get the gameObjects behind the plane to get the onClick/... event is to detect it on the plane, then do a raycastAll to see if another object is behind the plane where the cursor is located, then relay the event to that object.

While this will work, I wanted to ask whether you know of another way to accomplish the same thing with the event system that would avoid needing to repeat a raycast?

EDIT: Looking for further insight, you've mentioned in the past that for Windward you exclusively sent all events to the fallThrough (mask = nothing) and then sent them where you wanted them to go from there (using UICamera.Raycast and UICamera.Notify I presume), thereby allowing some routing judgement (like I'm referring to above) to be applied before forwarding them. In looking at the UICamera code, doesn't that result in 2 slow SendMessage() calls for EVERY event?

With your addition now of event delegates, have you changed the approach any? I guess I'm looking for insight into how to use the event system for best performance as you add more flexibility to it.


28
NGUI 3 Support / Re: Feature Request: PlayAnimation Mouse Button selection
« on: September 10, 2014, 02:26:07 PM »
Thanks much!

29
NGUI 3 Support / Feature Request: PlayAnimation Mouse Button selection
« on: September 08, 2014, 10:24:32 AM »
I'm using PlayAnimation on a number of buttons to bring up new menus. I only want a left click to activate the animation, not any click. Would you consider adding a mouse button distinction setting on this script, and/or more generally across other applicable scripts?

Currently, the only way I've been able to handle it is to write my own MyPlayAnimation with the filter built in. Obviously this has limits as PlayAnimation gets updated.

30
NGUI 3 Support / Re: UILabel won't resize freely when anchored
« on: August 30, 2014, 02:24:59 PM »
That works for my current situation - a single resize freely label and a background. Thanks.

What are the circumstances that require the EnvelopContent script you referred to here to be used?

In particular, I have a complex combo of widgets some of which can dynamically change size during runtime (aka labels that can resize freely, with a background that is anchored to the label). The label itself is not the top gameobject in the combo. I want to anchor this combo to a place on the screen.

Pages: 1 [2] 3 4