Updated particle system (particle physics influencer)

User Code & Projects
1

Though, this code isn’t really shared atm, I wanted to at least share some of what I’ve been doing with it.

One of the coolest updates is ensuring that particle transforms can be handled completely independent of the emitter. Currently, in JME and another particle system that I won’t directly mention, scaling and rotation are not independent of the emitter. More specifically, the translation is the only part of the individual particle transform that is independent of the emitter.

Before you say… THAT’S NOT TRUE! Let me explain. If you move the emitter shape, the particle will either a) move with the emitter, or b) keep a constant relationship between it’s original emission point and move independently of the emitter. BUT! What happens when you scale or rotate the emitter? Either a) nothing! or b) the entire particle mesh is scaled and rotated with the emitter.

Sooooo… long story short, I updated this to work as I originally intended!

Here is a demo of what this allows you to do. The vid also shows a small hint at the updates to the influencers, which now allow you to add as many change stages as you would like and define the interpolation between each stage independently. I’ll explain more in a moment, however, watch the yellow color. It chases the emitter as it moves.

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

Now, as for the updates to the influencers, like stated above, all influencers allow you to add as many different change stages as you would like. For instance, if your were working with the size influencer… instead of adding a start and end size, you can now do something like this: (on a side note… scaling for all three axis is now independant)

[java]
emitter.getInfluencer(SizeInfluencer.class).addSize(new Vector3f(1.5f,0.5f,1), Interpolation.bounceOut);
emitter.getInfluencer(SizeInfluencer.class).addSize(new Vector3f(0.5f,1.5f,1), Interpolation.bounceIn);
emitter.getInfluencer(SizeInfluencer.class).setFixedDuration(0.25f);
[/java]

The above would switch the particle between a wide/short config to a thin/tall config in a jello-ish fashion every 0.25f second until the particle’s life cycle was over. You can also just use addSize(Vector3f size) and it will assume Interpolation.linear.

Anyways, here is a vid using just the color and alpha influencers to create different effects:

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

Next on the list is adding particle stretching.

10 Likes
2

So, before going and reading about ways of accomplishing particle stretching, I guessed. and it seems to work well (as seen below). How stretching is applied will vary depending on Billboarding of course, for quad meshes anyways. I’m also wondering if particle stretching is useful with mesh-based particles… guess I’ll give it a try and see.

Anyways… here is the basic idea: the faster the particle is traveling the more it stretches along it’s velocity vector. This is multiplied by a magnitude and…

[video]http://youtu.be/MpnlE9bj-pM[/video]

PS… I potentially take back lumping JME’s emitter in with the above transform issue. I forgot JME’s emitter doesn’t allow for emitter shapes/meshes, so… it probably does rotate properly… however there is nothing to scale… so sorta moot.

3

I can think of a good use case for particle scaling based on velocity vector:

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

4

Whoa i cant wait for this to be out with jme’s particles system (or at least with a supported plugin!)

5

This is really nice, a great improvement.

6

Couple more updates:

Reversed velocity as a gravity option (vid is this + particle stretching)

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

And, a velocity influencer that allows for rotational velocity:

[video]http://youtu.be/aHuHH_l-MG8[/video]

The rotational velocity influencer is tangent (Tangent is pregenerated for the updating velocity, however it can also be set by the user to a fixed value for some really cool effects.) * magnitude that is effected by reversed velocity gravity * magnitude allowing for just about circular/spiral type pathing you could dream up.

7

incredible!

8

Man I’d love to be a mod to know who the downvote fairy is.

9

Now, if there would be a way to integrate it all with physics systems…

10
@madjack said: Man I'd love to be a mod to know who the downvote fairy is.

As far as I know, we can’t tell either, actually.

11
@pspeed said: As far as I know, we can't tell either, actually.

Admins I guess would have the right privilege. This can’t be anonymous only. I do remember someone mentioning they knew who had voted up/down. I just don’t remember who.

12
@abies said: Now, if there would be a way to integrate it all with physics systems...

I just started playing around with this. @thetoucher did a fine job with this already! Not sure if he is using JBullet to report collisions or collideWidth and generating a reflected trajectory. But one or the other will work!

13
@madjack said: Man I'd love to be a mod to know who the downvote fairy is.

It was a Particle-Rights Activist. They are marching outside my house at this very moment holding signs that say “Particles are people too”, “Emission is not a life-choice, they were born this way” and “Don’t drive under the influencer” (Oh wow… that last one was REALLY bad)

1 Like
14

Speaking of particle physics… thoughts on the subject?

  1. I’ve considered simple reflection planes (this would be ultra limited)
  2. Using collidesWifth against a list of geometries defined/maintained by the user (This would be my choice)
  3. I don’t think JBullet is a viable option as you would have to regenerate the collision shape for the particle mesh each frame (though I know very little about this subject, so… maybe @normen can give me a clue on this? If not, that’s cool too)
15

Don’t worry, bad puns are good in their own ways. :wink:

1 Like
16
@t0neg0d said: 3. I don't think JBullet is a viable option as you would have to regenerate the collision shape for the particle mesh each frame (though I know very little about this subject, so... maybe @normen can give me a clue on this? If not, that's cool too)

Idk why you would recreate the particle mesh every frame, I would say its about moving the particles and having them collide and not making other stuff collide with the particles, right? So just make it a bunch of physics objects like for example spheres.

17
@normen said: Idk why you would recreate the particle mesh every frame, I would say its about moving the particles and having them collide and not making other stuff collide with the particles, right? So just make it a bunch of physics objects like for example spheres.

Thought was… particle influencers can set up very un-physics-ee situations (unrealistic, defying the constraints defined for the physics engine, etc). Particles really only need to be sticky or bounce… much past this would be a little overkill for something that already only approximates an effect.

I guess what I was wondering was, do you think using JBullet would be overkill? Right now, I am doing simple collision using collidsWith… and though taxing when checking against large numbers of complex meshes, seems to do pretty good when constrained to checking a few objects.

Here is a really quick throw-together… the “suedo physics” is an influencer. You hand it the GeometryList you want to check against and (eventually) choose whether or not to make the particles “sticky” or “bounce”. Bounce will only reflect the velocity vector against the contact normal and apply some friction. Then the particle is back to relying on the other defined influencers for what to do next.

Thoughts on the approach compared to JBullet?

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

1 Like
18

19
@zzuegg said:

Link didn’t work =( nm!! It does now

20
@t0neg0d said: Speaking of particle physics... thoughts on the subject?

  1. I’ve considered simple reflection planes (this would be ultra limited)

  2. Using collidesWifth against a list of geometries defined/maintained by the user (This would be my choice)

  3. I don’t think JBullet is a viable option as you would have to regenerate the collision shape for the particle mesh each frame (though I know very little about this subject, so… maybe @normen can give me a clue on this? If not, that’s cool too)

  • sounds like a good idea for adding flat floor only collisions, would take no time to author and be very fast.

  • 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.

  • I use JBullet in my test, all of the particles interact with the BulletAppState physicsSpace (in my scene that is the characters, floor, walls, ceiling and pillars). This needs to be approached as an external physics influencer, the particle mesh does not go in the physics space: since it is a single mesh it can only be treated as a single object: if you did put the mesh into the space, after the collisions have been resolved, all particles would be influenced by the same resultant force, as if they were all frozen in a block of ice (or carbonite).

    • 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’.

    I’m happy to share parts of what I did if it will help anyone out, the reasons I didn’t just share it all to begin with is because I needed to make some minor tweaks to the core.

    It’s looking great @t0neg0d, keep up the good work =)

    1 Like