Home > Back-end >  Why setting ParticleSystem.main properties works like this?
Why setting ParticleSystem.main properties works like this?

Time:01-08

In Unity manual we are told to set properties like this

ParticleSystem ps = GetComponent<ParticleSystem>();
var main = ps.main;
main.startDelay = 5.0f;

And I cannot understand, why it works, as main and startDelay are value types.

Does this means, that main have complicated setters with links to ParticleSystem object? What are the profits of a such approach?

Now I cannot do ps.main.startDelay = 5.0f;, but essentialy splitting "error" gives me no error.

I recreate naive environment, to check if I understand c# value type correctly. If You have a struct in a class, you cannot change struct properties like this. It has no effects!

CodePudding user response:

Does this means, that main have complicated setters with links to ParticleSystem object?

-> yes exactly!

The MainModule knows the particle system and things are actually happening in the underlying native c layer of the engine.

What are the profits of a such approach?

As the module itself doesn't really do anything but being a link into native code it doesn't really matter whether it is a class or struct except the way reference types vs value types are handled in memory.

They just wanted to cluster certain functionality together into modules to make it easier to work with .. it could as well just be all in the API of the ParticleSystem directly but would then be quite cluttered and hard to understand what belongs together.

It basically all comes down to how the underlying native particles work (which we don't have any information on since the native part of the engine isn't public).

That the

ps.main.startDelay = 5.0f;,

is not allowed on c# level is the downside we have to deal with - but apparently the advantages going this way was greater than that, and basically is the same for almost all Unity API properties - so it is consistent again.

  • Related