Tasharen Entertainment Forum
Support => NGUI 3 Support => Topic started by: SmartyP on January 23, 2014, 10:07:56 AM
-
In Unity if I go to the menu NGUI > Create, the '2D UI' and '3D UI' menu items are disabled / grayed out. If I open another scene they are working fine, so it seems specific to my scene. I tried deleting other UI's I have in the scene to see if it was some sort of limit, but had no luck. No luck searching so far either..
Thanks in advance!
Edit: Oh ya, I can get around it in the short term by copying/pasting a 3D root from another scene..
-
Can someone please clue me in? I'm continually running into the 2D UI and 3D UI menu items being disabled. Is there a limit of 2 UIs per scene.. ?
Thanks again!
-
Same thing is happening to me.
-
Strange, I don't think there's any limits to that. Try selecting something in the scene and see if it changes.
-
If you already have a UI in your scene, the option becomes disabled. Perhaps I shouldn't do it?
-
How would anyone have a combination of 2D and 3D UI's without allowing multiple NGUI roots?! I think disabling the menu option is a very bad idea, and I'm not sure the reasoning.
And why did you remove the "Create GUI" dialog? That's where you could set the desired layer. Now you have to create it and then manually go in and change all the layer references. What was the thinking here?
-
Why bump an old post? NGUI doesn't disable the menu options anymore if that type of UI doesn't exist. 2D UI and 3D UI are different menu options.
The UI layer is chosen automatically now. Unity 4.5 has a built-in layer called "UI". If you want to use something else, select the UIRoot and change its layer like any other game object.
-
I bumped the old post, because it was the one that I was dealing with the issue I was having.
I do see that there are 2 menu options, "2D UI" and "3D UI", however they were both disabled for me. I looked in the code, and both menu items were being disabled by the same line of code: UIRoot.list.Count == 0.
Perhaps I have an older version of NGUI, but that doesn't allow one of each UI types to be created. I went ahead and simply removed these checks, and now I can make my UI's just fine.
As for Unity 4.5's built in layers, I am still on 4.3.4, so perhaps that's why my layers still don't match up automatically. Plus, I assume the 3D layer would need a new custom "UI3D" layer or something.
Anyway, sorry for rehashing an old thread, but there are quite a few versions of NGUI kicking around, and it's hard to stay up with the very latest. Thanks for the response.
-
Quite a few versions kicking around? Unless you pirated it, there is only one version -- the latest.
-
I came across this issue recently as well and can't understand the logic as to why they are disabled.
NGUI in theory can can contain multiple UI setups which may be split due to logical considerations.
A use case where everything is under one root is not the only one.
Why block the user from generating something automatically that just makes it faster to work?
-
The logic for the disabling was actually flawed. I just tweaked it some.
-
Forgive me if necro posting is a serious no-no. My searching lead directly here, and the question for the original post wasn't clearly answered (for my humble abilities to comprehend ;) so I figured that staying here would help contain the issue to one place. I'm using version 3.7.2.
I have a project with MANY separate UIRoots with many different layouts and camera behaviors, and ways of layering those cameras. Various UIRoots are turned on and off as the user moves through the experience. From this thread I'm starting to wonder if my methods are somehow flawed, or if I'm missing something obvious about why you wouldn't ever want to use more than one UIRoot construct per scene. That philosophy is implied by making the menu item disabled when a UIRoot is detected. ArenMook indicated that disabling (graying out) the menu item NGUI >> CREATE >> 2D UI or 3D UI was removed, but it is definitely making this menu item unavailable for me when I forget to hide any of my other UIRoots. You'll note that hiding your other UIRoots is any ease work around.
Am I doing something I shouldn't be with my current methods? Why would you ever want to make this menu item unreachable? Is this a feature meant to help new users understand that in most cases you wouldn't want to have more than one UIRoot at a time? (and my project is either unique or flawed)
-
It may be my limited vision, but I fail to see the advantage of having multiple UIRoots in the scene. Do you use different sizing schemes or something? What does that add that you can't do with a single root? It's always fun to see when people use stuff in unexpected ways, so I'm genuinely interested in why you would make it like that, paulygon. :)
Depending on how the different stuff in implemented, you might run into problems with getting UIRoot.pixelSizeAdjustment if you have multiple UIRoots in the same layer - it wouldn't know which to use.
-
That's funny, I'm having trouble seeing the advantage of only one root then trying to manage 30+ panels and draggable cameras in that single node. Currently, I can turn off a single UIRoot to hide everything associated with the given UI. Maybe it doesn't really make a huge difference either way. It just seems like having this much content buried in a single parent would make working on the separate pieces a nightmare.
Here's a snapshot of my current setup. Each item labeled "scrolling text" is a UIRoot.
-
That's quite a mess you've got there. Here is what my UIRoot looks like in Windward: https://www.dropbox.com/s/xcl49on54dtreue/Screenshot%202014-09-17%2013.04.44.png?dl=0
Note how I have everything clean, and under one root? This way if I don't need to work with the UI, I only have to fold one object -- "2D UI" instead of 50-some like in your example.
All those objects underneath the 2D UI in my screenshot that have [XX] prefix are panels. I can open/hide them quickly from the Panel Tool, or just by selecting them and using ALT+SHIFT+A.
-
Thanks for sharing that. Most of my projects that use NGUI (meaning all of them ;) look like ArenMook's example. I spent a ton of time just now trying to justify my current project's organizational method. I still can't find a compelling reason to rebuild it all just to bury everything under the same root. My project would be the same mess, i'd just have to open the now singular root it's under to see it all. Of course I'm worried that half way through rebuilding I would run into problems that I can't predict until I've tried it, versus now, everything works great. Again, what would that gain except having to open one root object to see what amounts to the entire game's content?
-
A single place for setting fairly basic values (UIRoot) is in itself a good reduction of error potential. Generally, I would load things dynamically instead of having everything loaded from the start though, but that's not necessarily needed depending on the complexity of the menu. It's a classic DRY issue - if you need to change your root values now, you're in for a headache. You'll also have to check each and every root in your project to make sure they're all the same, because otherwise none of the pixel values will correspond properly to each other. So there's repeated overhead in your setup, with no real added value other than 1 level of hierarchy saved for organization.
I see no compelling reason for it, based on what I see here, and honestly if you were one of the programmers on my team I would bonk you on the head with a paper and make you change it. :)
If you have significant changes, then you can potentially justify it; say an entirely different camera set up, or something like that. Right now, it seems to just be for saving 10 pixels on the x-axis in the hierarchy view, which seems to be a big headache for not very much gain.
Assuming that all the roots are identical anyway, then changing it is nothing more than dragging the content into your "main" root and cutting out all the other stuff.
-
LOL, point taken Nicki. As you said, it might not be as bad a switch as I imagine. I'll have to experiment to see.