Messages

61

NGUI 3 Support / Re: Custom shaders clipping UITexture

« on: October 09, 2013, 10:15:28 AM »

This might be a different question, but is there a way to have a UITexture use a custom mesh (instead of a square)? This would allow you to decrease the fill rate if a lot of the texture is invisible? If so, what recommendations would you have to do that?

I'm trying to do something similar. Mainly so that I can have a RenderTexture mapped to a UITexture and it would respect the UI depth space so I could place elements behind and in front of this texture. However, I need to have this render texture not be a square, but rather a custom shape like a circle or a hexagon.

62

NGUI 3 Support / Re: UITexture not updating

« on: October 02, 2013, 11:17:55 AM »

Yeah, I've noticed that UITexture was redone since 2.7 where it is a little "stickier" to work with if you change the material rather than going through the UITexture itself. What I end up doing is adding an extension method to UITexture which I wrap a call to UITexture.mainTexture call which will refresh the panel as appropriate. I used to use MarkAsChanged() but in 3.0 I started having problems with that too.

63

NGUI 3 Support / Re: 3.0 UIPanel Depth/DrawCall Management

« on: October 02, 2013, 10:20:53 AM »

Thanks for listening ArenMook. I understand that you try to find compromises all the time and it isn't easy to weigh everyone's needs.

Here is another suggestion: have a way of having widget sorted just by z. My guess is that you didn't want to go that way for 3D GUI, but if we could set the ordering somewhere to only use z because you know you are only using 2D that could be nice. So we could choose to use depth or z, but not both at the same time like before.

Using a Z-Depth only sounds pretty appealing to me. Not to mention that we can multi-edit transform z values, but it would also allow us to parent transforms. This would also allow us to intermix 3D elements with our UIs as mentioned in this post (http://www.tasharen.com/forum/index.php?topic=5999.0). Which is functionality we lost with the UIPanel no longer determining the Z-Positioning of the rendering in a 3D scene. I figure that this concept doesn't appeal to you though as depth has always been present in NGUI (and it does have purpose in regards to 3D UIs and perspective camera sorting/rendering).

64

NGUI 3 Support / Re: 3.0 UIPanel Depth/DrawCall Management

« on: October 01, 2013, 10:11:16 AM »

Awesome thanks everyone for their feedback. The goal here is to try to come up with some solutions to this problem and hopefully help ArenMook fix the problem. The new UIPanel inspector is a step in the right direction, but it still doesn't solve the problem of having this global depth space being difficult to manage.

With the reduced functionality of the UIPanel I think the best solution is to have the UIPanel's responsibility to be the depth parent. The problem comes when you start parenting UIPanels (such as a drag panel inside of a dialog). If we don't want to the local depths on a per UIPanel system like it was before some other options are per UICamera or per Unity layer so that at least you don't have a global range of widget depth to deal with.

65

NGUI 3 Support / Re: 3.0 UIPanel Depth/DrawCall Management

« on: September 30, 2013, 07:39:20 PM »

Awesome thanks ArenMook! I loaded it up and it looks greatly helpful! I will do some more tests with it tomorrow.

66

NGUI 3 Support / Re: iOS 7 Transparency and etc

« on: September 30, 2013, 05:40:49 PM »

You'd need to write those shaders on your own. There isn't a reason why NGUI couldn't support your own custom shaders for doing a blur alpha blend like iOS does currently. At the expense of draw calls naturally.

67

NGUI 3 Support / Re: 3.0 UIPanel Draw Call Management

« on: September 30, 2013, 03:18:37 PM »

Thanks for the response Nicki.

So basically, you have resorted to taking a spreadsheet approach to organizing the depths. Something that makes it difficult to globally think about.

I think the biggest issue I've had in the conversion is the problem is that I had a workflow of placing panels and then populating those panels knowing full well what order the individual widgets would render. Now I have to do that at a widget level thus 10x the amount of work it is to organize these panels.

For example, my project has the following layers on multiple UICameras and having all of the panels interact is presenting itself as a problem.

- 3D Text/Sprites (these are sprites and labels that are rendered with my 3D scene). These are procedurally instantiated from prefabs. So all prefabs must be updated to use this depth area.
- 2D Elements (happens in a 2D space, but below the UI)
- UI Standard
- Dialog 1 - Dialog Level (informational dialogs, query dialogs, etc.)
- Flying Notification Layer (Things that fly to areas on top of the UI).
- Dialog 2 - Full Screen Pause menu

It's a mess, but it's a complicated UI system for a complicated game. Using the new depth system has been problematic.

68

NGUI 3 Support / Re: 3.0 UIPanel Draw Call Management

« on: September 30, 2013, 01:54:16 PM »

Hi ArenMook,

I'm finally back to work today after a being ill. So I'm slowly getting my UI system converted to the depth system. After a couple hours of converting work to this depth system, I'm still not convinced that this is an improvement.

While the Bring to Front helps at a macro setup level. I still want to stress that this still doesn't bring a comprehensive way of understanding the depths that are out there in the entire global space. Expecting the user to have this understanding is not as easy as it was prior. Previously, we could make assumptions that panels would not interfere with other panels in regards to draw call ordering. In 3.0 the depth space that have to be remembered and organized has increased significantly. For example, I was looking at my 2D UI panels trying to find the UIWidets with unique materials that were assigned depths that would be breaking my draw call batching only to realize that the problem was with panels that I was using in my 3D portion to display text and icons as well as dynamically instantiated effects and labels. It's infuriating to say the least and doesn't seem to have a solution.

I am trying to advocate for each UIPanel to have its own localized depths instead of trying to grasp all of the depths at a global level. While this singular depth it's nice in a simple UI like Starlink, most of the time designers are not thinking of us when they design their UIs. I have 2D UIWidgets which have at least 4 layers of overlapping windows (Tint & Highlighting, Base UI, Dialogs, FullScreen). Then these layering systems have conflicts in my 3D UIWidgets just makes it more complicated to manage. In my opinion it doesn't make sense at all that these completely different uses of NGUI would be interfering with each other at a global level.

Is there a workflow process that maybe I'm missing in order to help keep track of all of these panel depths? Is there a way I can make sure that instantiated panels don't interfere with panels that were created via the editor without having to call a line of code after every instantiation?

While it sounds like uGUI uses a more complicated algorithm for determining depth/draw call batching which sounds great. However, this depth issue is still a problem with NGUI as I mentioned above.

For other that might be reading this, how are you handling this change from <3.0? I've seen a couple people having problems with the transition too, but having other people here saying that "yes this is a problem, and it sucks" or "I've mitigated this problem by doing X,Y,Z" would help me out.

Thanks!

69

NGUI 3 Support / Re: 3.0 UIPanel Draw Call Management

« on: September 27, 2013, 02:41:40 PM »

I agree that having some information on WHAT is causing the depth conflict on a particular UIPanel would be helpful. I agree with zazery about having a depth management tool. Ideally, it would be a separate window that we could reference that displays the UIPanels and their associated depths and which panels have overlapping depths.

While we're brainstorming about depths. How about a "clean depths" button on the UIPanel that takes all of its children and removes any depth conflicts and may also have a depth offset. When the depths are normalized the lowest depth stays the same (or becomes the start depth value), depths that are the same will become previous used depth +1, empty depths are removed, then each widget's depths are set to be a unique depth on that panel, and we can easily resort the depths of that panel by doing this cleanup with a new start depth value.

Regardless, a global lookup of the depths that each UIPanel gameobject uses would just be helpful to diagnose where these conflicts in depth are occurring.

70

NGUI 3 Support / Re: 3.0 UIPanel Draw Call Management

« on: September 24, 2013, 07:28:15 PM »

I'm disappointed that you feel this workflow is better. I hope I can convince you to change this. Or to have you help convince me why this change is an improvement.

From what I'm understanding in order to keep the UI optimized I would need to maintain a spreadsheet of depths for different areas of the UI so that I can make sure that I don't split materials on different depths causing unnecessary draw calls. There could be potentially thousands of widgets in a UI with all of the different dialogs/warnings/tutorials that could appear.

If we have potentially multiple layers of UI visible on the screen at any time. Each layer will need to have its own "depth range" that will need to assigned. Let's say that the dialog range is 200-500. Then on top of this, if there are multiple dialogs that share the dialog depth space, I would need to give each dialog a subset of that range. Otherwise in the Editor they are going to split because there are widgets that might conflict with each panel's atlasing. Then if we need to make a change of moving a chunk of the UI forward or backward in z-space this changing potentially every widget that has been created prior in order to make sure that they still fit in the appropriate z-depth? On top of that there is no multi-widget depth offset and must be done on a per widget basis?

I feel this is a disastrous change and very difficult to manage a UI a complicated as our last game's UI was (50+ dialogs/tutorials/etc.).

Before, I could slap the appropriate widgets into a parented panel. Check the UIPanel to see how many draw calls this panel had only factoring in its children. Adjust any depths internal to the panel and then not have to worry about other panels potentially interfering with this panel's draw calls. If I needed to adjust this panel's Z-Depth I could do it at the transform level and all of the internal widgets would maintain their internal depths.

If you feel that this new depth sorting is better, my recommendation would be as follows:

• Make each UIPanel manage the draw call for the widgets under it like the prior system. It will not check/compare depths of widgets on other panels.
• The Transform's Z position still has no impact so people don't get confused about render order there.
• Add a field to UIPanel that would affect the offset of the children widgets by some depth offset value (like 100 for dialogs).

I BEG you to explain why you feel this new 3.0 UIPanel draw ordering is superior. I understand that you were inundated with support emails from users who didn't understand the old system. However, I feel the new system requires a significant amount of work to maintain and is less flexible to changes.

71

NGUI 3 Support / Re: UILabel Issue

« on: September 24, 2013, 06:22:12 PM »

Is that what it looks like in the editor or when you run the game?

Assuming you're using a dynamic font, occasionally as you are displaying new characters the character get added to the texture. If the texture ran out of space Unity will pump up the dimensions of the texture and the labels need to be refreshed with new UV coordinates.

If it is in the editor doing a save will usually refresh the panels and cause the geometry to be regenerated with the correct atlas. If this is happening in the game itself the UILabel's texture coordinates are not being updated properly. See if you can manually refresh the panel that it is located on UIPanel.Refresh().

72

NGUI 3 Support / 3.0 UIPanel Depth/DrawCall Management

« on: September 24, 2013, 06:03:26 PM »

I started to get my project upgraded to NGUI 3.0, but I'm really concerned with how the UIPanel is breaking up the draw calls per the editor breakdown. In the past I have didn't use the depth of a widget really at all. I had been using the Z position of the widget in order to maintain depth ordering and creating new UIPanels if I needed to sandwich. However, after upgrading I ran into some problems.

UIPanel1
|
---Sprite Depth -1
---Label Depth 0

UIPanel2
|
---Sprite Depth -1
---Sprite Depth 1
---Label Depth 10

Assuming the labels use dynamic fonts, I expect UIPanel1 to be 2 draw calls and I expect UIPanel2 to be 2 draw calls. However, what I seem to be seeing is that the UIPanels are splitting their materials and draw calls on a global level rather than a per panel basis.

If I assign a unique depth to each widget the panels will seem to sort this properly. However, my game UI has a couple hundred widgets and if I have to maintain a unique depth for each widget at a global level it will be a huge PITA. I expected that the UIPanel would sort their draw calls on a per panel analysis of the depth of the widgets.

Is this global depth check a bug or is it intentional?

73

NGUI 3 Support / Re: 3.0 and UILabel Scaling

« on: September 24, 2013, 01:30:52 PM »

I feel that this is a step backwards from the control we had with setting the scale of the font, and is causing me to rethink how fonts would need to be handled in our game. Especially, in regards to high-dpi screens. Previously, halving the font scale to create a cleaner text on high-dpi devices. Granted you always wanted to balance the aliasing, but at least I could do that a per label basis rather than creating new UIFonts.

I'm curious on what other people are doing for their labels. Just setting the UIRoot fixed size to be retina at start?

74

NGUI 3 Support / Re: 3.0 and UILabel Scaling

« on: September 23, 2013, 06:40:02 PM »

Changing the height on all of my labels to scale the font makes me sad. Personally, when I see a content setting called "Shrink Content" it would be a shrink-to-fit mechanic where the UILabel will scale the print size to display the content as a size that can fit in the width and height of the widget. I understand this behavior was not how NGUI <3.0 worked in regards to this scaling, but I honestly didn't use it that much because I could more easily change the scale of the label. Especially with multiple UILabels, the multi-edit function of the Transform was more useful. Now I need to change them all manually which is a workflow degradation.

Hopefully, shrink-to-fit and/or multi-editing UILabels can be something that can be added in the future to help.

75

NGUI 3 Support / Re: 3.0 and UILabel Scaling

« on: September 23, 2013, 02:29:17 PM »

Thanks for the response, but that isn't the problem that I'm encountering.

If I set the line count to 0, the UIFont.WrapText will just create an infinite number of lines. This is not the desired behavior. I need to set a static widget size that the contents will scale in both the height and the width in order to fit that widget's width and height.

From my digging so far, shrink content is ignoring is ignoring if the text actually fits the width or not. It only triggers on height doesn't fit because the maxLines is 0 if the height of the font is too large. The problem appears to be that UIFont.WrapText is returning true that the text fit even if it needed to truncate the text. Which is causing the following line to never execute thus reducing the size of the font if it is the width that doesn't fit
else if (mOverflow == Overflow.ShrinkContent && !fits)

Edit: One problem is that this in UIFont.WrapText() is returning true using this logic:
return (!multiline || offset == textLength || (maxLines > 0 && lineCount <= maxLines));
So regardless of how many lines actually were rendered if there is 1 line (multiline is false) it will always assume that the text fit. This isn't the only problem though, but one of them I feel.