Hi,
I’m wanting to create particles similar to this:
https://www.babylonjs-playground.com/#3W04PW#0
But I want to create them within a container at random x,y,z positions in this container. I don’t need to animate them as I will be moving the container while the camera stays still thus moving through the particles.
What would be the best way to achieve this?
I can’t seem to find any example of a particle system that sets the positions of the particles individually / directly.
Thanks
D
Hi @Darcey
You can customize the particles start position function
https://doc.babylonjs.com/how_to/customise
And here is a playground that shows it:
Thanks for the links & replying, yes I’ve read that but it doesn’t detail what I need. I also tried BABYLON.SolidParticleSystem but I am unable to get particles to display like the ones in the BABYLON.ParticleSystem, transparency and light reflection issues.
A cleaned up link for that demo you have me (thanks for that):
https://www.babylonjs-playground.com/#10XN2J#22
SolidParticleSystem
https://doc.babylonjs.com/how_to/solid_particles
I need the particles to be static, non moving and in a container which I will be moving a FirstPerson camera through, the particle container (cube/box) will be very large area, if I go this route then I will have to work out velocity of camera and match the velocity of the BABYLON.ParticleSystem and it’s direction based on camera direction and motion (which sounds like a nightmare to do).
I will try creating the particles as planes in BABYLON.SolidParticleSystem and see if I can get them to display correctly as the particles in the demo do and do a random x,y,z vector position on around 5,000 of them. Or sprites maybe…
Thanks
D
Standard immobile particles should do the job for what you need.
A SPS can also do the job. Could you share your SPS attempt and your standard particle test in a playground so we could see what’s wrong with them ?
Hey guys. I stole one of Jerome’s box-of-SPS-triangles for a test I was doing recently… on lights.
https://www.babylonjs-playground.com/#2FPT1A#324
Something to fiddle-with. Lines 23-31… you see Jerome’s custom positioning function. He also has a simple custom updater function in lines 50-53. This has 200,000 triangle particles in a flattened box-shape… something to play-with. Reduce to 20,000 for more sanity.
The lights… you can’t shine lights on standard particles… but on these SPS… ya can, and so I did. Just fun stuff.
Line 34 radius sets particle size, line 19 particle count, line 20 box size, etc. (Wingy hugs Jerome for inventing SPS). Next gen of hardware, we’re going to “plow” SPS particles with Tonka toys… you know… MotorGrader Operator 1.0. 
FUN!!! Grain Elevator Tycoon! Gravel Pit Bull! heh.
Jerome already has basic particle collisions… working fine. Can ya smell the “Snow Plow Operator 1.0” on that demo? huh? I can.
I’ve cooked up this playground example of where I am at:
https://playground.babylonjs.com/#0ZV4IX
Issues I have are:
Unable to get particles to display like the ones at:
https://www.babylonjs-playground.com/#10XN2J#22
As the particles don’t fade out with distance, I tried fog but that doesn’t work either. If there is a way in the render loop to check particle distance from camera and then set it’s alpha that might work but I’m betting this might start to get a bit heavy on the old cpu/gpu. Maybe if visiblility = false if alpha = 0 might lighten the render load? Maybe I could try to work out camera orientation / direction and match particle direction on BABYLON.ParticleSystem and eyeball velocity values of camera movement to particle / emitter speeds, however this would need to follow a FreeCamera. EG. It’s always raining on you, not the whole world 
Particle texture, even with blendmode and alpha at 0.99 the particle plane texture is not trueley transparent and you can see that they are squares.
@jerome & @Wingnut
Love that particle collisions playground example! I’m already having ideas of sparks bouncing off a wall in some kind of metalic scene
https://playground.babylonjs.com/#0ZV4IX#1
3 you need to enable the alpha channel for the mesh vertices line 132
2 no need for fog, but you could add it for an extra effect, so commented out in my example : line 25
1 just add a computation of the particle/camera distance (squared distance is faster to compute) and set the particle alpha value according to this distance, line 121
https://playground.babylonjs.com/#0ZV4IX#2
the last factor in the multiplication at the line 131 (0.02 here) will increase or decrease the fading intensity according to the distance.
@jerome Nice! Thanks! That playground is going to get me refering to it quite often in the future I’m betting
Is there a way to improve performance, I need to have the particles span an extremely large cube area:
https://playground.babylonjs.com/#0ZV4IX#3
Is there a way distable render of the particle if it’s alpha is 0?
For this reason I may need to use BABYLON.ParticleSystem and work out how to move/rotate the ParticleSystem relative to camera rotation/direction and the ParticleSystem velocity relative to that of the FreeCamera’s velocity, while keeping the FreeCamera in the middle of the ParticleSystem (To make it rain on yourself and not the world/scene so to speak) .
D
I just tried moving the ParticleSystem version with a FreeCamera, what’s your thoughts on doing it this way?
https://playground.babylonjs.com/#JTXCMP#3
UPDATE:
Fixed playground example it will now render…
I’ve done some adjustments to the original playground example, code clean up etc and I switched out the ArcRotateCamera with a FreeCamera, the SPS Particles dissapear at certain angles, I think this is because of the center registration point of the SPS mesh? As in that vector point is no longer in the render view and thus the whole SPS gets removed from the render engine?
https://playground.babylonjs.com/#0ZV4IX#6
Move around the scene with AWSD and mouse look and you will see the issue.
Any ideas?
Thanks
D
https://playground.babylonjs.com/#0ZV4IX#7
line 232 to set compute the SPS Bbox once for all as its size doesn’t change then (or 233 if you want to skip the frustum test)
line 223 to set almost invisible particles as really invisble : invisible particles aren’t computed in the SPS particle loop, so it increases the global performance.
If you want 100 000 planar billboarded (2D) particles, you may consider using the standard particle system or the GPU particles instead of the SPS.
And… sps.mesh.alwaysSelectAsActiveMesh = true; will prevent that “disappear when turning” issue, I think.
Yep, you are correct. When the center of sps.mesh goes out-of-camera-frustum, the BJS optimizer tries to setEnabled(false)… for max performance.
Nice 1, thanks for the fix.
Is there a way to generate the standard particle system (BABYLON.ParticleSystem), so that it doesn’t animate and over a large cubed area as per the SPS example for the FreeCamera to move around in?
Here’s an updated playground (that works) using ParticleSystem.
https://playground.babylonjs.com/#JTXCMP#4
NOTE: Not sure what randomCircleCoords() would be to maintain particle generation within the camera viewport at any possible angle & position.
I attempt to move the ParticleSystem around around at line 180 to 184
@Wingnut
Thanks for the tip
Hi again, guys. I recently did a LITTLE work on using camera.position as a standard PS emitter. (standard particle emitters can be mesh or a vector3… and camera.position is a vector3.)
https://playground.babylonjs.com/#36UHXZ#36
(pardon the sparkly-particles custom updater)
I just barely started… mostly working in lines 120-125. It is quite easy to drive the camera fast-enough to exit its around-the-cam particle cloud. My goal was getting particles spraying from the entire edges of the render canvas… toward screen center. I started a thread about it… but few were interested or knew of solves. (yawn)
Also, Darcey… you might have noticed some problems with “depth sorting” and other alpha-related things… on standard particles. Expected behavior. Since standard particles are sort of like a single ground grid that has been divided-up into separate cells, the particles can only be depth-sorted IN-FRONT-OF, or BEHIND other mesh. I’m quite sure standard particles cannot be both behind and in-front-of other mesh… at the same time.
But maybe it can be done… using multiple particle systems. They are lightweight… no problems using many. Standard particles have an age (maxLifetime) that determines when they recycle… and they gentle-change from color1, to color2, to colorDead… across their lifetimes… so that gives you SOME fade-out features… time-based, not distance-from-emitter-based.
There are helpers nearby that are WAY smarter than I… on these subjects (such as Jerome). Generally, I am just a playground librarian. heh. I should just shut-up, really.
I don’t really know how to use the standard particle system, but I know that you can overwrite the emitter behavior and that you can set immobile particles at random locations.
You’re sort-of grappling-with the question: Is it better to move camera thru cloud of stationary particles, or parent-to-camera… an invislble emitter out in front of camera.direction, and set ps.gravity (and/or particle emit-directions) to move particles toward the camera? (in webGL particles, gravity can be sideways.)
In my previously-linked PG… line 125…
particleSystem.gravity = camera.getDirection(BABYLON.Axis.Z).negate().scale(.5);
heh. Goofin’ around with sideways gravity.
@jerome & @Wingnut
Yep, looks like I will have to try something different, what I can think of:
I love your spirit. Keep in mind… the amount of power you can program-into custom startPosition and custom updateFunction on both types of particle systems. You can force the particles to act however you wish… just by fully exercising those two write-them-yourself functions. BUT… they could be complex… and they will definitely be monitoring camera values carefully, and morphing their functionality based-upon what the camera is doing. Both functions… run often and fast… often well-faster than human eyes.
Hmm, might be a good idea to watch fps and throttle this as the effect I need is going to be quite subbtle, its to give a better feel of motion so the alpha values will be 0 to 0.2 at most and a lower update polling rate should suffice which should lighten the load up again. hmm or even a web workers lol
Just found this playbround, interesting: