关于界面高度height的计算

首先看一个例子,新建一个Panel,在下面添加两个Button,分别命名为Button、Button2。

1、给Panel添加一个VerticalLayoutGroup组件,ChildForceExpand属性中勾上Width。

2、给Button、Button2添加LayoutElement组件,其中Button的FlexibleHeight设置为0.3,Button2的FlexibleHeight设置为0.1

3、将Panel的高度设置为100

这时我们发现,Button的高度是70,Button2的高度是30。奇怪,这个高度是怎么算出来的呢?

网上搜索一番,竟然很少有人讨论uGUI的AutoLayout,尤其是flexibleWidth/Height属性的意义,官方文档也语焉不详。这时只能放大招了,uGUI已经开源,索性把代码拉下来看看到底怎么实现的。下面是托管代码的地址:

https://bitbucket.org/Unity-Technologies/ui

uGUI的AutoLayout有三个核心接口,定义在ILayoutElement.cs文件中:

ILayoutElement

ILayoutController

ILayoutIgnorer

结构很清晰,由ILayoutElement提供布局信息,ILayoutController来控制布局,ILayoutIgnore提供给UI忽略AutoLayout的能力。

例子中使用的VerticalLayoutGroup继承自HorizontalOrVerticalLayoutGroup,这个类实现了布局的核心逻辑,代码量不多,我就直接贴上来了

其中SetChildrenAlongAxis方法清晰地阐释了minHeight,preferredHeight,flexibleHeight的涵义。

为了帮助理解,我们先定义几个概念。我们把当前UI所有同级并参与自动布局的组件的preferredHeight总和称为totalPreferredHeight,minHeight的总和称为totalMinHeight,父UI的真实高度称为realHeight。总结如下:

1、 minHeight

在自动布局中,此UI最小高度不会小于minHeight。这个参数定义了realHeight < totalMinHeight时,当前子UI的height为minHeight。

2、 preferredHeight

可以理解为,UI自身希望的高度。

当totalMinHeight < realHeight < totalPreferredHeight时,realHeight处于totalMinHeight和totalPreferredHeight之间一定百分比,把这个比例应用到每一个接受自动布局的子UI上,即是我们最终得到的效果

3、 flexibleHeight

当realHeight >
totalPreferredHeight时,父UI会剩下一部分高度。flexibleHeight就是告诉AutoLayout系统,应该怎么瓜分剩下的高度,使子UI填充满父UI。flexibleHeight默认是-1,不会进行扩充。当flexibleHeight

0时,flexibleHeight值作为权重来计算当前子UI最终的高度,公式如下:

height = preferredHeight + (flexibleHeight / totalFlexibleHeight) * (realHeight - totalPreferredHeight)

flexibleHeight示意图

弄清楚这些概念后,我们再看一下文章开头的例子。

button1的flexibleHeight=0.3,button2的flexibleHeight=0.1,minHeight和preferredHeight都没有设置,按道理高度应该分别是75、25。为什么会出现70、30?

查一下ILayoutElement的实现类

ILayoutElement实现类

发现Image和Text实现了ILayoutElement,而我们的按钮中默认是有一个Image组件的,用脚本获取这个Image然后打印它的preferredHeight,发现等于10

再套用flexibleHeight的计算公式:

这里有个问题,一个GameObject上挂载两个ILayoutElement组件,是怎么决定用哪个的?这个可以在LayoutUtility.cs中找到答案:

原来LayoutElement有一个layoutPriority属性用来决定优先级,这个属性暂时还没有在编辑器中暴露,也许后续版本会加强这方面的能力。

AutoLayout系统会选用优先级最高的ILayoutElement里相应属性返回。Image和Text的优先级默认是0,LayoutElement默认优先级是1。所以正常情况会使用LayoutElement中的设置,但我们的例子中,LayoutElement没有设置preferredHeight,LayoutElement里布局相关的初始值都是-1,所以还是使用了Image的preferredHeight:10。

【结语】

其实,只要官方文档描述详细一些,根本没必要浪费时间去查这个来龙去脉。这几天在学习Swift,苹果人性化的Programming
Guide加上iBooks的配合,使得学习这门语言真是件轻松愉快的事情。相比之下,Unity简直是在虐待开发者。Unity、Unreal、Cryengine等最近也为争市场弄得头破血流,除了降价开源提供新特性之外,完善文档也是不容忽视的工作,毕竟开发者才是这些厂商真正的衣食父母。

VR环境下的语音识别

语音识别对于VR领域格外重要,因为它不仅能模拟AI与用户对话,还为用户提供了与任意应用进行沟通的更多选择。
手动输入指令可能不太现实,并且应用如果拥有太多按钮或其它GUI元素,也会很快让用户手足无措。但只要能语音控制,那么在VR环境中就很容易开口去进行各种操作。

Unity
Labs
的虚拟现实(VR)授权平台Carte
Blanche将发布一个名为U的个人助理系统,用户可以通过语音控制它,很便利地执行一些操作。Unity
Labs研发团队
一直在研究可以实现这种声控命令的语音识别与分析工具。

观看下面的视频了解Carte Blanche中的个人助理系统U:

本文第一部分将介绍语音识别的概念和理论。它将简单介绍其相关概念和参考,以帮助读者了解更多关于语音识别方面的信息。第二部分将简单介绍在Unity Asset
Store的安装包以及公开的代码库,我们封装了几个语音转文本的解决方案,还有一些用于对比各API的文本翻译的示例场景。

如果想详细了解语音识别的概念和理论以及更多相关的研究,请进入Unity官方中文社区。下面简单为大家介绍语音识别与语义分析的原理,以及Unity
Labs
为大家提供的语音识别插件。

语音识别与语义分析的原理

语音识别,顾名思义就是通过程序将语音转换成文本 。而 语义分析是其下一步,即将转换出来的文本进一步分析
,并确定文本想要表达的意思。即使是目前最好的语音识别和语义分析程序也远称不上完美。虽然人们能直截了当并毫不费力地处理这样的任务,但是当我们试图让程序去执行这两个步骤时,困难程度真的是难以想象。

目前基于统计学的语音识别最重要的部分就是声学建模(Acoustic
Modeling)。这个过程中用于识别声音开始时不同的波形,或者是语音结束时的一些音节。对于声学模型而言,通过查看声波输出,并尝试找出最可能输入的音节是什么,
从而分析出说话者究竟想表达什么。

如上图所示,这是声学模型中“x”的发音模型。椭圆表示我们正在尝试识别的音节。它们无法被直接观察到,但它们产生的概率波形(底部)是可以被完整观察到的。因此,波形自身是可以观察的,但必须及时从可观察的状态中分辨出音节。

假设语音已经被成功转换成了文本,现在程序需要分辨该文本究竟是什么“意思”,这时语义分析就可以登场了。人们日常生活中就无时不刻地在进行着语义分析。例如,在阅读这句话之前,你可能已经猜到接下来会是人们如何进行语义分析练习的例子。那是因为你能利用上一句(例如“人们日常生活中就无时不刻地在进行着语义分析”)作为上下文线索,从而很好地预测后续几句。因此,如果想要拥有非常逼真的VR体验,AI必须善于分析玩家的语句并给予正确的反馈。

语音转文本的工具

Labs最初研究的语音识别涉及了对现有语音转文本解决方案的评估。我们开发了整合部分解决方案的Unity C#脚本插件并分享在Unity Asset
Store。里面包含了示例场景,可以依次对比每个API转换的文本内容,同时允许用户从给定的列表中选定短语,并查看说出该短语后程序判定的准确程度。该代码也可以从Unity代码库中获得。

我们提供的插件是对比目前Unity中几大语音转文本解决方案的简便方法,也很容易将其整合至你的项目。如果想在Unity中尝试其他API,使用该插件也非常简单
,只需新建类继承自Speech-To-
Text的Service基类,然后即成到示例场景或小部件即可。除了单独的语音文本转换SDK,插件还包括多个辅助类与函数(记录管理器,音频文件的创建和转换等等),以便集成和比较更多的API。

各大语音文本都各有特色,如果有兴趣,可以查看关于 Windows dictation recognition, Google Cloud Speech,
IBM Watson, 以及Wit.ai
四种语音识别解决方案的具体信息。

总结与未来规划

语音识别很难精准的原因在于有太多的变量需要考虑。对于每一种要识别的语言都需要储存大量的数据,包括所有现存的单词(包括俚语及简写形式),这些单词相互如何结合,语调和口音也可能影响发音,所有人类语言的冗余和矛盾等等更多因素。

发布至Asset Store的自Speech-To-
Text插件目前仅集成了几个语音文本转换解决方案,但这些足以用来比较现有语音识别工具的优缺点了。对Unity开发者而言,该插件只是起点,还可以根据具体需求来加入更多功能。

_ _

SimSensei,一款由南加州(USC)学院创新研究部(ICT)开发出来的模拟治疗程序

这项研究源于Carte
Blanche项目最初集成AI机器人U来响应声控命令的计划。这涉及到语音文本的转换以及关键字识别。另一个有趣却艰难的挑战是创造出能与用户“对话”的机器人。人们在日常对话中经常包含类似于“嗯”或者是“啊”之类的语气词来表达感受。如果VR应用中的AI机器人不仅能够理解关键字,还能理解人类回话的各个部分,那它将让VR环境的沉浸感进入全新的层次。

unity生命周期

继承MonoBehavior的生命周期

主要的生命周期:

Reset : 用户第一次添加组件时或用户点击见组件面板上的Reset按钮时调用

OnAwake:
当脚本实例被载入时Awake被调用,一般可以在这个地方将当前脚本禁用:this.enable=false,如果这样做了,则会直接跳转到OnDisable方法执行一次,然后其它的任何方法,都将不再被执行。如果当前脚本处于可用状态,则正常的执行顺序是继续向下执行OnEnable,当然我们可以在另外一个脚本中实现这个脚本组件的启动:this.enab=true;

OnStart: Start仅在Update函数第一次被调用前调用。

OnUpdate:渲染一帧之前被调用。这里是大部分游戏行为代码被执行的地方,除了物理代码。

LateUpdate:
是在所有Update函数调用后被调用。这可用于调整脚本执行顺序。例如:当物体在Update里移动时,跟随物体的相机可以在LateUpdate里实现。如果后面写了Reset,则会又回到Update

OnGUI: 渲染和处理GUI事件时调用,当然,如果你使用了NGUI,这个生命周期的事情就不用考虑了。

FixedUpdate:
这个函数在每个物理时间步被调用一次。这是处理基于物理游戏行为的地方。常用于移动模型等操作。不受帧率影响,默认0.02s,如果卡帧了Update就不会再执行,而FixedUpdate则继续执行。

Edit->preject setting ->Time -> (Inspector监测视图)Fixed Timestep 设置刷新时间

OnDisable:
当对象变为不可用或非激活状态时此函数被调用。这个时候,脚本并不会被销毁,在这个状态下,可以重新回到OnEnable状态(enable=true)。

OnDestroy: 当MonoBehaviour将被销毁时,这个函数被调用。当前脚本的生命周期结束。

建议一般在Awake中做一些初始化,在Start中获取游戏对象

其他的生命周期:

OnPreCull:在相机剔除场景之前调用此函数。相机可见的对象取决于剔除。OnPreCull 函数调用发生在剔除之前。

OnBecameVisible/OnBecameInvisible:在对象对于相机可见/不可见时调用此函数。

OnWillRenderObject:如果对象可见,则为每个相机调用一次此函数。

OnPreRender:在相机开始渲染场景之前调用此函数。

OnRenderObject:在完成所有常规场景渲染后调用此函数。此时,可使用 GL 类或 Graphics.DrawMeshNow 绘制自定义几何图形。

OnPostRender:在相机完成场景渲染后调用此函数。

OnRenderImage(仅限专业版):在完成场景渲染后调用此函数,以便对屏幕图像进行后处理。

OnGUI:在每帧上多次调用此函数,以响应 GUI 事件。程序首先将处理 Layout 和 Repaint 事件,然后再处理每个输入事件的 Layout 和
keyboard/鼠标事件。

OnDrawGizmos: 用于在场景视图中绘制小图示 (Gizmos),以实现可视化目的。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×