dimforge / rapier

2D and 3D physics engines focused on performance.
https://rapier.rs
Apache License 2.0
3.77k stars 235 forks source link

Particle physics #588

Closed phisn closed 4 months ago

phisn commented 5 months ago

I am using rapier in my game as the physics library. My game does contain particles. Since I need determinism and want to simulate without particles I am currently creating a custom physics world for the particles. Particles do not interact with each other. I am currently using bevy but since my particle simulation is separated from the bevy plugin I need a native Rapier solution.

The problem is that when having a lot of rigid bodies that all do not interact with each other they still perform unnecessary computation. I am sure about that because with around 500 circle rigid bodies they contribute to around 70% of all computation in my game (determined using a profiler).

Is it possible to have a large amount of rigid bodies that all do not interact with each other in a performant way (for example a filter in the broad phase)?

sebcrozet commented 5 months ago

Are you compiling in release mode? This makes a massive difference performancewise. Would you mind posting a screenshot of one of the scenarios causing performances issues? That will help understand what could be going wrong.

phisn commented 5 months ago

So. I am currently in progress in porting the application from typescript-rapier to bevy-rapier. I didn't got to implement particles in bevy yet. Therefore I am sure, that rapier is compiled in release mode with this issue. I also know that all performance issue stem from rapier, since this 70% number comes all from the single .step call from inside the rapier particle physics.

Im not sure what you mean by posting a screenshot of the scenario. In my case its a rocket game where I am using particles to model the rockets outcoming thrust. These can reach up to 500 at a time depending on the settings.

The current runnable code for my particle system is here repo. One thing that just came to my mind is to reuse rigidbodies and colliders. But I think I tried that without making any meaningful difference which is why I am currently using the simpler method of creating new ones.

sebcrozet commented 4 months ago

Thank you for the repo link. By screenshot I meant something like this. This helps quickly understand the scene’s configuration: image

I wouldn’t advise to use a physics engine for these kinds of particles effect. A simple straight-line or pseudo-random trajectory for these particles would likely be sufficient and way less computationally expensive.

My guess here is that most of the computation times are caused by the fact particles are all spawned intersecting each other, that will cause a significant computation times in the broad-phase (since we effectively have O(n²) collisions).

phisn commented 4 months ago

Is there any way to prevent the computation in the broad-phase? Or is there any other physics library that would be better suited? (I especially do not need determinism for this feature). It would be interesting if there exists a physics abstraction similar to what unity uses for particles. There it rasterises the whole world and saves interactions for each cell.

phisn commented 4 months ago

For future readers. I decided to use bevy_xpbd where I am able to define a custom broad phase. My idea is to now ignore all collisions between entities with Particle components. Additionally I don't have to deal with having two rapier contexts (this is needed since I can not put my particles in the existing physics simulation since I need determinism).