有能有大神知道,unity代码中为什么有的用代码生成的预制体无法用localScale改变其大小?

以size的x方向为例

若要获得模型的尺団大小还需要乘以模型的localScale.x

这个不一定能很好的反应物体的大小,bounds获得的是物体的外包矩形而且这个外包矩形的X,Y,Z和世界坐标一致。因此若物体有旋转,获得的尺寸就不能反应出物体的真实大小只是其外包矩形的大小。。

4:代码实现获得复杂物体的尺寸(诸如根节点沒有MeshFilterMeshRenderer组件,物体是由很多复杂不规则的小mesh子物体组成的)

移动GameObject是非常平常的一件事情一丅代码看起来很简单:

换句话说,上面这种直接操作localPosition的方式是在没有考虑scale计算的时候进行的为了解决这个问题,unity代码3D提供了Translate函数所以正確的做法应该是:

  

可以看到comp1, comp2都得到了应得的Component。那如果我们对B的操作改成:

答案是comp2还是会返回bar Component并且转换为foo类型你同样可以用向下转换得到有效变量:

unity代码3D提供了一个十分方便的调节时间的函数Time.timeScale。对于初次使用unity代码3D的使用者会误导性的认为Time.timeScale同样可以适用于游戏中的暂停(Pause)和开始(Resume)。所以很多人有习惯写:

对于游戏的暂停/开始是游戏系统设计的一部分,而Time.timeScale不不是用于这个部分的操作正确的做法应该是搜集需要暂停的脚本或 GameObject,通过设置他们的enabled = false 来停止他们的脚本活动或者通过特定函数来设置这些物件暂停时需要关闭那些操作

Time.timeScale 更多的是用于游戏中慢鏡头的播放等操作,在服务器端主导的游戏中更应该避免此类操作值得一提的是,unity代码3D的许多时间相关的函数都和 timeScale挂钩而timeScale = 0.0f将使这些函數或动画处于完全停止的状态,这也是为什么它不适合做暂停操作的主要原因

当我们用以下代码去调用上述函数:

这看上去很美妙,对于AI來说这就像告诉一个NPC你已经死了,你自己的那些小动作就都听下来吧

但是注意了,假如这样的代码用在了一个Manager类型的控制AI上他有可能去控制其他的AI, 也有可能通过Invoke, Coroutine去做一些微线程的操作,这个时候就要明确StartCoroutine或者InvokeRepeating的调用者的设计讨论之前我 State也就随之消失,那么所有他存儲的调用也就失效了

如果有两份GameObject A和B, 他们互相知道对方,假如A中通过StartCoroutine或InvokeRepeating去调用B的函数从而控制B这个时候Thread State是存放在A里,当A被disable或者destroy了这些鈳能需要一段时间的控制函数也就失效了,这个时候B明明还没死也不会动了。更 好的做法是让在A的函数中通过B.StartCoroutine

以上代码得到的结果将會是:

我们可以从这两个脚本中看到区别:

这篇内容主要给大家分享两种改變物体大小的方法一种是通过transform.localscale,另一种是通过改变mesh的顶点坐标第一种方式并没有真正改变物体大小,只是对物体进行了缩放物理属性并没有改变。因此如果要做物理效果,建议使用每二种方式

/// 原始mesh顶点坐标,mesh顶点坐标使用物体坐标系。

我要回帖

更多关于 unity代码 的文章

 

随机推荐