Author Topic: (!!!) Improving NGUI: Voice your opinion  (Read 166890 times)

breakmachine

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 71
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #30 on: November 15, 2013, 12:04:15 AM »
How about packing dynamic fonts in separated channels (rgb). Would that optimize anything?

Nicki

  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 33
  • -Receive: 141
  • Posts: 1,768
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #31 on: November 15, 2013, 04:01:12 AM »
The single most annoying thing in NGUI for me, is a tiny thing with how buttons-touches are handled.

If I tap down on a button then slide my finger off the button outside, then button should "deselect" (visually change away from the tapped state) but no other buttons should receive input if I slide over them, since the one I tapped down on should be the only input receiver. If I think slide back over the original button it should re-activate, and if I release on top of the same button I release on, it should count as a click.

The way it works now is weird to me.

Either you have sticky press, in which the button keeps being tapped down no matter where your finger slide, or sticky keys of, in which it's even weirder and you can slide over a new button and have that count the same as a OnPress.

I want to be able to slide out of a button to cancel the click visually, but be able to slide back to re-enable it.

Ramble ramble.

BGL

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 9
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #32 on: November 15, 2013, 04:26:03 AM »
Data binding has already been prototyped, and the Pro version has some testing code in it that has the framework for it. I'm still not entirely sure I understand what's the best use case for it. I use it to be able to set both properties and values of a remote script by name -- which, while cool, seems like a strange way of going about it, since I can just do a GetComponent and set the value directly. I can think of a couple semi-useful use cases, but I'd like to hear what you guys would use it for?
Data binding is very useful to totally separate UI logic and UI appearance. Your UI code will not relay at all on the hierarchy of UIWidgets, they are separated. For example with data binding if you expose a bool like MyLogicIsValid, you can change totally your UI without a line of code, for example changing the appearance of a button to look disabled/enabled, display a string that tell the user that something is not valid and even play an animation on value switch. Another example, if in my UI logic there is a list of 100 items exposed, I can choose to show them 10 by 10 in a scroll panel, then I can add a preview for the selected one without changing any code; I can even change what I show for each item, as far the properties are exposed, and how, if for example there is a string property, I can show a UILabel or a UISprite.
When you work in a team it will help you dramatically improve UI development speed, maintainability, big task splitting...even more in a big company.
I can continue with the benefits and the use cases, but I think this could be enough.

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #33 on: November 15, 2013, 07:14:47 AM »
@haueryou26: It's not possible to pack RGBA textures, which are 4 channels, into a single channel. Packed fonts can do that because they only have 1 channel of data (RGB is assumed to be pure white, only alpha is needed). Unless your entire UI is made up of semi-transparent white areas, it's not possible to pack it into R, G, B, and A channel.

@BGL: What would you bind to what in your example? Say the "enabled" state of a collider... bound to what? Any script and/or animation can change the enabled state easily. Same would be with any widget property. The benefit of doing this is what escapes me. An artist-centric use-case example would be nice.

Antares88

  • Newbie
  • *
  • Thank You
  • -Given: 3
  • -Receive: 0
  • Posts: 35
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #34 on: November 15, 2013, 08:59:47 AM »
Aren,
it's really great that you take into account the voice of the community for the future of NGUI and uGUI.

That said, IMHO it would be useful to many if you manage to spend some time on the documentation and tutorials.

There's still a mess around with info related to old NGUI versions. Having more complete and up-to-date material in evidence would be great.

Thanks for your efforts.

haueryou26

  • Guest
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #35 on: November 15, 2013, 10:51:18 AM »
@ArenMook:  So I thought there might be some push back on the idea of packing UI into the R,G,B channels.  So I'm providing a link of another person proof of concept that you can pack into the individual channels of a single texture and still have it work for yours needs. Please look at http://www.polycount.com/forum/showthread.php?t=89682&page=9  This entire environment was created in this method of having a single texture.  One might say well that is an environment and that's why you can get away with it.  I personally don't believe that to be the case.  I believe you can use this same process for UI and each channel would by default be black and white.  You would get your variation from unique shaders or hard coding in albedo tints.  Its true that if you have UI that has multiple colors associated with a single image you would not be able to do this.  In my pipeline if this happened where I had UI element that needed a range of color in a single asset I would simply make a atlas for these fully colored UI elements and another atlas for all my black and white assets.   I have already worked with studios doing this kind of optimizations at Microsoft and believe this is where the industry is going.  Anyways if your don't have plans to support this memory efficient UI workflow, I understand. I do however see this being a huge win for your product and would have bought your product again just to have this kind of functionality.

Ps.  I apologize for the run-on sentences, I'm super tired this morning.
-Stephen Hauer
« Last Edit: November 15, 2013, 11:02:58 AM by haueryou26 »

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #36 on: November 15, 2013, 11:28:08 AM »
Yes, if you create a single texture where you encode black-and-white sprites, it works fine. As I said, it only works if they are black and white. The only way to get color in there is to use one of the sprites as a mask as well. So now you have a black and white detail texture + color mask.

It's not something suitable for GUI atlasing. You can create an atlas like that in Photoshop by hand, surely, but it is not something that would work in a production environment with RGBA user textures.

Quarkism

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 48
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #37 on: November 15, 2013, 02:36:37 PM »
Regarding DataBinding :

http://www.avariceonline.com/Products/Mvvm

I plan to be releasing this shortly for under between $20 and $50 (not sure yet). I'm currently revising the Lobby for NGUI 3.

If the new UI is still not released then I might just release it with NGUI with a promise to upgrade.

One caveat, it does use reflection and JsonFX. It should work on IOS (I don't use Reflection.Emit) but I haven't tested it yet as I do not have a mac.

I come from a microsoft background where MVVM is a big thing. The solution is molded after that. It supports using both monobehaviours and model classes (clr objects) as binding targets, complex hierarchies, two way binding and a bunch of other features.
« Last Edit: November 15, 2013, 02:43:43 PM by Quarkism »

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #38 on: November 15, 2013, 10:00:29 PM »
Hehe... a plugin for uGUI -- a system that's still in pre-alpha? :)

Ugur

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 60
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #39 on: November 16, 2013, 12:46:04 PM »
Ok, i take the time to give some long feedback, too.
Now i say it upfront, this is not intended to be a bashing of NGUI, NGUI came in a time where there were only way worse gui options in unity and most people still relied on using ongui or building their own gui solution from scratch.
Ongui lead to too many drawcalls (hence bad performance on mobile devices of back then), no multitouch support and no way to create anything in visual workflow in the ide.
So NGUI addressed all those downsides and was also way better than all the other offerings back then and we used NGUI in many projects successfully and that was a big gain for us so i'm thankful for that =)

It also allows to do 2D and 3D UIs and combine them, animate them in both 2D and 3D etc, which still today not many others do that well.

Now comes the "But" or to name it positively improvement suggestions =) Both for NGUI and also possibly new future Unity builtin gui, listing things which are lacking and should be added or improved:

Over the course of using NGUI for many projects, time and time again i stumble over the same limitations on a few ends which make some things way more cumbersome and time intensive to do than they should be.
I catch myself fighting against the same type of limitations and adding the same kind of workarounds and extensions over and over and at the same time having to redo way too much because things are not well portable between different projects, scenes or atlases.

I'll list the major ones of those and for some also how i think those should/could be addressed:


-In NGUI one has to build together scrollable textfields, scrollable lists and two directional scrollpanes together by hand out of various components/scripts. Even more basic controls like buttons, checkboxes/toggles, dropdown menus etc, all has to be handmade from several parts/components/sprites.

It is good one can build together all parts of things when wanted, but no good that there's no built together ready to use scrollpane control or button control or checkbox control for example which one could just drop in and use, just choose the sprites used for the parts, the font and be done with it, or stick with the ones used by default thanks to the builtin controls coming with builtin atlas images (which merge to your atlas).

Since there's nothing like that, this also leads to various other issues like way too cluttered gameObject/component hierarchy and numerous additional depth sorting complexities issues cause instead of say one gameobject with a scrollpane controller attached to it one already has many nested gameobjects with scripts and depth sorting issues items on them to get a scrollpane going.

-same goes for having to build together any other control like a checkbox or button. Again, nice one can build one together out of several sprites and scripts and gameobjects etc, but yeah, there should also be a ready to use checkbox and button etc control which i can just add in and it comes with default sprite for checkmark and bg and label and i can switch that to something else and be done with it.

-that also goes for things like a scrollable list, there should be a scrollable list control which one just drags into the scene, it has in the inspector a default list item (icon and label highlightable toggle button like list item) prefab builtin ngui list item pre selected and one can edit or replace it. And there should be several premade builtin list items for the standard things (toggle button with bg, highlighted bg/color, icon and label, or datagrid list with multiple labels and sortable on headers)

For these premade UI controls (a full checkbox a full button, a full scrollable list, a full scrollpane etc) there should be a GUI skin which by default uses a builtin atlas and then one can just for the parts they use (like a label, button bg sprite etc, scrollbar thumb sprite etc) choose a fitting image from the atlas one has and they all look right then.
One could further improve reusability of atlases, skins and controls by extending the atlas system so that there is always a spot/name for the images of the builtin controls' used atlas images (like a panel bg, button bg, scrollbar bg, scrollbar thumb, default font etc).

Right now stuff we create in NGUI is only really reusable to the degree where we do something with the same atlas in same look in another project. Otherwise stuff made in one project is completely unreusable in another project cause one has to make all those controls from scratch again and it is tricky to change to which atlas/camera etc a control belongs and which images it should use etc without changing all those things by hand for each separate part of a control.

i bought a few ngui controls packages from the asset store for example and really, besides showing to a newbie how to set up things in ngui or if one wants to use those controls with exactly that atlas/ skin, they are basically useless in another project, cause of the way how cumbersome it is to replace just which atlas/images are used for the different controls parts.


A basic example: In the sample scenes coming with ngui there are different atlases used for different scenes.
Just try to copy let's say gameobjects from the  scrolling list example scene with wood atlas to one of the scenes with sci fi atlas and try to get those two using the same atlas and work fine together there.
Very Painful, time consuming and tedious.
What should happen is: I paste a scrollpane control from the other scene into this scene, it recognizes i used an atlas/skin which is not used in this scene, it asks me if keep this skin of the pasted items or replace with one of the skins used by the items in this scene and blamo, all components look fine, use the same atlas and work with the right camera etc.
If on top as i suggested each atlas automatically has slots for the images of parts of builtin controls like builtinControlScrollBarThumbImage then it would automatically use the right image from the other atlas.
And since the scrollpane has for example exposed a field for scrollbarbg, scrollbarpane,scrollcontentbg, scrollcontentframe, i could either just replace those sprites or if my other atlas has items with that same name (which then all atlases should have by default for all builtin controls and the parts textures they use) then it would just use those.
So basically ngui should get a guiskin skinning model like OnGUI has it for the standard controls and their part sprites/labels.

add standard control (button, toggle, checkbox, scrollpane, datagrid etc) to a scene
—>the atlas would get sprites added from a builtin ngui atlas for all those parts those standard controls use like standardControlScrollbarThumb. If an atlas in this scene already has sprites of that name it would ask if one wants to choose those or replace them.

Huge gain in reusability, portability, quick skinning ability etc.



Ok, onto another big issue: using certain relative screen dimensions.
NGUI has anchoring covered and stretching of items covered to certain extend. But what should be possible would be one can place a container rectangle on the screen (and premade controls like a scrollpane contain that, too) where one can stretch/resize the control and toggle an option to set keep relative screen dimensions and then  the control automatically uses that relative screen size.
so let's say i use a scrollpane which starts at x 110 y half screen height and then fills up half the screen height, then when the screen is twice the height it should still start (procentually relatively) where it did and cover half the screen height.
Right now its too cumbersome to make a control made out of lots of components, like a scrollpane, cover a certain relative screen percentage and make it always cover that certain relative screen dimensions and adopt to different resolutons/screen dimensions.
One should be able to set for x/y/z, width/height of a control if it should keep that position absolut (actual pixel values) or relative (screen percentage) when screen size changes.

-masked/clipped areas: One should be able to set the dimensions of those with a rectangle and that should have its offset anchor on the top left, not set up in a way where one has to put it in the center and then stretch in both directions. Same goes for hit areas. Hit areas should also by default cover the bounding shape of the whole control (when not toggling off that option it should resize automatically as one changes sprites etc used in the control or the dimensions of the whole control)


-text is never satisfying to me in ngui: either not sharp at different dimensions with bitmap fonts or depth sorting issues when using usual fonts since then basically the rest of ngui and those fonts don't play in the same depth sorting worlds properly.

-a better way to handle how to react to different resolutions and ppi, be able to set as general default and per control how to react to different resolutions/ppi. Really keep the same actual screen size dimensions for a control on per control level decidable or scale relative to the screen res/ppi.

-bad list performance:
using tiled sprites and images not part of an atlas (UITexture) as list items in scrollable lists is an extremely performance intensive thing since it leads to high polycounts and extra drawcalls,and lists with many list items aren't a great idea in general cause it still always handles all list items which are not in view/clipped.
Something like that should be improved, too, like for a list item when i set a tiled sprite or gameobject (with numerous sprites etc) as bg, it should give the option to add that as extra sprite so then it would make a bitmap image clone of that bg as it shows and add it to the atlas so then only using that one larger image as two tris rectangle instead of at runtime having that rectangle made up of many rectangles in small size with many tris.
This would also address another issue for containers with many items which is it then moans too many vertices and can't display it in same panel anymore with same clipping area anymore.
If i know my list item bg which is used for all list items will always have the same dimensions and use the same tiled sprite, why not just add the whole computed thing to the atlas so it uses two tris in a rectangle with that bg as one atlas element instead.
In lists it also shouldn't always handle all elements, it should allow dissabling/not drawing those outside the clipping area. Even more ideally it should on visual side only create enough list items to fill the clipping range+2 and then reuse those when one scrolls by changing their label or other per item changing content.

-there should be anchors for anchoring relative position within containers

-there should be tab focus switch between controls

-there should be supply psd and choose where the sprites are in that

-no kerning, line spacing and generally too few text controling features. what about set a label to autosizize left, right etc, scale to fit only in one direction, get the dimensions of a label easily
(easy as in label.textWidth), copy and paste in textfields, drag select text etc


-the new custom transform handles are bad and should go or at least they should always be behind the usual transform move tool handles so one can still use them

-i won’t even go in detail into what would be the next major and great step after all those: being able to design vector graphic ui control’s parts (like a bg or similar) inside unity and have the option to have that added to the atlas (next to it storing the vector points/fill info internally for editing again later on) or rasterize it at runtime.



So really, it would help a lot already if it came with builtin atlas/skin for standard controls, some standard controls and an easy way to replace those standard controls atlas images/skin and use em/combine em/replace em in own projects and then take it from there with those other things i and others listed.
« Last Edit: November 16, 2013, 12:54:38 PM by Ugur »

Photic

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 2
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #40 on: November 16, 2013, 04:24:12 PM »
I've been working on a game that only uses ngui. My game might not be what ngui is designed for but it works a lot better than the current Unity GUI system.

I really like the boxcollider resize option on a widget that has a boxcollider, but I would also like to be able to resize a collider based on the size of a different widget.
For example:
 Button (has box collider)
  Background (with UIStretch)
  Label

I would like the boxcollider of the button to be the same size as the stretched background. I have made a script to handle this case, but I think it would a nice supported feature.

I'm not sure if it's been removed, but I can't seem to find the option to have a max width on labels anymore. In certain instances I would like the text to wrap rather than resize.
Previously when the option was there I would calculate the size of the entered text then calculate the how wide I wanted the text to be then set the width to that value. Then I would calculate the number of lines used based on total text entered and resize the background of the label to the desired height. All of this was pretty complicated.

So it would be extra helpful if there was an option to resize/stretch a widget based on the size of the text and to constrain the text width.

My next issue might just be my lack of understanding. I created a scroll view using the dual camera style and when I use grid or table it seems to center the list of items on the upper left bounds of the first item until I scroll for the first time, they're still off but they're closer to center after scrolling, but strangely the camera happens to jump to their center, instead of the items being centered in the camera view.

I would also like it if the grid and table supported different/dynamically sized items, I could be wrong but they seem expect all of the items to be the same size. I ended up creating a script to calculate and position items according to the axis they're stacked on to handle this. Though It would be nice to see a supported feature that would have items appended based on the total height/width of the item instead of a predefined size.

Thanks for listening :)

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #41 on: November 16, 2013, 08:47:04 PM »
@Ugur: Thanks, that's pretty detailed, but I have this feeling that you're not using the 3.X cycle version since you mention about having depth issues, and 3.X is all depth-only based and dynamic labels work the same as any other widget with depth.

@Photic: Regarding your box collider on button... why don't you just add a UIWidget script to your button then toggle the adjust collider option? I guess it's a fairly hidden feature...

Max width is just width of the label now. Resizing widget based on the size of the text... ResizeFreely on the label. If you want another widget to resize to envelop that label, UIStretch on it using that label as the container should do the trick.

Most of what I gather from this thread is this: NGUI is a powerful tool, but I suck at creating non-programmer documentation. :) I really should work on that. I'm thinking of adding help buttons to components and linking them to posts here, where users can always ask questions related to the topic directly.

What do you guys think?

Photic

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 2
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #42 on: November 16, 2013, 09:20:43 PM »
Oh awesome! Thanks for the info, I'll give that a shot.

Though I do feel dumb now because I am a programmer :P hehe

Ugur

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 60
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #43 on: November 16, 2013, 09:27:54 PM »
@Aren:
No, i'm using NGUI 3.0.5 and i still get depth sorting issues with that in complex uis where things sometimes get sorted in front and sometimes behind other objects etc and i have to always check what's the issue with which panel etc.

Most of what I gather from this thread is this: NGUI is a powerful tool, but I suck at creating non-programmer documentation. :)

I'll just assume you don't mean it in nasty way, and yeah, adding links to documentation one can easily access is not a bad idea in general. But yeah, the issues i listed are not due to lack of documentation at all.
Nor am i a non-programmer =)
I listed the strengths NGUI had and still has on a few ends over OnGUI and various other gui solutions for unity which came before NGUI. Thing is, it needs to evolve considerably (and so would unity's new GUI system have to if it follows NGUI's setup too closely) because its just lacking on a few ends which lead to controls not being well reusable accross projects and one spending way too much time on creating basic controls like a button, checkbox, dropdown menu, list menu or a scrollpane for every project with a bit more complex UI.

The basis is there and usable, but that there are no builtin out of the box ready to use controls like buttons, checkboxes, dropdown menus, list menus,scrollpanes etc means one has to build all those controls together before one can actually start to design/lay out the UI.
Why are there no prefabs for those controls using a builtin atlas?

And yeah, it would also need a gui skinning system with the then builtin standard controls coming with their default skin and then one could just replace those sprites in the atlas with own ones and have those controls ready to use.

Lack of such a system means one has to recreate way too much from the ground up for every project since one basically can't reuse controls one made using one atlas in another project using another atlas easily.

I don't think such and other things i listed are helped with better documentation, but yeah, if they would be implemented that would mean people spend way less time on creating basic controls, have em ready to use and also ready to use in multiple projects with different atlases etc and yeah, that would help to reduce the for you beginner seeming questions since the beginner stuff would come in ready to use form out of the box =)

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: (!!!) Improving NGUI: Voice your opinion
« Reply #44 on: November 16, 2013, 09:41:11 PM »
Quote
Why are there no prefabs for those controls using a builtin atlas?
There are prefabs for all basic GUI elements uGUI using a default (built-in) atlas. Come to think of it... I don't know why I never added them to NGUI. I really should.

As for my non-programmer documentation comment... majority of the documentation I write is in the code, so a dev would need to navigate to the function in the code to get a description of what it does (or check www.tasharen.com/ngui/docs/ I suppose). I was just thinking that adding a way to automatically open the web browser to get an overview of the component would be handy. Ima do it.