Unity3D界面插件EZGUI和NGUI的比较

来源:互联网 发布:linux cp 多个文件 编辑:程序博客网 时间:2024/06/01 10:21

http://blog.heyworks.com/choosing-gui-framework-for-your-unity3d-project-ezgui-vs-ngui-part-i/

The following post might be helpful for those standing on the crossroad which GUI framework to go with in Unity project. Among lots of more or less advanced 3rd party options there are just two which can be seriously considered: EZGUI and NGUI. I’ll clarify major differences I’ve noticed in my experience working with both of them.

EZGUI and NGUI provide great features for making in-game UI easily and efficiently. However they use different implementation approaches. EZGUI comprises lots of instruments and controls with plenty amount of settings, so you can tweak almost every parameter of any UI element. In opposite, NGUI provides lots of small components and I like its minimalism, short, clean and understandable code. Both EZGUI and NGUI target “1 draw call for UI” and they’ve got very close. Of course “one-draw call for UI” isn’t the main concern, but why not to have such a great addition to your well-structured and optimized code.

The following table contains a comparison of both frameworks with features I find important:

 

Pixel perfect

Scale of controls is adjusted automatically once on a scene start. Note: it has issues losing render camera reference when instancing UI as a prefab

Scale of controls is adjusted automatically every time resolution changes. Also has ability to applyhalf-pixel-offset

WYSIWYG

Generates ordinary gameobject with geometry, so everything is visualized by Unity itself

Uses several ways of visualization: “geometry” and “gizmos”, since all UI elements are a part of a single mesh

Access from code

Methods from a specific controller-script are linked with control events.

There can be some issues with instancing objects and losing references. Another way –using delegates can be more convenient in some cases

Similar as EZGUI, but here you have helper components, such as UIButtonMessage, which send specified message to a gameobject (or to itself, if target is null), on selected type of interaction. Also you can access to last used control through static variables such as UICamera.lastHit or UICheckbox.current

Ease of controls creation

Empty GameObject is created and attached with necessary components

Provides handy wizards for creating all kind of controls.

Workflow speed

Smooth, but slow. Searching scripts which aren’t included in common menus, adjusting tons of settings, fixing broken atlases and lost camera references (most likely I’m not the only one who experienced these issues)

Supersonic! Just a little slowdown when creating atlases for sprites in the beginning, and then pure enjoyment of future process!

Drag and Drop

Both frameworks have this feature. Just a little note: any object in NGUI with a collider can be draggable

Atlases creation

Atlas has to be recreated every time you want to add/change an image in it. EZGUI can scan all objects, even in a project folder, find all  using the same material and then regenerate the atlas. This process takes lots of time and you should be very accurate not to break something

Atlas can be managed in two ways: either using fast and handy Atlas Maker to add, delete or modify images in atlas or managing sprites in atlas already created via Atlas prefab inspector

Panels switching

Making menus with switching panels has never been easier due

EZGUI’s powerful abilities

Panels can be switched easily as well, but some additional scripting is required. Panels can be switched through animations and helper components, but I haven’t found any direct way to enable one and disable another panel

Additional stuff

Since EZGUI is based on Sprite Manager, classes (e.g. Sprite etc.) can be quite useful in 2D games for environment creation, backgrounds etc.

Sprites can be used, however with some restrictions like any control must have a parent like panel or UIRoot.

And here is a comparison by controls implemented in the frameworks.

Control

Label

Sprite

Sliced sprite

Tiled sprite

Filled sprite

Simple button

Image button

Toggle button

Radio button

Checkbox

Progress bar

Slider

Input

DropDown list

Scrollable lists

I was really excited with Sliced Sprite from NGUI. When there is an objective to create a resizable window that should be pixel-perfect in different sizes, have a frame outside of it and be filled with a pattern - that’s exactly when Sliced Sprite can manage everything, just specify areas on texture to be used as a frame, corners and filling.

Tiled Sprite can be implemented manually with EZGUI, however it won’t be so easy. Tiled sprite always stays pixel-perfect, and it tiles the texture you’re using when scaling. That’s very handy for creating backgrounds for example.

NGUI extends Unity with a bunch of useful hotkeys which are really nice-to-have, e.g. Ctrl+Shift+N to add new empty GameObject as a child to selected one, hotkey for toggling gameobject’s activity, handy buttons for resetting transform’s position, rotation and scale.

Both frameworks are provided with detailed documentation describing every script, every component, property or method. Additionally, NGUI is shipped with a lot of step-by-step tutorials, video and write-up lessons for beginners.

EZGUI is based on Sprite Manager 2 (developed by Above and Beyond Software). SM2 provides features for creating 3D mesh sprites, customizing and changing their parameters in runtime, as well as creating texture atlases, so that all sprites in a scene are a part of single batch and are drawn in one draw call.

And here’s my subjective comparison of these both frameworks:


Usability

Functionality

Flexibility

Reliability

Extensibility

…that means I like NGUI much more, however I haven’t described another very important difference between NGUI and EZGUI - the way of working with them. I’ll demonstrate it in my next post, stay tuned.


原创粉丝点击