Messages

16

NGUI 3 Support / Widgets anchored to panels occasionally position themselves using a wrong camera

« on: September 30, 2016, 02:41:33 AM »

Pretty weird editor side error, not sure what can be the cause of this. It usually happens when the Editor loses focus, for example when you switch to your IDE or browser and come back later - at that point, there is a chance that UI widgets anchored to panels (for example, some top-level UIWidget holder attached to a top-right corner of it's panel) disappear from view of the UI camera and go into some extreme position like (-23223485, -6451236). This can only be fixed by reloading a scene or by pressing Apply on a prefab enclosing your UI hierarchy (that probably calls some method like OnEnable that reruns parts of UI code responsible for the issue).

I was very puzzled about the possible reasons behind this until one day I moved my main gameplay camera around an area where UI camera and elements are situated. I've left the UI layer rendered by the gameplay camera so that you'll see the situation clearly:


▲ WebM, click to view

And here is how things are supposed to work, properly anchored to UI camera:


▲ WebM, click to view

What might be causing this temporary use of a completely unrelated camera?

I'm using Unity 5.4.1f1, up to date version of NGUI. Nothing exotic about my setup, just one 2D UI in the scene, arranged into a traditional NGUI hiearchy (parent -> camera, root -> panels -> widgets).

17

NGUI 3 Support / Re: Pixel-perfect bitmap fonts in NGUI - 2015

« on: August 22, 2015, 02:09:06 PM »

There are two TTF conversions of the font, one of them is corrupted, yes. I used one from the Github, with Unicode support (*uni-11.ttf and so on), that one is valid:
https://github.com/koemaeda/gohufont-ttf

18

NGUI 3 Support / Pixel-perfect bitmap fonts in NGUI - 2015

« on: August 20, 2015, 04:50:33 AM »

Most of the tutorials I can find on the net date back to 2012-2013 and NGUI underwent many changes since, which makes me doubt whether I'm doing everything right. So I'll try to make a short tutorial on that - please correct me if anything I'm writing here is wrong.

Let's say I have a .ttf source font. Popular example of one is 11px GohuFont:



How do I get it into NGUI with the same pixel-perfect crispness? Obviously, Dynamic Unity fonts are out, I should be using atlased bitmap font. As far as I see, there is a Font Maker tool now.
Unfortunately, I was unable to get good results out of it's Generated Bitmap mode: unless you leave the default size value of 16 unchanged, Font Maker creates a mess like this:



And setting glyph size to 16 is obviously incorrect for this font:



So I tried another approach - digging out BMFont and importing my .ttf there. I used the following settings:



I then used the resulting .txt definition file and .tga atlas file, plugging them into NGUI Font Maker switched to Imported Bitmap mode.
The resulting font prefab looked more like it:



Except, obviously, alpha was missing. I tried to change BMFont export options with no luck, it insisted on exporting RGB or grayscale image with no alpha. So I simply created a new image with white fill in RGB and BMFont output in A, and reimported the font using NGUI Font Maker with that new texture. Now that's better, I'm getting almost perfect replication of results I wanted in game view, especially with pixel perfect snapping of widgets:



Only doubt left is texture filtering. No matter how well pixel perfect alignment lines up your labels and sprites, wouldn't the bilinear/trilinear filtering unavoidably dilute and dim the edges, especially pixel-thin lines like ones used in such a font? If you need 1:1 translation of pixels with no smoothing, why not set the filtering of your atlas to Point mode? Well, after trying it out, I'm not sure.



I'm unable to pick up any differences in label pixel colors between Point and Trilinear filtered atlases. It's not even subjective, Photoshop Difference layer mode literally returns black everywhere.
So, I guess Point filtering only makes sense in some exotic cases - for example, when you perfectly scale up your UI by 200 or 300 percent on XXXHDPI Android devices. In that case, getting crisp pixels on magnified sprites can only be achieved like that.

Did I miss anything, or that pretty much covers it all?

19

Misc Archive / Re: Building Material Design UI with NGUI

« on: December 19, 2014, 07:26:43 AM »

Not earlier than the middle of January I'm afraid, too much is still missing or unfinished.

20

Misc Archive / Re: Building Material Design UI with NGUI

« on: December 11, 2014, 10:37:53 AM »

I'm just frequently borrowed to do other work, so this project is moving forward slower than I would like.

21

Misc Archive / Re: Building Material Design UI with NGUI

« on: December 10, 2014, 03:09:01 PM »

Great news everyone! Responsive layout system progressed very nicely and is pretty different now from object-based draft I showcased above. First, to remind you what responsive layouts are, simple illustration:



There were two biggest issues with the previous implementation:

• You had to set up the objects in one centralized and unintuitive custom inspector that was disconnected from real UI hierarchy, which is far cry from intuitive and fast anchoring editor every NGUI widget offers you on selection of particular widget within the hierarchy.
• The implementation used simple enabling/disabling of GameObjects, and you really don't want to deal with that most of the time: imagine having half a dozen of functionally identical data-driven scroll lists instead of one, it's awful.

Both of those issues are out and workflow is much more straightforward now. First, you set up desired resolution brackets. For example, maybe you want to have one layout for screens of below 480dp width, another layout for screens between 480dp and 640dp width, and another layout for screens wider than 640dp. Easy! Just set up your intervals with this neat array in the screen manager (featuring auto-configured clamping to nearest neighbors with fancy sliders and warnings):



Second, add a new component to any UI widget you want to be density dependent. Depending on amount of resolution intervals set up in your screen manager, that component will store appropriate amount of anchoring configurations. The component is not attempting to replace the perfect anchoring editor from NGUI - you still use the familiar controls, except you can save your configuration to one of the resolution brackets. Set up your anchoring for a narrow screen, click the copy button on narrow configuration, set up your anchoring for a wide screen, click the copy button on widescreen configuration. Done.



The screen manager maintains a list of resolution-based anchor components and swaps anchoring configuration to appropriate one depending on detected resolution, giving you results like this while keeping your data-driven UI free from pesky duplicates or other inconveniences. There is no need to set up dozens of resolution-based anchoring configurations either - in some applications, the whole design can be hierarchically anchored to just one widget, necessitating just one collection of configurations on that topmost widget.

Aside from this goodness, I worked on some other stuff like refactoring and new view presenters. One of the new object types is the dropdown menu. While still work in progress, it's already looking quite good:

• It's using just one label for all the options: no separate labels/colliders/delegates, which conveniently prevents hierarchy clutter and instantiation costs on option list length changes. I get the selection from local touch position.
• As usual, everything is animated through a simple evaluation: one tweening method with 0-1 float argument does all the magic with sliding offsets, sheets, shadows, spacing, colors, etc. No dozens of tweener instances, no Unity animations, clean and fast.
• It expands from the list position of a selected value, just like guidelines dictate. Tricky to combine with this animation, but as you can see, it works.

22

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

« on: November 26, 2014, 05:44:54 AM »

Look at the standard NGUI shaders, notice the postfixes like " 1" and " 2" in shader names, check the code that handles NGUI materials. As clipping is done through shaders, you must prepare clipping compatible duplicates of any custom shader you use in UI, and name them in the same way so that NGUI can find them.

I'm not sure I understand why would you want to use custom shaders at all, though. What's wrong with using standard vertex color driven coloration from NGUI tools?

23

Misc Archive / Re: Building Material Design UI with NGUI

« on: November 05, 2014, 02:27:41 PM »

One particularly inconvenient issue with designing UIs for multiple screen resolutions and densities is how you need radically different proportions and layouts to cover all cases nicely. You don't want lines to span a 4k display horizontally and you don't want your sidebar to eat precious horizontal space on a narrow smartphone screen. So you need to make design responsive.

Uh, well, I solved that, more or less.



I thought about the issue a bit and found a somewhat elegant solution.

• First, to avoid absolutely horrifying math involved in managing non-overlapping interval lists, I implemented screen resolution intervals through making simple int lists where you define not intervals, but midpoints between them. You can define any amount of midpoints you want - for example, 320px, 480px, 640px, 720px and 1280px in the case of that gif.
• After that, you can manage a list of layout groups, which contain a GameObject list and two integer sliders allowing you to select the resolution bracket from points you have entered before. Then simple validation logic hides and shows stuff as necessary.

Current implementation looks like this in inspector:



A bit ominous (I can probably get neat color coded interval visualization going for every group), but very easy to use.

24

Misc Archive / Re: Building Material Design UI with NGUI

« on: November 03, 2014, 07:53:37 PM »

After wrestling it for few days, finally got it working. Fancy clipped screen transitions straight out of apps like Google Inbox!

25

NGUI 3 Support / Re: [Solved] Forcing an update of every single anchored widget after root rescale?

« on: November 03, 2014, 07:15:20 AM »

Ah damn, you're right. That's what I get for staring at the screen for too long.

26

NGUI 3 Support / Re: [Solved] Forcing an update of every single anchored widget after root rescale?

« on: November 03, 2014, 06:36:54 AM »

That's exactly what I'm talking about, they do not run in Editor play mode while they do in edit mode and standalone build. At least that's the impression I get from this pattern:

1. #if UNITY_EDITOR
2. if (!Application.isPlaying) UpdateDrawCalls(); // wouldn't that make editor play mode the only excluded situation?
3. #endif

A simple example is calling Refresh on the root panel after changing screen dimensions. In editor edit mode, it works great, updating all interdependent anchors. In the deployed build it does the same. And only in editor play mode it seems to be cut off by the check and does nothing, making repeated forcing of OnEnable method through toggling root GameObject the only working option to force anchor update. What is the intent behind introducing that difference between builds and editor play mode?

27

NGUI 3 Support / Re: How to force UIPanel child widgets to switch to a higher panel on panel disable?

« on: November 03, 2014, 06:13:18 AM »

Yeah, ParentHasChanged has zero effect unless the panel in the middle is destroyed and not just disabled.

I can easily get every widget and reparent it to a new panel, but I don't think it would be a good idea because I will be completely unable to restore the old scene hierarchy afterward. It's one thing to parent an object neatly holding stuff inside, it's another to parent every single UIWidget that was sitting god knows how deep in the hierarchy. I'm just animating a screen transition by this texture-clipped panel, so all hierarchy has be in it's initial state just a second later, the less reshuffling, the better.

I guess I'll try getting transform children instead of UIWidget references, should probably work without breaking stuff. I'd rather not use a panel-less empty object for that.

28

NGUI 3 Support / How to force UIPanel child widgets to switch to a higher panel on panel disable?

« on: November 02, 2014, 10:15:39 AM »

I'm having a bit of trouble with an exotic case: for a certain screen transition type, I parent an object with a panel hosting some widgets to another object with a texture clipped panel, play some animations with higher-level texture clipped panel, then restore the hierarchy back. Trouble is, I can not figure how to disable the moved panel for the duration of that scene without killing the rendering of all child widgets.

To explain, here is the standard hierarchy:

Clipped panel (enabled)
Normal panel (enabled)
- Widget

And here is what happens for the duration of screen transition:

Clipped panel (enabled)
- Normal panel (disabled)
- - Widget

Problem is, the moment I disable the normal panel, every single widget stops rendering, probably because it's supposed to do that due to UIPanel OnDisable method. But I don't want that: I want the widgets to continue being rendered, just using the higher panel in the hierarchy: clipped one. And I'm unable to do that. So far I have tried lots of combinations and different orders of normal UIPanel component .enable setting, widget.ParentHasChanged() calls, direct widget.panel parameter reassignment, panel Refresh() calls, and some other methods, but nothing seems to work - absolutely invariably, once I disable the normal panel, every single widget linked to it will disappear.

The only way to get the desired behavior I have found was to destroy the UIPanel manually from the inspector. That's obviously very undesirable way of doing things, I'd prefer not to have a hassle of caching all panel properties to recreate it later and I'd prefer not to risk GC rushing in during 1 second long buttery smooth animation. I just need to replicate what happens to child widgets when a panel is removed, without actually removing (only disabling) it. But I'm not seeing any OnDestroy behavior in UIPanel, so I'm not sure how exactly widgets actually move under command of a higher panel. It's reliably happening and it's exactly what I need, but I'm unable to track how it's done. Can someone shine a light on that?

29

NGUI 3 Support / Re: [Solved] Forcing an update of every single anchored widget after root rescale?

« on: November 02, 2014, 08:18:54 AM »

On a slightly related note - what is the reason behind UIPanel methods UpdateDrawCalls, CalculateFinalAlpha, LateUpdate and a segment of UpdateWidgets method being explicitly forbidden to run in the Editor play mode (through directives and !Application.isPlaying checks) while they are allowed to run in the deployed builds? I'm not sure I understand the point of that as it makes panel behavior different between editor and real builds.

30

Misc Archive / Re: Seeking a 3D Artist

« on: November 02, 2014, 06:33:30 AM »

Yeah, I had some obligations at work and haven't had the time to update the mod for quite a while. It's in good state now though, supporting the latest version and all. By the way, funny story, but some parts from B9 were started as a test assignment before that job: http://www.gamasutra.com/blogs/ArtyomZuev/20130731/197365/Environment_art_and_modeling_in_Kerbal_Space_Program.php

P.S.: Sent you a PM.