今天抽空研究了一下UGUI的深度,UGUI真是好的不得了。以前用NGUI的时候UI的深度就是一个指定的数值,数值越大越靠前,尤其在布复杂界面的时候,深度值不知道怎么填非常恶心。现在有了UGUI这问题即可迎刃而解呀~~如下图所示,B图片在A图片前面,在看看Hieraychy视图,因为A在B的上面,所以优先渲染A,然后是B。那么B就在A的上面了。。
那么我现在想让A图在B图的上面,那么直接在Hierarchy视图里把B拖拽放在A上面即可。
如果GameObject下面有多个精灵,那么原理是一样的, 优先看父节点在Hierarchys视图中的排序,决定父节点的渲染先后。然后在依次看子节点中的Hierarchy视图的排序。如果还有孙节点一次类推。。这样的话如果没有ABA叠层的情况那么图集永远是一个drawcall.所以在布界面的时候就要花点心思这样drawcall就能节省很多了呢。
如下图所示,在深入一下渲染绘制的顺序
UIMain 和 UINext 是同级目录,因为UINext 在UIMain下面 所以优先渲染UIMain这样UINext将在屏幕最前面。UISub原理一样,由此可得出。
精灵显示从前面的 到后面的排序 NextB > NextA >SubB>SubA>MainA>MainB 。。
布界面的时候我们可以按照这个排序来让我们的drawCall 最小化。可是如果我想运行的时候在两个图之间插一个图该怎么办?脚本如下所示。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
using UnityEngine; using System.Collections; public class UIMain : MonoBehaviour { void Start () { GameObject button = GameObject.Instantiate(Resources.Load<GameObject>("button"))as GameObject; button.transform.parent = transform; button.transform.localPosition = Vector3.zero; button.transform.localScale = Vector3.one; GameObject AObj = transform.Find("A").gameObject; GameObject BObj = transform.Find("B").gameObject; button.transform.SetSiblingIndex(AObj.transform.GetSiblingIndex()); } } |
transform.SetSiblingIndex 和 GetSiblingIndex就是设置与获取 GameObject在兄弟节点的位置。。
- 本文固定链接: https://www.xuanyusong.com/archives/3293
- 转载请注明: 雨松MOMO 于 雨松MOMO程序研究院 发表
捐 赠写博客不易,如果您想请我喝一杯星巴克的话?就进来看吧!
UGUI的Hieraychy排序简直不能更糟,或许出发点是想做简化,但是实际运用中,这种僵硬的做法只带给人无尽的痛苦
UGUI的制作思路简直反人类,没见过这么脑残的,为什么我需要关心各种在面板上的顺序?为什么我需要关系制作混合界面时的各种层级结构?为什么我不能完全通过一个节点来开关某个模块(弱智一样的Hieraychy排序导致着些都变成可笑的代码控制),至少在我的项目NGUI框架里,这些东西根本不需要关心
NGUI最完美个管理方案是每个界面独立一个Camera,通过一个Define脚本定义界面的CameraDepth(同步设置该界面的MainPanelDepth),这样你就会发现在制作过程中你再也不需要关心任何所谓层级问题,开关一个界面变得和开关一个GameObject一样简单,也不用像以前一样弱智的用代码不断刷新遍历更改各个界面的Depth,也别跟我说DC问题,平均一个界面20个DC在现在400元的手机都能跑满100DC满帧60帧
最后场景上哪怕有10个空Camera几乎都不会有0.01ms的开销,比大部分程序动不动就几K的GC泄漏性能优秀太多,平时保证0GC的代码要求这是最基本的
不如NGUI好用。不同的Canvas设置非常恶心。
同意楼上。NGUI一个deapth控制渲染顺序非常科学,GPU编程的深度也就用一个值。实际我公司大型项目也就一个类就解决了所谓层级顺序。反观UGUI。呵呵。不同camera是一种设置。相同camera是另一种设置。确实很二。是一种明显的退步。
雨凇大大,想请教一下如何用UGUI 制作3D HUD?
xuliang?
晕,怎么发了两遍,请无视这一条……
文字a,图片b,如果排列方式是abababab那么就是8个drawcall如果游戏中制作列表,动态地添加小物件A,A包含图片和文字,那显然会产生这种排列,那drawcall不是很呵呵了?这个问题该怎么解决?
而且制作的时候,如果界面内容太多,就会分类进行制作,比如A区域,B区域,一个区域一个功能,但这样又会产生混排的问题,哪怕界面就一个图集和一个字体,但实际上的drawCall远不止2个(现在21个了,还没加入列表,加了列表目测上40……),如果为了降低DC而更改UI结构,逻辑上又不好控。我都想把NGUI那套挪过来了……或者用程序重排预制,所有代码控制的界面元素交由一个界面元素数据集控制,但,好麻烦啊……
我要是重排预制,如果要控制某个区域的整体显隐和移动旋转什么的,啊,某区域每个元素都得遍历一遍显隐移动旋转,而且因为原来层级被干掉了,所以现在移动旋转只能换算为世界坐标进行……难道我对transform的控制代码还得改写为对transform所有子孙的操作……这个思路简直让人绝望啊
遇到楼上一样的问题 ,混排需要让代码去控制prefab的排列
遇到更诡异的问题了,UGUI层级问题,明明A图片在B图片上面,但就是会被B图片遮蔽。有时候游戏中干了什么操作,比如点击了某个按钮隐藏了部分UI或者干脆是点击了3D部分的内容,UI上某些图片闪烁(其实是他被他下面的图片的挡住了,再点一下又没挡住,简直诡异)我突然灰常怀念NGUI的Depth……虽然设置麻烦,但DC可控,而且没有UGUI这个诡异的bug……
我也遇到类似的情况,你们后来怎么解决的?
为什么SubA在上面但 SubB > SubA? 是写错了吗?
MOMO大神,如果我想要用代码来控制UGUI里面两个Button的深度,该如何实现啊?
MOMO ,关于UGUI 中 image的 material ,默认是没有材质的吗? 没有材质怎么会画到场景里? 我发现对象里是没有材质的。 并且我也找不到设置 image对应的atlas 所使用的material,这样我就无法更改 换shader。。
肯定有默认材质。。通过image可以直接改material
为什么看了你的另外一篇说是要把控件挂到UI的相机下的文章后感觉层级好乱,现在这样多好啊,昨天群里有人给了这样一个图,我还不理解
可以不挂在下面。。
请问怎么在Unity2D项目里面把Spine制作的骨骼动画对象显示在Unity4.6的原生UGUI上面?
设置canvas的渲染模式为摄像机模式,然后调节动画的位置放在UI前面
老大,请问下,在ugui里如何去显示一个npc的头部提示信息。旧版以前可以用Texture感觉很方便
新版也有image啊。。你说的头部信息?是类似人物头顶血条的那种吗?
差不多吧,像这个样子。先谢过大大了。
图片链接:http://pan.baidu.com/s/1c0vnrIK
http://www.xuanyusong.com/archives/2644 这一篇。。 用这个算法就可以了。
嗯,谢谢大大。我研究下:)
可以看看canvas的世界坐标模式,应该可以满足
布界面的时候我们可以按照这个排序来让我们的drawCall 最小化?这话有点不是很明白我们项目现在采用是UGUI,DrawCall 占用10多个,不是满意的据情况要减少DrawCall,可以控制渲染循序?咋么控制的
手游的话,80drawcall以内就可以了。。。
请问下ugui里面事件怎么吞噬,比如两个按钮重在一起,点击时,让两个都执行click事件?还有不规则图形的点击,移动等,我当前是用的collider 2d添加上去做的检测,有没有更方便的办法来处理不规则图形的事件?
这个需求比较特殊, 得自己去写了。。。
界面结构虽然看起来是简单了,但是一般的都是美术同学来做,然后我们通过fastGUI等工具导成我们需要的界面,总角色这样做界面不是给美术太大的限制就是我们不好重写工具了。
fastgui 这个思路很好啊。之前我没用主要是有一个原因。 就是两个图集公用的图片是如何处理的? 这个你们有解决吗?
这就是传统2D的思路哇 :) 挺方便的~
试试吧。。
必须的 :)
必须的,另外更关注的是UGUI的执行效率方面。NGUI的UIPanel.LateUpdate实在是太难受了
UGUI已经开源了 现在一堆老外大大在研究这个。。。
ABA叠层是指AB使用的不是一个图集?
嗯的。
有点另类啊,其实还是觉得用Z轴调整渲染顺序最好,但是会有蛋疼的图集遮盖问题,如果能自己优化掉就好了
UGUI会自动择优批次。。。
我反而觉得这样不好,比如说制作者会按功能划分子节点。这样Hierarchys反馈为层次就不好了。特别是涉及批次合并的时候(不知道UGUI有没有这个概念)。NGUI的深度直接看是有点烦,但自己做个工具就好多了。
据我现在的理解, UGUI的理念就是让开发者不要care 图集 和 drawcall 。它的图集都是不直接给开发者使用的, 也不能运行时读取图集。他的意思就是开发的时候就用散图。打包后它会自己择优合并批次。。
那还可以,说得过去
可以试试,我觉得以后肯定UGUI会干掉NGUI 最近我也在做调研工作。 希望下个项目 直接用UGUI来做。。
嗯,毕竟是官方的,下个项目看看,还有看看它会不会搞点编辑工具。
不能按功能划分很不方便,如果一个面板有不同层次的元件,就不能用同一个父物体统一移动了。不知道官方为什么不用z轴。
可以的,你把含有某个功能模块的根放到指定的Hierarchys上不就得了
打包后自动合并应该不行呀,对于那些运行时动态加载的图片怎么打包呢?还是不打包?
动态加载的也是图集上的啊。。