Particle System Updates

[Meta-Maxim]

Planning and Discussion for the new Particle System #2728

• Long-range particlesystem registry, "Chimney-problem" - likely longer term topic
• Optimize updater to partition ParticlePool based on emissionRate of emitters, not evenly.
• Create documentation (focused on JavaDoc - see Tutorial module request: Particle System #2999 for a separate tutorial request)
• Finish annotating code
• Create tests
• Any needed performance improvements, like better network handling?
• Improve some of the block breaking particles (can look awkward for some blocks/items like torches)

[Cervator]

Bump - submitted a separate issue #2999 to cover a tutorial module. Declaring the goal here to be for general documentation (so primarily javadoc) and overall improvements still needed. Updated the original post some with a couple more checkboxes. Some discussion on Slack noted the possibility that too many things are going over the network rather than just the emitters?

[Cervator]

Bump - changes are we need to also look at the cleanup process further, it seems likely that there are entity leaks somewhere. One play test just made it past 10 million entities with a variety of particle usage (mostly explosions and maybe locomotive smoke)

[Meta-Maxim]

@Cervator ParticleEmitterComponent.destroyEntityWhenDead = false by default. So when the emitter runs out of particles / stops emitting the entity is left behind. You have to set it to true for the system to remove itself. Those are my first thoughts, I haven't tested anything so it could be something else.

I'll be able to look into all of this more once I get started with GCI, I have midterm exams so I'll be very busy with school for the next week or so.

[Cervator]

Hey @MaxBorsch - I was wondering about your GCI status and such, thanks for the update :-)

Would it make more sense for that boolean to default to true then? But yeah midterms come first!

[Meta-Maxim]

@Cervator I'm not sure which way is better. I went with false because it's the less destructive of the two and users wont get confused when their entity randomly get removed just because its particles ran out. I was imagining that people might attach particles to entities that are used for things other than just the particles, for example a fireball entity that has particles attached but also custom rendering/damage components. In that case you wouldn't want your fireball to get removed by default when its particles ran out. Although I can see why true might be better as particles are infinite by default, so you would need to first set a particle limit hinting that you want the entity to self-destroy.

[Cervator]

Good point on not wanting to entirely destroy an entity if it is really something else just having particles added - but in that case wouldn't it make sense to remove any particle-related components and if that "empties" the entity then destroy it?

[Meta-Maxim]

@Cervator Emitters have something like a destroyComponentWhenDead, it doesn't destroy other related components but that would make a useful and simple addition. Cough GCI task. We can have it true by default...