Brady,
Can you talk a bit more about EZ GUI launch features?
Is there any kind of GUI designer? I’m pretty curious about the drawcall numbers. Everything is packed down to one draw call?
As you provably know, Unity 3, will not support any new Gui system at launch. Theirs a lots of folks waiting for this kind of GUI enhancement! 
Cheers,
What are the added advantages of having a seat of SM2 as well?
What functionality does SM2 bring to EZ GUI?
What functionality does EZ GUI not have without SM2?
Also, I assume that (as opposed to on gui) raycast hits don’t penetrate thru the windows and buttons and effect gameobjects behind the window?
Sure, glad to! It’ll be hard to cover it all here, so I’ll just try to hit the high points, and I’ll let the release videos, etc, speak for themselves shortly.
Yes and no. Your GUI elements show up in the scene view and game view (just like sprites in SM2), and you can move them around to your liking. For “desktop” Unity, all controls allow editing of almost all parameters in the inspector. On iPhone, you can use the custom editor window (which is also available for desktop Unity). In short, it’s very easy to use as it is highly visual.
Yes, EZ GUI uses technology very similar to SM2, and is able to pack your UI graphics into a single atlas (provided it will fit onto your max texture size, of course, otherwise you’ll have to use more than one atlas, but no biggie) and results in a single draw call (not counting any text meshes). Text is handled using Unity’s TextMesh component. This is good because TextMeshes are batchable on iPhone, unlike GUIText. So if you are able to fit all your UI stuff onto a single atlas, and all your text uses a single font, you’ll come away with 2 draw calls for the whole thing.
In addition, EZ GUI uses some of the latest tech from SM2 which allows combining your sprit-based controls all into a single mesh to achieve single-draw call numbers on Unity desktop as well. So now the draw call savings are also available on Unity Desktop. There are some limitations to using the combined mesh approach, but also some advantages. It’s up to you which to use.
Another really cool thing is that EZ GUI allows single-click switching between mouse input and touchpad input. So you can very easily test your game in-editor using the mouse, and then change a single option and deploy to a touchpad-based device. Full multitouch is supported as well.
Initially, here are the main control types available:
There are also control management components which allow you to group controls together, much like using a window. These are called “panels”, and greatly ease the task of creating multi-page menus or wizards. Also included is a “transition” editor which is capable of assigning all manner of animated effects (not to be confused with sprite animation) to individual controls or entire panels full of controls. This supports all sorts of tweening/easing operations, and is incredibly easy to setup and use.
There’s also a third input type besides mouse and touchpad: “ray”. But you’ll have to wait until the release date in a day or so as that’s a surprise. 
The answer to all of these can be summed up thusly: Sprite animation.
Most EZ GUI controls are sprite-based (though not all, as you’ll see in the launch video). However, out of the box, EZ GUI’s controls support single frames for each control state (i.e. a frame for a button’s “normal” state, and another for its “over” state, etc). SM2 integrates seamlessly with EZ GUI, allowing you to add and edit sprite animation on any sprite-based control.
Yes, you can set the UIManager object to ignore all other layers but the designated GUI layer and only colliders in the GUI layer will be caught. This saves performance as well, obviously, by not testing rays against non-UI colliders in the scene. You can disable this, however, if you intend on making all in-scene colliders clickable so as to save the hassle of having to assign everything to the GUI layer.
I can’t wait to show you guys what I’ve been working on! Keep an eye on the forums as the release should be ready in the next couple of days.
First of all, everything sounds great.
Here’s one for you…
Click on an object with an attached collider and a script detecting OnMouseDown() [or somesuchthing] and it activates and displays a panel(window).
Is this a simple boolean call, as in OnGUI()?
function OnMouseDown() {
showWindow = true;
}
I assume that you’d need to link… what? a UIManager that controls your code??
var myUIManager : UIManager;
function Start() {
myUIManager = FindObjectOfType (UIManager);
}
function OnMouseDown() {
myUIManager.showWindow = true;
// or
// myUIManager.ShowWindow() where ShowWindow(){showWindow = true;}
}
That sort of thing?
Actually the simplest method available in EZ GUI is to use a UIPanelTab component. If you out one of those on a GameObject, you then just tell it which panel it controls in the inspector (drag and drop) and that is pretty much all there is to it. In code, you can do something like:
void OnMyButtonPress()
{
panel.Reveal();
}
Speaking of which, which we weren’t…
Are there language requirements for EZ GUI?
Do you need much additional scripting, and if so can you use both Unity.js and C#?
Both C# and JS work just fine. And for 90% of uses, hardly any scripting is necessary. You’ll pretty much just write code to respond to button presses, etc. Beyond that, you may write a line or two here and there to show/hide a panel or something. For most use cases I foresee, you won’t have any reason to write more than that.
The only language-related restriction is that for one type of delegate which listens to “raw” input events (which is not going to be necessary except in the most advanced, bare-metal tweaking), I believe you have to use C# because I’m not sure that it is possible to define a method in JS which passes a value type by reference. But then again, it may be possible as I’m not that well versed in Unity’s JS. If someone who knows Unity’s brand of JS better than I do knows better, please let me know as I’d love to know the syntax for doing that.
Alright so, it only works with mouse and touch inputs?
Pretty god. 
Actually, it works wish mouse, touchpad, and also a special type called “Ray”. More details on that should be coming very, very soon. EZ GUI also supports basic text input, and so it uses the keyboard on desktop for that, and automatically displays and uses the iPhone keyboard on iPhone.
Sounds good,
Cant wait to see EZ GUI running on our project!
Cheers,
Just thought I would update anyone watching this thread to let you know that EZ GUI has now been released to the public! Here’s the main thread:
Alright,
tanks,
I didn’t want to pollute the announcement thread with more jumped up “pre-sales” questions… but…
I was pushing ahead and working on my inventory system, that uses OnGUI.
To display the loot and inventory windows (and the same goes with the character pane, etc.) I use a variable that contains the current object’s icon to display what that icon would be. Most of the examples I see from EZ GUI have one or several predefined buttons or button animations.
Can you feed your button a new icon on the fly using code?
Below are examples of my loot and inventory windows. How would I do this with EZ GUI?
http://theantranch.com/Unity/Entries/2010/5/17_Basic_Inventory_%26_Looting_System.html
function DrawLootWindow () { // The window function to draw the loot window
if (GUI.Button (Rect (5,5,10,10), "")) {
CloseLootWindow ();
}
var startY : int = 20;
for (var i : int = 0; i < lootArray.length; i ++) {
if (lootArray[i] != null) {
if (GUI.Button (new Rect (10, startY, 130, 30), GUIContent (" " + lootArray[i].itemName, lootArray[i].itemIcon))) {
var success : boolean = AddItem(lootArray[i]);
if (success)
lootArray[i] = null;
currentLootableObject.UpdateLootArray(lootArray); // Updates the LootableObject "live". Makes this line in OpenLootWindow redundant.
}
startY = startY + 35;
}
}
}
function DrawInventoryWindow () {
if (GUI.Button (Rect (5,5,10,10), "")) {
CloseInventoryWindow ();
}
// GUI.DrawTexture (new Rect (0, 17, 180, 195), warriorBG); // Testing
var j : int;
var k : int;
var currentInventoryItem : InventoryItem; // Establish a variable to hold our data
var currentRect : Rect;
for (var i : int = 0; i < inventory.length; i ++) { // Go through each row ...
j = i / inventoryWidth; // ... divide by array by width to get rows...
k = i % inventoryWidth; // ... find the remainder by width to get columns...
currentInventoryItem = inventory[i]; // ... set this point in the matrix as our current point ...
currentRect = (new Rect (offSet.x + k * (iconWidthHeight + spacing), offSet.y + j * (iconWidthHeight + spacing), iconWidthHeight, iconWidthHeight));
if (currentInventoryItem == null) { // ... if there is no item in the j-th row and the k-th column, draw a blank texture
GUI.DrawTexture (currentRect, emptySlotIcon);
} else {
GUI.DrawTexture (currentRect, currentInventoryItem.itemIcon);
}
// If there is an item at this location and there is a button click...
if (currentInventoryItem != null GUI.Button (currentRect, "", GUIStyle ("label"))) {
if (Input.GetMouseButtonUp (0)) { // ... if that click is mouse button 0: equip it.
// Equip it
openLootWindow = false;
openCharacterWindow = true;
var success : boolean = EquipItem (currentInventoryItem);
if (success)
inventory[i] = null;
}
}
}
}
The core of it can be summed up with:
GUI.DrawTexture (currentRect, currentInventoryItem.itemIcon)
I suppose there are a couple of ways you would handle a situation like that. One could simply be to have difference versions of the button and show/hide the proper one. Without getting into the technical details, it would probably be possible to change a button in the way you describe at runtime, but I’ll need to make it easier to do so. Is there a reason it would be preferable to do this than to show/hide the appropriate button?
It’s a volume issue.
Sorry for all these questions, but I’m realizing how integrated the system I am working on is and how dependent it is on the display method.
For a GUI, I could have dozens if not hundreds of items, theoretically each with it’s own icon. Approaching this with an “OnGUI()” focus means I can have the icon image for an item as part of it’s class (eg: Class Item{var itemName:String; var itemIcon:Texture2D; etc…} and then with the method above, display the appropriate icon for the current item just by looking at the item’s values.
The drawback to this all the unbatched drawcalls. Up to 25 icons in the inventory and up to 12 icons equipped…
In SpriteUI (and this is me thinking on the fly), I’d have to have all the buttons on the same atlas. I’d have to define each and every one’s bounding box using code. And I’d have to have a complex form of comparisons that looked at the item and it’s position in the inventory to display the appropriate icon and then adjust it’s position to match the new position.
I did notice on my first game with SpriteUI that after getting to a certain critical number of button and graphic definitions (and I had several multilayer indicators) that on the iPhone it took measurable seconds to get thru the SpriteUI load phase… and in the end I went for SpriteUI while the game was playing and OnGUI for all of the full screen menus - enabling and disabling the objects with the OnGUI scripts to keep them from firing at all, empty or not, while the game was playing.
All this being said, I see that you have the full meal deal up for the 3 EZ plugins, so I should have a go at them.
I also must apologize, I’ve been up all night and just took a short nap, as I’ve got too many competing projects going on right now.
Is the ray functionality supported on the iPhone? Can you have menus rendered inside the 3D world? That isn’t using render to texture, is it?
What I would recommend using EZ GUI is instead of using that code to decide which texture to display, use the same code to decide which button object to display. The only difference would be that you’d set the button’s position there as well (just assign to its transform’s localPosition property). The atlases are generated, so no work to do there, and it’s no additional work on your end if they should need to use more than one atlas as long as you have a list of references to the buttons you plan to use. And the colliders are auto-generated by EZ GUI, so as long as a flat collider will work in your case, then no need to do anything there either.
Yes, you can use a ray pointer type on iPhone. The only difference is since you don’t have hardware inputs, instead of using the “action axis” to tell it which Unity input axis to use for the action button, you use either code to trigger the “active” state (akin to hitting an “action” button, or clicking the mouse), or use a UIActionBtn component, which is a special on-screen button type that serves as your “action” button to fire the ray.
And no, nothing in EZ GUI requires render-to-texture. I did use a render texture in the space ship scene when you see the security cameras in the two hangars. But that’s all. The computer console itself was done just using EZ GUI controls. They are able to sit in the same plane without “z-fighting” because I marked them as managed and just set their draw layer to control ordering. It works really well to create in-game screens and such.
UPDATE/correction: The next EZ GUI release (coming in a day or so) will allow a fully-customizable layer mask selection for telling it which objects to cast rays against. It defaults to “Everything” so you’ll need to be sure to set it to just the layers you want tested by the GUI raycast.
What I’m worried about, as I’m thinking thru this, not working thru this… Is that I will need to have multiple instances of the same texture - and I won’t know how many.
When displaying itmes in the inventory, if one had 5 of the same type of item, one would see five item icons using the same texture.
(Just me thinking out loud…)
Where OnGUI is useful, is, within a class, I can define a texture associated with an item.
Class Item {
var itamName : String;
var itemIcon : Texture2D;
var etc : Etc;
}
So I can display: GUI.xxx (Rect, itemIcon); [as it were…]
… and have multiple objects that are the same Item type and use the same icon.
A sprite is both a texture sample from the atlas (atlas, x, y, height, witdh) and a location and scale on the screen…
Can you display the same sprite multiple times? Can you create or duplicate sprites on the fly? (var mySpite : Sprite = new Sprite (Rect, Image); var newSprite = new Sprite (mySprite); Or something??) If so, what would this do to performance?
If I were to use SpriteUI, I would polly have to create a new sprite for each new instance of an item in the inventory:
newSprite = DefaultSpriteUI.AddElement( new Vector2( 198, 220 ), 84, 84, 2, 252, 128, 84, 84);
Then then I’d prolly need to delete it afterwards…
Not very efficient.
Can you change where the sprite is looking at the atlas?!?
Could I define my inventory window of say (arbitrarily) 25 slots which contain 25 sprites, each pointing at first to the empty slot icon on the atlas (let’s say at Rect(0,0,50,50)) and attach a rect value to the item class (item. iconRect (150, 200, 50, 50)), and then have a function that sets the image by saying “If item is placed in slot n, set the image of sprite n to item.iconRect. If item is removed from slot n, set the image of sprite n to empty.iconRect.” Effectively repointing the image on the atlas to a new position and therefore a new image without actually creating and destroying the sprite?? (Would that make any difference to performance? It is the same GameObject and Collider and all that…)
I’ll need to start digging further into EZ GUI, as all I’ve done so far is recreate a static button bar! Works fine, now that I’m getting the hang of it!
(Like I said: Just me thinking out loud…)
No need for additional instances of textures. It’s all UVs pointing to a single atlas, so it would just be a second button instance that points to the same place on the atlas.
Currently, you can display identical controls as many times as you want and the only apreciable performance impact is just the additional fillrate of drawing the pixels. So you could use a pool of buttons and just show/hide or enable/disable the ones you want to use. In the next release you should be able to also do something like:
button1.Copy(button2);
This will duplicate button2’s settings in detail. So yes, when the next release is out (pretty soon) you’ll be able to have a pool of “generic” buttons and just copy the one that is the “template” for how that button should look and behave as needed.
Yes, and that is what the Copy() will do.