Messages

46

NGUI 3 Support / 3.0.7f3 TweenAlpha UIRect

« on: December 18, 2013, 01:23:20 PM »

We upgraded our components and we found that our game crashed due to changes in how TweenAlpha finds its UIRect. I just want to bring it to your attention so you can be made aware.

In most tween classes the target is found via GetComponentInChildren but in TweenAlpha it is only GetComponent. Were you going to change the other tweens to use GetComponent or was it a mistake in TweenAlpha? Or is there a reason why one uses one method and one uses the other?

Thanks!

47

NGUI 3 Support / 3.0.7f2 - Problems Anchoring to Screen Positions

« on: December 12, 2013, 12:12:23 PM »

Hi, I upgraded to f2 and now I'm having problems figuring out how to get widgets to parent to screen coordinates (top-left) for example.

My 2D hierarchy is the following
UIPanel
--UICamera
--GameObjectParent
----UISprite
------UISprite
------UILabel

When I try to anchor, it correctly finds the UIPanel GameObject. However, when I try to specify Advanced and set only the top and left coordinates in the anchor settings it is sticking it in my main camera's space and not in the UI space. Am I doing something wrong from what anyone can tell? It seemed to be working properly in f1 so was there a change that I need to do in order to get sprites to screen anchors in F2?

A second question. Are you going to deprecate the old UIAnchor script? While I find the new anchoring system powerful, I find a little cumbersome to use. (A lot of selecting NONE for simple point anchoring using Advanced) I also miss being able to anchor non-widget GameObjects in the new system as I often have a "ViewController" GameObject that will contain a controller script that manages the widgets underneath it.

48

NGUI 3 Support / Re: NGUI on custom Mesh

« on: December 12, 2013, 12:08:05 PM »

The only way I can think of how to do this now, is to render the UICamera to a texture and then use that texture to be applied to a cylinder.

49

NGUI 3 Support / Re: Forcing Objects to Left Side Of Screen?

« on: December 09, 2013, 02:23:27 PM »

I'm also having a problem doing some tests with 3.0.7. It appears when I try to parent my anchor of a sprite to my UIRoot in order to anchor the sprite in the upper-left portion of the screen for example, I am running into problems that your video doesn't appear to follow along with.

When I try to anchor to my UIRoot it thinks that it is a GameObject and it will not allow me to specify any of the drop lists and will only allow me to offset from the GameObject's Vector3 position.

In the video it appears that the drop lists should be enabled when you parent to the root, but in my case they are not.

GameObject Hierachy:
UIRoot
--UICamera
----UIPanel
------UISprite(w/ Anchor)
--------UISprite
--------UILabel


Is this still the preferred 2D GameObject hierarchy for 2D objects?

50

NGUI 3 Support / Re: Serious performance spikes with 3.0.2 and UIPanel.LateUpdate

« on: December 09, 2013, 12:07:04 PM »

This is also probably related to the optimization request that I had requested in regards to improving performance with multiple UIPanels. (http://www.tasharen.com/forum/index.php?topic=7014.0) Even iterating through a list of 1000 widgets every frame for 90 panels had a huge impact on performance for us. Granted, 90 panels is a bit excessive, but I don't think NGUI should be iterating through the entire list of UIWidgets for every active panel (1000 x 90 = 90,000 iterations per frame). Even though there are performance checks, there is still work being done every iteration ([] operator and comparison checks). If the widgets were parented to specific panels this could be prevented. I look forward to this optimization.

51

NGUI 3 Support / Re: No more packed font?

« on: December 08, 2013, 12:47:36 PM »

I'm curious on why you think a packed bitmap font is more useful than a dynamic font. Seems to me that a dynamic font would be superior in every way. You couldn't do bitmapped outlines or coloring with a packed font, so any advantage bitmap fonts is negated.

52

NGUI 3 Support / 3.0.6f7 LateUpdate Optimization

« on: December 06, 2013, 06:23:40 PM »

Yet another LateUpdate performance thread. Using NGUI 3.0.6f7 we were doing some performance testing and it appears that there is significant overhead involved here. We have about 1000 widgets in our scene. None of the widgets move so the panels are marked as static. We were doing some profiling and we ran into a question that I'm curious if you could look at.

Our first test:
UIPanel
--UITexture
--UIPanel
----UISprite
----UISprite
----UISprite
----(An additional 11 sprites here)
--UIPanel
----UISprite
----UISprite
----UISprite
----(An additional 11 sprites here)

There were 94 panels of these 11 sprite sets to equate to about 1000 UIWidgets. The idea was that we could use the panels to determine if they were visible or not on the camera and disable and enable it. However, just having them all visible produced some very disturbing profiling results. Our late update call was taking 13ms or 87% of a naked scene's CPU and was already causing frame rate problems in the editor. We looked at the deep profile of it and it was spending 98% of the time inside of the LateUpdate -> UpdateWidgets() call.

Then we did the following layout (basically all the widgets were parented to one panel)
UIPanel
--UITexture
--UISprite
--UISprite
--etc.

We expected this to be faster (obviously fewer panels and draw calls), but we found that the profiler said it was < 1ms (7%)! Meaning it was upwards of 13x faster than sticking them on sub panels so I went to investigate what might be happening.

Inside of a UIPanel.LateUpdate() there is a loop that is confusing me, that I'm hoping you might be able to shed some implementation light on.

1. UIPanel.LateUpdate() {
2.    // Only the very first panel should be doing the update logic
3.    if (list[0] != this) return;
4.  
5.    // Update all panels
6.    for (int i = 0; i < list.size; ++i)
7.    {
8.         UIPanel panel = list[i];
9.         panel.mUpdateTime = RealTime.time;
10.         panel.UpdateTransformMatrix();
11.         panel.UpdateLayers();
12.         panel.UpdateWidgets();
13.    }
14. ...
15. }
16.  

Then inside of the UIPanel.UpdateWidgets() this is happening

1. UIPanel.UpdateWidgets() {
2. ....
3.   for (int i = 0, imax = UIWidget.list.size; i < imax; ++i)
4.   {
5.         UIWidget w = UIWidget.list[i];
6.         // If the widget is visible, update it
7.         if (w.panel == this && w.enabled)
8.         .....
9.   }
10. ....
11. }
12.  

So the problem I have is that if you have a lot of panels there is significant overhead iterating through every widget that many times (even if not much is done because it checks the equality on the w.panel vs this).

My recommendation would be to iterate through all of the widgets only once and check their parent panel for information relating to their visibility. As there are likely significantly more widgets than panels. Something like this

1. UIPanel.LateUpdate() {
2. if (list[0] != this) return;
3.  
4.                 // Update all panels
5.                 for (int i = 0; i < list.size; ++i)
6.                 {
7.                         UIPanel panel = list[i];
8.                         panel.mUpdateTime = RealTime.time;
9.                         panel.UpdateTransformMatrix();
10.                         panel.UpdateLayers();
11.                         // REMOVE THIS panel.UpdateWidgets();
12.                 }
13.  
14. // Update Widgets - Update all widgets only once, instead of iterating through the list once per panel
15.                 for (int i = 0, imax = UIWidget.list.size; i < imax; ++i)
16.                 {
17.                         UIWidget w = UIWidget.list[i];
18.  
19.                         // If the widget is visible, update it
20.                         if (w.panel.enabled)
21.                         .....
22.                  }
23. ...
24. }
25.  

I hope that makes sense. If I'm wrong about this implementation I'd appreciate any information you can provide on why it was implemented as described above.

Thanks for your time!

53

NGUI 3 Support / Re: NGUI and multithreaded rendering

« on: December 06, 2013, 02:00:17 PM »

There is a multi-threaded rendering checkbox in the Android player settings. We ran into problems with a project (that wasn't using NGUI) with it crashing so we didn't enable it. Personally, I don't think the Android multi-threaded renderer is ready for prime-time yet.

54

NGUI 3 Support / 3.0.6f7 UIPanel Depth Tool - Incorrect Triangle Count

« on: December 04, 2013, 11:50:30 AM »

In 3.0.6f7, I was trying to use the new Depth tool today and noticed that the triangle count on the panels appears to be incorrect. It seems to be either 128 or 256.

55

NGUI 3 Support / Re: 3.0.6 f7 Default layer labels drawing in front of 3D objects

« on: December 04, 2013, 11:48:41 AM »

If you're referring to pre 3.0 then yes, the panels are now z-space ignorant. And as such, they will always be rendered after all other objects in the scene. You might be able to hack it so that it uses the default 3000 render queue for these objects by making a shader as such.

56

NGUI 3 Support / Re: (!!!) Improving NGUI: Voice your opinion

« on: November 18, 2013, 01:29:59 PM »

I'm really looking forward to transitioning to uGUI. The only concern is that we've been really spoiled by your ability to push out fixes and new versions quickly and efficiently. So my request is to see if we can make sure that we can maintain some sort of ability to download updates without waiting for new Unity versions.

In regards to GUI functionality and some holes that I see in the functionality.

Text Flow: The biggest request by far, but I'd really love to get some text flow improvements. This would include functionality such as having text flow along a a curve or other shape. This would allow you to make a label fill a non-rectangular shape such as around a circular UI element. I'm not sure how you'd do this other than maybe making a new subset of components (similar to tweens) that would alter the flow of text along an animation curve or something. Another part of this feature would be to allow text to have flow elements that it would watch out for and would create new line breaks based on the collision with these elements. For example, if I have a sprite in the upper left of a text area, the label would automatically position itself in the UILabel where it would not overlap with this sprite. Having this done dynamically would greatly help with localization.

Dynamic Font Emoticons:  This is pretty self-explanatory, but having an easy way to embed sprites in a UILabel would be great. Having some advanced parameters could also be great. Such as [#spriteName#DEPTH:-1#SIZE:32x32] to get a sprite rendered below the label's depth at a size of 32x32. The reason to specify the depth is to try to get this sprite to batch with the other sprite elements could be +/-. The reason to specify the size is that if I want to downsize a larger icon to fit into the label, I may need to shrink it to fit it into the space. Or the sprite that I'm using may not be square. Then being able to link to an atlas on the label that the text would automatically space appropriately to fit.

Multi-Edit UITexture: This is a relatively small request, but since you added it for some of your bigger ones (UISprite and UILabel), I thought I'd request this one as well.

Android Mouse Support: Another minor request, but having supported Android mouse support implemented into the tool would be nice so that I don't have to worry about it being overwritten by updates.

Non-Rect Sprite/Texture Mesh: I'd like to be able to specify a mesh for sprites if desired. So that I can provide a mesh that is non-rectangular in order to cut down fill-rate if there are large portions that are alpha. If it came with a snazzy editor that'd be sweet too, but at the very least a link to a custom mesh if desired.

Obviously, these kind of features are pretty advanced. I really appreciate you asking the community for some feedback. I hope that after uGUI you might work on integrating TNET into Unity. Although I have a feeling that keeping up with community requests and bugs is going to be a full-time job.

57

NGUI 3 Support / Re: Sprite atlases contain lots of empty space!

« on: October 16, 2013, 12:25:35 PM »

It does, but you should be able to us the built-in packing solution instead of Unity's solution. If you go to the Atlas Maker there is a checkbox for Use Unity Packer, just make sure that isn't checked.

58

NGUI 3 Support / Re: UITextures becoming UISprites?

« on: October 10, 2013, 08:10:38 AM »

That definitely helps! I think the biggest problem is that I was hoping to use the same name for the larger-sized resource in addition to the sprite name for the atlased version. I'll have to add a suffix to the big image loading so that it doesn't think that the images are the same as the ones located in the atlas. Thanks for your omniscient help ArenMook and Nicki.

59

NGUI 3 Support / Re: Custom shaders clipping UITexture

« on: October 10, 2013, 08:07:22 AM »

Hi ArenMook,

Thanks for the reply. I looked into the process that you described and came up with the following code:

1. public MeshFilter MeshData;
2.         public override void OnFill (BetterList<Vector3> verts, BetterList<Vector2> uvs, BetterList<Color32> cols) {
3.                 Color colF = color;
4.                 colF.a *= mPanel.alpha;
5.                 Color32 col = premultipliedAlpha ? NGUITools.ApplyPMA(colF) : colF;
6.  
7.                 MeshData.sharedMesh.GetIndices(0);
8.  
9.                 Vector3[] meshVerts = MeshData.sharedMesh.vertices;
10.                 Vector2[] meshUVs = MeshData.sharedMesh.uv;
11.                 for(int i = 0; i < meshVerts.Length; i++) {
12.                         verts.Add(meshVerts[i]);
13.                         uvs.Add(meshUVs[i]);
14.                         cols.Add(col);
15.                 }
16.         }
17.  

However, I found 2 problems. One was trying to get the mesh data as a triangle strip (as I assume that is the topology that you're using). It appeared correctly, but I ended up finding that there was rendering issues (some of the triangles were at the right depth some of them were not). The other problem that I ran across was in the UIDrawCall.Set method where it expects only quads to render. Am I understanding the code correctly there?

60

NGUI 3 Support / UITextures becoming UISprites?

« on: October 09, 2013, 01:43:36 PM »

I'm encountering a weird inconsistent bug and it appears that UITextures are changing into UISprites for some reason which is causing null references to the UITexture. I've only noticed this post 3.0? I've tried to replicate, but I'm not sure what is happening. Is there any reason why the code would be replaced as a UISprite like that? Can anyone else corroborate this issue and see if maybe we can track it down?

Edit: I know that it is not post is not helpful from a technical support perspective until I have repeatable steps. I'm just curious if other have noticed this before I really dig in to try to track this down.