Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug + fix: IndexInActor not updated in solver after a particle kill
#1
Hi there!

I was doing some kind of fancy particle management when I came across a bug preventing me to delete the last particle of an emitter if another particle from the same emitter has been killed before. (Note: I've been killing it the "proper" way, setting its life to zero)
The bug was due to the fact that the IndexInActor field from the ParticleInActor class in the solver is not updated when a particle is killed by the Emitter. The consequence is that when deleting my 2nd particle, its IndexInActor still "pointed" to the particle I just killed before and was moved to inactive particles group at the end of the list.
I took a quick look and it seems that there's nowhere where IndexInActor is updated, so the fix boils down to doing it in KillParticle:

Code:
       public bool KillParticle(int index){

           if (activeParticleCount == 0 || index >= activeParticleCount) return false;

           // reduce amount of active particles:
           activeParticleCount--;
           active[activeParticleCount] = false;

           // swap solver particle indices:
           int temp = particleIndices[activeParticleCount];
           particleIndices[activeParticleCount] = particleIndices[index];
           particleIndices[index] = temp;
           // FIX BEGIN
           solver.particleToActor[particleIndices[index]].indexInActor = activeParticleCount;
           solver.particleToActor[temp].indexInActor = index;
           // FIX END

I tried it on my scene and if fixes the problem wonderfully!
I guess this was the intent of the existing swap in particleIndices above (cf the comment), but the change is not deep enough in the system for it to work correctly.
Unless the bug was due to me using the system in the wrong way, I guess it would be good to have this extra piece of logic integrated in the next release.

Cheers!
Reply
#2
(28-01-2018, 05:34 AM)tooomg Wrote: Hi there!

I was doing some kind of fancy particle management when I came across a bug preventing me to delete the last particle of an emitter if another particle from the same emitter has been killed before. (Note: I've been killing it the "proper" way, setting its life to zero)
The bug was due to the fact that the IndexInActor field from the ParticleInActor class in the solver is not updated when a particle is killed by the Emitter. The consequence is that when deleting my 2nd particle, its IndexInActor still "pointed" to the particle I just killed before and was moved to inactive particles group at the end of the list.
I took a quick look and it seems that there's nowhere where IndexInActor is updated, so the fix boils down to doing it in KillParticle:

Code:
       public bool KillParticle(int index){

           if (activeParticleCount == 0 || index >= activeParticleCount) return false;

           // reduce amount of active particles:
           activeParticleCount--;
           active[activeParticleCount] = false;

           // swap solver particle indices:
           int temp = particleIndices[activeParticleCount];
           particleIndices[activeParticleCount] = particleIndices[index];
           particleIndices[index] = temp;
           // FIX BEGIN
           solver.particleToActor[particleIndices[index]].indexInActor = activeParticleCount;
           solver.particleToActor[temp].indexInActor = index;
           // FIX END

I tried it on my scene and if fixes the problem wonderfully!
I guess this was the intent of the existing swap in particleIndices above (cf the comment), but the change is not deep enough in the system for it to work correctly.
Unless the bug was due to me using the system in the wrong way, I guess it would be good to have this extra piece of logic integrated in the next release.

Cheers!

Hi!

Thanks a lot for taking the time to post the fix! It is thanks to users like you that Obi is steadily getting better Sonrisa.

The issue was discovered by another user, and it is fixed in 3.3. It's not too far away from being published.

See the thread where it was discovered/fixed:
http://obi.virtualmethodstudio.com/forum...hp?pid=415
Reply
#3
(30-01-2018, 11:25 AM)josemendez Wrote: Hi!

Thanks a lot for taking the time to post the fix! It is thanks to users like you that Obi is steadily getting better Sonrisa.

The issue was discovered by another user, and it is fixed in 3.3. It's not too far away from being published.

See the thread where it was discovered/fixed:
http://obi.virtualmethodstudio.com/forum...hp?pid=415

Oops I missed this post Guiño
But that's nice; good to see that Obi is actively maintained!
Is there a post anywhere that sums up the content of the next releases (like bugfixes, features, etc.) or the development roadmap? That could be useful Sonrisa
Reply
#4
(30-01-2018, 01:12 PM)tooomg Wrote: Oops I missed this post Guiño
But that's nice; good to see that Obi is actively maintained!
Is there a post anywhere that sums up the content of the next releases (like bugfixes, features, etc.) or the development roadmap? That could be useful Sonrisa

Hi!

Not currently, but we'd like to add a roadmap section in our webpage. That way anyone can see what's coming next. I can share with you the current changelog for 3.3 though. The biggest changes are:

- the addition of adaptive distance fields.
- the ability to use multiple emitter shapes per emitter which is great for creating composite shapes.
- solver sub stepping.
- much lower garbage generation for collision/fluid callbacks.

Complete changelog:

## [3.3]

### Added
- Support for 2D rigidbody coupling has been brought back.
- Added substepping to the core solver. This allows to update each solver at a different effective frequency, and decouple Obi's
physics loop from Unity’s.
- New implementation of fine-grained parallel tasks in core solver, that boosts performance up to x1.5.
- Support for a new collision primitive: distance fields.
- Initial particle color for emitter shapes. Each emitter shape can now influence the color of particles being emitted trough it.
- ObiCollider automatically creates ObiRigidbody component if needed when reparenting it.

### Changed
- Emitter shapes now need a reference to the ObiEmitter they are attached to. This allows to have more than one shape per emitter, which enables the creation of complex compound emitter shapes using several simpler ones.
- Near-zero garbage generation for OnCollision and ObFluidUpdated solver events.
- Removed SupportsAllSamplingMethods() from ObiEmitterShape. Separated old SamplingMethod enum in two enums: SamplingMethod and EmissionMode. SamplingMethod can have different values depending on the shape used, EmissionMode is part of the emitter and has two values: Stream and Burst.

### Fixed
- solver.particleToActor wasn’t being correctly updated when killing particles in a emitter. This caused random particles to disappear when setting their life to zero, using particleToActor to retrieve their indices.
- Null reference exception in pin constraints when visualization is enabled.
- Bug that caused asleep particles to miss collisions upon reactivation.
Reply