Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug / Crash  ObiInstancedParticleRenderer renders ghosts of dead particles
#1
Bug 
Very much in the spirit of Halloween here, but ObiInstancedParticleRenderer appears to be haunted as it's rendering ghost particles.

Replication steps:
  • Create a new blank URP project
  • Install Obi Fluid 7.03
  • Change shader target in ProceduralInstanced.shadergraph from BuiltIn to Universal
  • Launch Faucet And Bucket test scene and fix the scene materials
  • Disable the emitter's ObiFluidSurfaceMesher, add ObiParticleRenderer and ObiInstancedParticleRenderer components
  • Set the emitter's lifespan to 1 second and speed to 8, and launch the scene
  • Once the scene is open, you'll see the error. Set the Speed to 0 while the scene is live to get a really clear example of the ghost particles, which will then stay around indefinitely.

Expected Result: The ObiInstancedParticleRenderer particles stop rendering when the particles expire. When the ObiParticleRenderer particle disappears, its corresponding ObiInstancedParticleRenderer should also disappear.

Observed Result: When particles expire at the end of their lifespan, ObiInstancedParticleRenderer continues to render them at their last known position. In Burst backend they are drawn in their final orientation and in Compute backend they are drawn in their final position but with zero rotation. The particles remain there indefinitely or until their index is re-used by a new particle. ObiParticleRenderer and ObiInstancedParticleRenderer render perfectly in sync right up until the particle expires.
Reply
#2
Hi,

Could reproduce this, thanks! Sonrisa

Interestingly enough it only happens when the emitter's blueprint is a fluid blueprint, not when it's a granular blueprint (which is the usual use case for particle instances). Will work on a patch and get back to you asap.

kind regards,
Reply
#3
Hi,

Here's the patch. Replace these 4 files in your Obi installation with the ones attached, it should solve the issue.

Obi/Resources/Compute/InstancedParticleRendering.compute
Obi/Scripts/Common/Backends/Burst/Rendering/Common/BurstInstancedParticleRenderSystem.cs
Obi/Scripts/Common/DataStructures/NativeList/ObiNativeList.cs
Obi/Scripts/Common/Rendering/ObiInstancedParticleRenderSystem.cs

Let me know if I can be of further help,

kind regards


Attached Files
.compute   InstancedParticleRendering.compute (Size: 1.2 KB / Downloads: 1)
.cs   BurstInstancedParticleRenderSystem.cs (Size: 4.1 KB / Downloads: 1)
.cs   ObiNativeList.cs (Size: 23.89 KB / Downloads: 1)
.cs   ObiInstancedParticleRenderSystem.cs (Size: 5.24 KB / Downloads: 1)
Reply
#4
(Yesterday, 02:08 PM)josemendez Wrote: Hi,

Could reproduce this, thanks! Sonrisa

Interestingly enough it only happens when the emitter's blueprint is a fluid blueprint, not when it's a granular blueprint (which is the usual use case for particle instances). Will work on a patch and get back to you asap.

kind regards,
Yep, noticed that too! Thanks so much!

Regarding use case, what I'm doing is having a thick fluid that has little bits embedded in it. A fluid emitter is much easier to control and keep merged with the fluids. I'm also still deciding which of the two ways I want to do it:

  1. The particles are emitted from a separate emitter and mix with the existing fluid. This is the simplest way but doesn't necessarily give an even coverage, the two streams interact, and each type of 'bit' needs its own emitter.
  2. Apply the ObiInstancedParticleRenderer to the original fluid emitter, and then write a shader to vary the 'bits' programmatically. I have a test shader that renders a small percentage of the instances (pseudorandomly based on Instance ID) and varies colour/texture used, size, etc. This method involves no extra particles or simulation and gives an even coverage, but requires a lot of shader work and it's trickier to do multiple 'bits' with different meshes.
I've tested both methods and they both work well and produce better results than using granular blueprints for this use case.
Reply