unity粒子系统粒子范围_粒子系统模块–常见问题

Unity 5.3以后,可以完全通过脚本访问粒子系统的模块,但这种方式可能造成混淆。本文解答相关疑问,揭示幕后原理,并讨论未来改进。粒子系统模块存储在C++端,设置属性时直接修改,无需重新分配。MinMaxCurve类驱动许多模块属性,包括常量、曲线等模式。虽然目前无法直接从脚本读取曲线,但未来将改进这一限制。此外,正考虑将模块从结构体改为类,以便更清晰地理解模块归属,并优化值的设置与获取。
摘要由CSDN通过智能技术生成

unity粒子系统粒子范围

Starting with Unity 5.3, you have full scripting access to the particle system’s modules. We noticed these new scripting features can be a bit confusing. Why do we use structs in an unconventional manner?

从Unity 5.3开始,您可以对粒子系统的模块进行完全脚本访问。 我们注意到这些新的脚本功能可能会有些混乱。 为什么我们以非常规的方式使用结构?

In this blog post, we will answer some of your questions, take a little peek behind the scenes and explain some of our plans to make the process more intuitive in the future.

在此博客文章中,我们将回答您的一些问题,在后台进行一些窥视,并解释一些使将来的过程更加直观的计划。

访问模块 (Accessing Modules)

一个例子 (An example)

Here is a typical example in which we modify the rate property from the Emission module.

这是一个典型示例,其中我们从“排放”模块修改了rate属性。

1

2
3
4
5
6
7
8
9
10
11
12
13
14
15
using UnityEngine;
public class AccessingAParticleSystemModule : MonoBehaviour
{
// Use this for initialization
void Start ()
{
// Get the emission module.
var forceModule = GetComponent<ParticleSystem>().forceOverLifetime;
// Enable it and set a value
forceModule.enabled = true;
forceModule.x = new ParticleSystem.MinMaxCurve(15.0f);
}
}

1

2
3
4
5
6
7
8
9
10
11
12
13
14
15
using UnityEngine ;
public class AccessingAParticleSystemModule : MonoBehaviour
{
// Use this for initialization
void Start ( )
{
// Get the emission module.
var forceModule = GetComponent < ParticleSystem > ( ) . forceOverLifetime ;
// Enable it and set a value
forceModule . enabled = true ;
forceModule . x = new ParticleSystem . MinMaxCurve ( 15.0f ) ;
}
}

To anyone familiar with .NET, you may notice that we grab the struct and set its value, but never assign it back to the particle system. How can the particle system ever know about this change, what kind of magic is this!?

对于熟悉.NET的任何人,您可能会注意到我们抓取了该结构并设置了它的值,但从未将其分配回粒子系统。 粒子系统怎么会知道这种变化,这是什么魔术!

这只是一个界面 (It’s just an interface)

Particle System modules in Unity are entirely contained within the C++ side of the engine. When a call is made to a particle system or one of its modules, it simply calls down to the C++ side. Internally, particle system modules are properties of a particle system. They are not independent and we never swap the owners or share them between systems. So whilst it’s possible in script to grab a module and pass it around in script, that module will always belong to the same system.

Unity中的粒子系统模块完全包含在引擎的C ++端。 当调用粒子系统或其模块之一时,它仅调用C ++端。 在内部,粒子系统模块是粒子系统的属性。 它们不是独立的,我们绝不交换所有者或在系统之间共享它们。 因此,尽管可以在脚本中获取模块并在脚本中传递它,但该模块将始终属于同一系统。

To help clarify this, let’s take a look at the previous example in detail. When the system receives a request for the emission module, the engine creates a new EmissionModule struct and passes the owning particle system as its one and only parameter. We do this because the particle system is required in order to access the modules properties.

为了澄清这一点,让我们详细看一下前面的示例。 当系统收到对发射模块的请求时,引擎将创建一个新的EmissionModule结构,并将拥有的粒子系统作为其唯一参数传递。 我们这样做是因为需要粒子系统才能访问模块属性。

1

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public sealed class ParticleSystem : Component
{
.....
public EmissionModule emission { get { return new EmissionModule(this); } }
....
}
public partial struct EmissionModule
{
private ParticleSystem m_ParticleSystem; // Direct access to the particle system that owns this module.
EmissionModule(ParticleSystem particleSystem)
{
m_ParticleSystem = particleSystem;
}
public MinMaxCurve rate
{
set
{
// In here we call down to the c++ side and perform what amounts to this:
m_ParticleSystem->GetEmissionModule()->SetRate(value);
}
}
......
}

1

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值