Hello,
I have found that subemitted particles are not handled by the fluid renderer. DEMO
Here, the particles still look like sprites, instead of fluid. I added two lines to the original example. They are highlighted by an all-caps comment.
Welcome aboard!
Sub-emitters work by cloning themselves each time they must respawn, so when a new particle system is created that way, it wonât be added to the fluid renderer.
One way to overcome this problem is to override the start function of the ParticleSystem class and add the particle system to the fluid renderer at that time:
Of course, all particle systems will now be added to the fluid renderer⌠If you want both regular and âfluidifiedâ particle systems with sub-emitters at the same time, I think we would need a way to be notified when a new particle system has been spawned by a sub-emitter. cc @Deltakosh, I donât know if it makes sense to add an observable for that?
[âŚ] This PG is better because it disposes of the fluid object when the corresponding particle system is disposed, but this PR is needed to make it work:
2 Likes
PR merged, will be available tomorrow on the playground
1 Like
Thank you for this incredibly fast reply and PR! To me, this confirms that I made a good choice by replacing three.js with babylon.js. Unfortunately, it seems that the performance for sub-emitters is low (the tab almost freezes) when combined with the fluid renderer:
Here, each particle of the main system is a rain drop. Then, upon death, it emits droplets with the subsystem. I set subParticleSystem.manualEmitCount = 0 to ensure that it is not the actual rendering of the droplets that is slowing down.
When I do not use the fluid renderer, it works fine. I will experiment with manually updating the particles of the main system to use them as droplets, to see if that avoids the performance problem.