koobas.hobune.stream
New particle system structs - how does this work?
I'm trying to tweak my particle systems in script, and I notice the needed "emissionRate" is deprecated in favor of an "emission" property.
ParticleSystem.emission is read-only, and is a struct, so trying to set PSystem.emission.rate = 5 does not work. The typical solution is to copy the struct, change it, and assign it back to the object (like you might do with transform.position or something).
But as this thread's creator realizes, that doesn't work because PSystem.emission is readonly. However, @richardkettlewell suggests not needing to reassign the struct, and that all you need is a temp var.
He says this code should work. And, in fact does:
ParticleSystem.EmissionModule em = particles.emission;
em.rate = new ParticleSystem.MinMaxCurve(5);
But everything I've learned in 10 years of C# coding says that this shouldn't work. My new "em" variable should be a copy of emission, and modifying it should not be able to affect the source struct. In fact this is why the line "PSystem.emission.rate = 5" gives a compile error, because it knows this won't work.
But somehow, it does work. Anyone know how? Afaik it seems impossible.
The particle modules are just interfaces to the particle system. They are not independent objects. Internally they contain a reference to the particle system and calling get/set calls down into the c++ code. We do this to avoid GC but still keep params in per module groups.
The documentation says emission is a struct. Is that not the case?
edit: rather, it says Emission$$anonymous$$odel is a struct, but the question remains.
So this is kind of how it works:
struct Particle$$anonymous$$odule
{
private ParticleSystem ps; // access to the C++ particle system
int someValue
{
get
{
return ps.GetSomeValue();
}
set
{
ps.SetSomeValue(value);
}
}
}
So the struct is only an interface which is why you dont need to reassign it however you can keep the struct and continue to use it. No need to keep getting it.
That makes sense. The only other question to me, then, would be why structs ins$$anonymous$$d of classes? If they were classes, we could use the more direct system.module.property = value.
The "avoid GC" claim, also made in the thread I linked, doesn't make sense to me. You're only creating this data once per particle system, no? Since we can't assign the module objects directly, there's no risk of creating any more garbage than we allocated on object creation.
I'm sure, just like the original question, I'm missing something here, but it seems like an empty class makes as much sense as an empty struct?
I agree classes would be a more logical approach. We will discuss it some more internally.
Update: We use classes ins$$anonymous$$d of structs because there would be managed allocations when accessed if they were classes.
I think by gc we mean we need to copy the data from cpp into the struct however this way we don't need to. AFAI$$anonymous$$
