Messages

1

NGUI 3 Support / Re: Problem with NGUI and standart Unity Animation pipeline

« on: October 15, 2015, 12:57:24 PM »

I believe you want the AnimatedWidget component. Attach it to the widget's GameObject, and animate its values instead.

2

NGUI 3 Support / Re: Broken Dynamic Font

« on: August 18, 2015, 06:19:02 PM »

Repro steps are hard to nail down at the moment. The only new error I'm seeing from NGUI is a null reference in NGUIText line 111 but it doesn't correlate to seeing the corrupted labels.  I'll respond again if I can reliably reproduce the issue.

3

NGUI 3 Support / Re: Broken Dynamic Font

« on: August 18, 2015, 01:16:48 PM »

I'm also seeing this issue (the garbled label chars) on nearly every label after updating from NGUI 3.7.9 to 3.9.2 on Unity 4.6.7. Some playthroughs it appears normal for a while, but other times its an immediate issue.

4

NGUI 3 Support / Re: Particles with NGUI

« on: July 02, 2015, 03:50:50 PM »

I'm not at liberty to open source my solution, but here's the gist:

The goal is to have NGUI manage the draw order of the material that the particle system uses. The easiest way I found to do this was to create my own widget type/subclass, which overrides the material property, returning the particles system's desired material. NGUI will now manage the creation of an instance of that material with the correct render queue set, and all I have to do is assign the widget's drawCall.dynamicMaterial to the particle system renderer (usually in update since it could change).

Of course the devil's in the details, but that should get you going. Once that's set up, you can extend it to general Renderers like MeshRenderer and LineRenderer (or in my case, start general), and add soft clipping support (which has to work in world space instead of panel-space).

Good luck!

5

NGUI 3 Support / Re: Atlas sprites positions problem when sharing atlases

« on: May 06, 2015, 01:41:38 PM »

Make sure to run File/Save Project after rebaking your atlas before sending it, and send both the texture and prefab (and material if you changed PMA setting).

6

NGUI 3 Support / Re: Solving anchored + animated widgets

« on: May 06, 2015, 12:20:25 PM »

Thanks for the reply. EnvelopContent just appears to be a beefed-up version of UIStretch, with a much higher performance cost if your hierarchy includes widgets you don't want to include (which is certainly a common workflow if you are taking advantage of NGUI's hierarchical fading). It's also located in Examples, indicating that it isn't a core feature unlike UIStretch. Lastly, it would be yet another script for our artists to become accustomed with, unlike the built in anchoring system.

I already addressed your second point in my example, and how they don't resolve this common issue. Anchoring a corner will not allow the "assembly" to slide while retaining its dimensions, and placing my animated items as children means they can't match the dimensions of the parent. Do you have any issues with my proposal specifically or do you just feel that the issue already has an acceptable solution (because it seems other customers don't)?

7

NGUI 3 Support / Solving anchored + animated widgets

« on: May 04, 2015, 02:17:24 PM »

After running into another case where I need anchored and animated widgets, I've come to the conclusion that NGUI needs to address this fairly common requirement and how it can be reconciled with the current anchoring system. The main issue arises due to the fact that it is no longer possible to match a widget's dimensions without also taking its position. The legacy components UIAnchor and UIStretch provided that ability. Here's an example that illustrates the problem:

Widget A (anchored to fill the left 1/4 of the screen)
- Various UI elements (anchored to Widget A in order to have correct dimensions/relative spacing)

Now what can I do to slide these elements on-screen from the left?
- I can't apply a TweenPosition to Widget A because its anchoring will override the tween.
- I can't apply TweenPositions to the sub-elements, because they still need to accept the dimensions from Widget A

My proposed solution is to add a control to UIRect that allows the user to toggle position and/or dimension matching. This new enum (or checkboxes) has three possible states: Position, Dimensions, or PositionAndDimensions. The only change in behaviour is that right before overwriting localPosition or mWidth/mHeight in UIWidget.OnAnchor:1231/1238, we check that we have an acceptable AnchorMode.

I believe this change to be low-risk, backward-compatible (default to PositionAndDimensions), and easy to communicate. Please let me know what you think.

8

NGUI 3 Support / Re: UIKeyNavigation directional filter logic

« on: December 22, 2014, 02:16:10 PM »

I think the change would simply decrease the possibility for user error due to say placing different UI elements at different Z-depths, as well as expanding the out-of-the-box capabilities of NGUI for 3D map screens, center on child effects with 3D scrolling effects, etc. You can of course cache some of this data for efficiency, although I'd say once per nav input isn't a big hit.

9

NGUI 3 Support / UIKeyNavigation directional filter logic

« on: December 09, 2014, 04:14:30 PM »

I'll keep this short:

UIKeyNavigation should be comparing direction vectors relative to the camera, instead of world space. Currently the system breaks down if your UI/Camera heirarchy has a non-zero rotation, if your UI is 3D, or if your buttons have different Z-depths (for whatever reason). Here are the necessary changes:

1. static protected Vector3 GetCenter (GameObject go)
2. {
3.         UIWidget w = go.GetComponent<UIWidget>();
4.         UICamera cam = UICamera.FindCameraForLayer(go.layer);
5.         Vector3 center = go.transform.position;
6.  
7.         if (w != null)
8.         {
9.                 Vector3[] corners = w.worldCorners;
10.                 center = (corners[0] + corners[2]) * 0.5f;
11.         }
12.  
13.         center = cam.cachedCamera.WorldToScreenPoint( center );
14.         center.z = 0;
15.         return center;
16. }
17.  

While I'm at it, a layer mask would be cool to restrict navigation between buttons on different layers. Sometimes we have a map screen and a UI overlay and we don't want to be able to navigate between them freely. This would just involve adding a public LayerMask field, and throwing out targets that aren't in the mask in the Get() loop. Let me know what you think.

10

NGUI 3 Support / Re: Update to most recent version slows Unity

« on: November 28, 2014, 06:53:41 PM »

There is no issue. This was a false alarm due to people thinking that GetComponentInParent<T> is equivalent to transform.parent.GetComponent<T>. It's not! go.GetComponentInParent<T> is equivalent to:

1. Transform trans = go.transform;
2. while( trans != null ) {
3.    T comp = trans.GetComponent<T>();
4.    if( comp != null )
5.       return comp;
6.    else
7.       trans = trans.parent;
8. }

which checks all ancestors of the GameObject that you're calling it on (and the GO itself). The slowdown itself was due to the fact that NGUI often uses lazy initialization (not a bad thing), and since transform.parent.GetComponent<T> wouldn't find the component it's looking for on the first frame it tries, it would keep trying every frame. Essentially that poor hack caused NGUI to enter a state of perpetual initialization.

11

NGUI 3 Support / Re: How the UISprite to gray?

« on: November 26, 2014, 08:45:48 PM »

The shader renders the UI in grayscale. The (.222,.707,.071) is an empirical value often used to preserve more detail than simply averaging all 3 channels.

12

NGUI 3 Support / Re: understanding anchors at runtime

« on: November 04, 2014, 09:25:52 PM »

Notice that your Target field is bold, this means it's different from the prefab. One limitation of all prefabs in Unity is that you can't reference objects in the scene (and not in the prefab), since that object doesn't exist separately in the project, meaning you can't guarantee its existence when you instantiate the prefab. The prefab therefore has anchoring None. You have a couple options:

A) Put a panel at the root of the prefab and treat it as the screen, since panels assume the screen's dimensions (unless the panel also has anchoring set)
B) Assign the anchor at runtime (could be nicely component-ized if it looks for a root/panel in the runtime parent)

13

NGUI 3 Support / Re: NGUI and Unity 5.0 Upgradable APIs

« on: October 28, 2014, 01:26:10 PM »

Unity 5 will automatically rewrite references to .particleSystem, .collider, etc to the GetComponent<T> version when you upgrade your project. That won't help when you need to update to a new version of NGUI though (if NGUI is still using .collider). I would say Aren should run his NGUI project through a Unity 5 upgrade now (since GetComponent<Collider>() is no worse than .collider) but leave the caching of transforms until Unity 5.1 or a time when the majority of users are on Unity 5.

14

NGUI 3 Support / Re: NGUI Graphic Glitch

« on: September 08, 2014, 12:25:35 PM »

Check if you have Multithreaded Rendering enabled in your Android player settings, NGUI is incompatible with that option at the moment.

15

NGUI 3 Support / Re: Put square Photo inside circle photo is possible?

« on: August 29, 2014, 01:26:58 PM »

There are 2 things happening in your example: A texture mask, and a second texture layered on top.

Masking a texture with another texture is possible if you write a custom shader for it. Basically you read the color of the main texture normally, then multiply its alpha by the alpha (or greyscale value) of the second texture.