Updated particle system (particle physics influencer)

Sure that works, nothing to complain about with your implementation. You could make the picking / collision part pluggable and create a version for people who don’t use collideWith but only bullet collision, so the overhead doesn’t get doubled. Then in turn one could also plug bullet right into collideWith at some point…

If you only have a few objects that actually collide (the particles don’t have to collide with another) then using bullet completely for the path computation plus collision is surely possible and should also perform quite well. I would probably use a separate, threaded physics space and only reuse external objects collision shapes though if possible. And you would have to use custom controls or the base physics objects directly as none of the controls work like this.

1 Like

In addition to sticky particles, it might be useful to have “fragile” particles which are destroyed when they collide with other objects.

1 Like

UDK has an interesting approach to particles and collision using depth: http://www.youtube.com/watch?v=RURQSR788Dg
Not sure it applies here, but worth a look.

1 Like
@thetoucher said: 2. sounds like it is encroaching on "roll your own physics engine" territory, which unless you have a very defined outcome and really know what you are doing, sounds like a horrible idea, since you miss out on all the optimisations, development effort and features of existing solutions.

Why this crossed my mind is, there are already multiple influencers that do just this:

Gravity
Impulse
Velocity

  • custom influencers written by the user

If you were to hand over the particle to a physics engine, wouldn’t it negate everything else that is going on? Meaning you either get physics or influencers but not both.

If the physics influencer did nothing more than change the angle of the normalized velocity vector and then reapply the length of the original velocity vector after accounting for friction, you should be able to apply this without overriding the rest of everything that is going on.

Yes, it is limited to collision only, but it would feel real enough.

1 Like
@sgold said: In addition to sticky particles, it might be useful to have "fragile" particles which are destroyed when they collide with other objects.

Definitely… really awesome observation. This will actually help bring fps up.

1 Like

Well… here is a quick implementation of the physics influencer I talked about above. Right now, I’m not giving much breathing room between detecting a collision and checking for collisions again. You should be able to set a global delay for how often to check for collisions and a specific delay for how long to wait after detecting a collision and starting to check again for the particle in question. This will both speed up FPS (always an added bonus) and solve the “unintentional sticky particles” in the vid below.

So, with that said, keep in mind that this is supposed to approximate simple physics collision and reflection for particles, still allowing other influencers to effect the outcome… nothing more :wink:

[video]http://youtu.be/KiC3_Vn_c0E[/video]

What about creating a separate, independent physics shape (small sphere) for each particle? Not sure how well Bullet scales for thousand+ objects, but it might be simpliest and most powerful solution. Then gather the locations/velocities back into render system which would still use single mesh.

Other option would be to port PhysX :wink: It has particle module which interacts with all the rest of in-scene physics. There are even more goodies in Apex, but then it goes into major magic category (plus, Apex seems to be a lot more limited platform-wise).

@abies said: What about creating a separate, independent physics shape (small sphere) for each particle? Not sure how well Bullet scales for thousand+ objects, but it might be simpliest and most powerful solution. Then gather the locations/velocities back into render system which would still use single mesh.

@thetoucher said: I created a physics influencer that utilised a pool of JBullet collision spheres, when a particle is created, it gets assigned a collision sphere that inherits the particles location and initial velocity. Then each "tick", after JBullet does it's magic, each collision spheres reports their location (and velocity) the linked 'particle'.

… =/

@abies said: What about creating a separate, independent physics shape (small sphere) for each particle? Not sure how well Bullet scales for thousand+ objects, but it might be simpliest and most powerful solution. Then gather the locations/velocities back into render system which would still use single mesh.

Other option would be to port PhysX :wink: It has particle module which interacts with all the rest of in-scene physics. There are even more goodies in Apex, but then it goes into major magic category (plus, Apex seems to be a lot more limited platform-wise).

Because of the interaction with other influencers… and because the other idea worked out pretty good:

[video]http://youtu.be/KiC3_Vn_c0E[/video]