• currently all particle components / emitters are updated (simulated) at the start of the frame - which means even particles off-screen are always simulated
• in order for the particle system to use few camera properties (specifically I think only its position for sorting), it depends on a hacky way the forward renderer sets up _activeCamera - note that this works as expected for a single camera only. Ideally we create multiple mesh instances / meshes inside the emitter, to allow their per camera sorting?
• there is this comment related to this in the particle-emitter suggesting that due to not having camera during the first update (before forward renderer sets _activeCamera), and incorrect shader might need to be compiled initially .. this is fixed later when the camera changes. Fixed in Refactor the way shaders get created for particle systems #6804
• the emitter calls material.getShaderVariant() without any parameters, and so we don't have access to camera rendering settings (gamma, tone mapping) - Fixed in Refactor the way shaders get created for particle systems #6804
• When a what is called complex property of the ParticleComponent is changed, it rebuilds entire emitter from scratch. This is not particularly efficient. But what is worse is that if the same property is changed multiple times per frame, the emitter gets rebuilt each time. Ideally the emitter's resources are only destroyed at that point, and lazily recreated inside addTime at the start of the next frame. When the resources are destroyed, that includes mesh instance, and component uses the mesh instance to set few properties on it, and so a simple solution does not work. We could perhaps change the MeshInstance API to allow it to be created without mesh and mesh supplied later. Emitter would then keep the meshInstance permanently, allowing the component to set its properties.

Ideally:

• This should work similarly to skinned/morphed meshes and splats, where forward renderer executes culling first, and the expensive update only takes place for the visible visuals. This should be at least case for the procedural particles where the bounds can be estimated.
• user might need an option for simulate off-screen or disable