mesh based particle system

[jerome]

Well, the name is (for now) SolidParticleSystem.

 

A first working attempt with alpha textured quad AND cam facing : http://www.babylonjs-playground.com/#2LFJES

Scene is at line 150.

 

In this example, 5000 quads, sized 6, are emitted. Runs at 60 fps in my Chrome.

I voluntary moved the mesh at +30 on the right to test cam facing.

 

I noticed a strange behavior : if the mesh origin is outside the screen, no more particles are drawn !?!

I don't get why ...

 

If a box is half outside the screen, it is yet still drawn.

 

Any ideas ?

[jahow]

The bounding box is very small and centered around the emitter. You may have to update the bounding box once in a while...

[jerome]

ok

didn't know the bounding box was used for rendering...

 

what's the method to update it ?

[jahow]

refreshBoundingInfo();

I tried adding it to your animate() function, but it seriously hurts performance: http://www.babylonjs-playground.com/#2LFJES#1

I guess it's another problem to solve...

 

A mesh bounding box is used to do culling, i.e. not rendering things outside of the view.

[jerome]

well, it's still 60 fps locally in my Chrome

 

else is it a way to set/fix the bounding box size ?

maybe would it be an option to fix it once when creating the mesh ... don't know

[jerome]

another way could be not to call it each frame but only, for example, on particle recycle call ?

 

 

[edit] : just tested => quicker on each frame than on recycle only... very strange (60 fps / 45 fps)

[edit 2] : obvious !! recycle is called per particle, whereas global mesh update is called once after every vertex is updated !

it was a bad idea so ...

[qqdarren]

@jerome Can you explain the motivation for this? I wondered why you've been trying to get the "solid particles" be camera facing. I get that with  particles they face the camera as they are actually 2D overlays, but I thought the point of your experiments was to get the 3D behaviour of real meshes. (And I'm guessing, that by requiring they all look the same, that you are able to get more on screen without hurting performance, compared to creating normal meshes?)

[jerome]

This SolidParticleSystem is a big updatable mesh.

It is subdivised in what we now call solid particles which are, well, some animatable subparts of this mesh.

 

As they are parts of a mesh, they all have the properties of a mesh : they are correctly z-sorted, have good alpha-blending, can reflect light, etc, etc.

They have in this way the 3D behavior of real meshes. They are hidden by opaque meshes between them and the camera, they are visible through transparent meshes and they have a real z coordinate.

You could make them collide if you want. But you would have to compute these collisions by yourself.

 

In the very case of plane subparts (triangles or quads), if we don't implement a camera facing system, you just can't see the subparts if you rotate the cam, say, 90° left (because the cam is then in the same plane than all the subparts). This camera facing system is needed only for plane subparts of course.

 

For real solid (3D) subparts, it won't be necessary.

 

These subparts will all have the same geometry (although I guess we could have different ones, but the implementation would then become quite complex, so for now, let's consider they have all the same shape) but will be able to have different colors and <tadataddddaaa> different textures (if I can achieve it). Actually this would be a kind of texture atlas as for current sprites. 

[jerome]

stress test at home (2007 old laptop computer, pushcart GPU... remember) : http://www.babylonjs-playground.com/#2LFJES#2

 

Chromium : 5000 particles, size 4, light+reflection, alpha, texture, all rotated facing the cam => 60 fps 

iiiihhaaaa

[fenomas]

Awesome stuff!

 

Regarding the bounding box, once a particle system has gotten going, the "cloud" of particles will occupy a reasonably static area. So the ideal thing would be for the bounding box to equal that area, and never need updating. That is, for example if a particle system has particles that live for 100 frames, and each particle gets an initial x velocity in the range [-1 .. 1], then the bounding volume's x-axis would need to cover [-100..100], right? At any given time (particularly right after creation) the system's actual bounds might be smaller, but that can probably be seen as an edge case.

 

With that said, it's not quite as easy to calculate bounds analytically if gravity is involved, and if there's a custom position function then obviously the system can't predict its own bounds. So for simplicity it might make the most sense to either (1) have the user specify a bounding volume when creating the system, or (2) recalculate bounds every N frames.

 

Note: it may be possible for the System to recalculate its bounding volume faster than BJS's built-in method, by looking through its position arrays. In practice the bounding volume will only grow, never get smaller,  so it could be sampled every N frames for a while, and once the bounding volume stops increasing in size the System could stop recalculating. I will take a shot at this tonight (unless someone else beats me to it).

[jahow]

Hey guys, I have two questions for you:

 

1/ Will users be able to use this system not only for emitting particle, but also for simply displaying a large amount of similar, simple meshes without cluttering the scene with thousands of objects? Because I think limiting this to a particle-emitting use would be a shame. For example this could be used for some sort of voxel rendering.

 

2/ Would it be possible to set the angle of each particle individually instead of having them all face the camera, for example for small rocks that would be sent flying and spinning after an explosion?

[jerome]

@jahow

 

# 1 : yes, I think it won't be limited to emit things.

I won't implement any real emitter, recycler, but just provide two default overwritable methods (updateParticle, recyle).

In the same way, I don't want to impose a particle trajectory system. Each user will code its behavior.

 

In other terms, I don't really want this system to embed many real particle system pre-defined mechanisms.

A minima just a way to position particles.

 

# 2 : yes, too.

For now, I just focused on a way to orientate at once (so high optimization) all the plane particles.

But I think I will add a per particle orientation option.

 

The work is in progress so many things could be added yet

 

I think this system would answer to other needs than current particle systems :

better accuracy in positioning and compositing in space but lower capacity in particle number (hundreds or thousands max instead of hundreds of thousands for the current system)

[jerome]

@fenomas : about bounding box pre-computation.

 

This is exactly what I intend to do : set a initial bounding box dimension the user will compute by his own (the system can't predict what trajectory method the user will use).

 

I don't know if the "recalculate N frames" way is the right one, because the particles could then disappear from screen suddenly if, say, a movement camera hiding the system occurs between two recalculation.

[jahow]

Or let the user define a rate of bounding info recomputation? Which could be 0 if the user knows his particles won't actually move but simply stick around

[jerome]

good idea !

 

[jerome]

just for fun, added alpha to the texture with alpha : http://www.babylonjs-playground.com/#2LFJES#3

[Wingnut]

Like we can see those particles?  Man, they are cookin'! 

 

Oh, that's right, you're driving an Apricot.  nod. 

 

You are speaking of the boxes, I bet.    errr...  something. 

[fenomas]

1/ Will users be able to use this system not only for emitting particle, but also for simply displaying a large amount of similar, simple meshes without cluttering the scene with thousands of objects? Because I think limiting this to a particle-emitting use would be a shame. For example this could be used for some sort of voxel rendering.

 

In practice I think this may not be as useful as it sounds. The benefit of treating particles this way is that BJS considers them a single mesh for purposes like view culling and alpha sorting. So using it for a bunch of regular objects will have drawbacks unless those objects are clustered closely together.

[jahow]

It's true, missing alpha sorting and culling can indeed be a problem. For alpha sorting, using alpha-tested texture is a good solution (just like in Jerome's first demos here) since particle objects are usually small, and alpha test does not require sorting. As for culling, a great thing would be to include in the SolidParticle code a way to allocate different particles to different submeshes, for example by setting a "submesh_index" parameter on each one. This way, submesh culling would solve this issue!

 

What I'm thinking about is for example a way to render hundreds of trees & other simple props in a city builder game. Or even buildings that would be rendered as thousands of sprites far in the background. This system would be perfect for that.

[jerome]

Back to code this afternoon   ...

 

So far the plane particle ever-facing process worked only for an unrotated mesh as you can see here :

http://www.babylonjs-playground.com/#2LFJES#4

 

This mesh slowly rotates around Y axis.

When the rotated mesh is parallel to the camera axis, the particle become invisible.

 

It's fixed now : http://www.babylonjs-playground.com/#2JMK7G

This mesh rotates around x,y and z axis and the particle keep facing the cam.

 

Scene from line 150, as usual.

 

Under the hood, I kept the particle facing computations in the local system because they are really fast (only additions and multiplications, no matrix) and I set a fake camera position : the real camera position inversely rotated by the mesh rotation value

So this demo still runs at 60 fps here

 

[EDIT] this demo has live bounding box recomputation each frame, you can disable it by commenting the line 122

[jerome]

I know you all want all these wonderful features as real 3D particles, each particle rotation, submesh indexing, manual bounding box setting, multi-textures, etc right now.

 

You'll have to wait !

 

Step after step ...

 

 

http://www.babylonjs-playground.com/#2JMK7G#2

here is for now the per-particle-scaling feature !!!

 

All particles are here randomly re-scaled on each recycle call.

As each particle object is accessible within the animate() method, you could have changed each particle size at each frame also.

 

scene from line 160 now.

[Wingnut]

Nice, J-willickers! 

 

Jahow... with different layers of "particle trees"... that might require a separate particleSystem for each layer/distance.

 

Ok, back to Jerome... why do you have these things always facing the camera (billboarded)?  Let's get these things tumbling, huh?  Our default particles spin around z.  Let's get some spin around x and y, too, Jman! 

 

But really, we want flying ribbons, don't we?  We want each particle to be a random basic shape, with unknown number of vertices, and the particle updater first queries the particle to find out how many vertices it has, and then it does the rotational update on THAT many vertices.  So, in a way, each particle carries with it... what shape it is (not really, but it carries how many vertices/indices it has).  Then the updater knows how far to traverse the vertexBuffer.... to get-to the next shape.

 

First particle, a torus knot.  Second, a box.  Then a Lines mesh, and then a ground, then an imported model, then a mesh with a displaceMap.  That should slow that particle machine of yours.... to a crawl.  heh.  

[jerome]

hey Wingy

the billboard mode like is a for plane particles only (else tey disappear when the cam is in the same plane than them)

 

a shape model per particle ? mmmhh.. why not ? more complex, but I think it is feasible ...

 

step after step 

- similar plane particles : need to adjust to any shape now

- per particle rotation (3 axis)

- similar 3D particles 

- per particle texture or color

- ...

- per particle everything : shape, rotation, size, color, texture

 

outch

[jerome]

Hi guys,

 

Here are some new features : http://www.babylonjs-playground.com/#T80US

each plane quad has its own velocity, scaling, and rotation

 

Line 58, changing the model index : http://www.babylonjs-playground.com/#T80US#1

I use now another build-in model, a triangle, instead of a quad

 

Line 57 now : http://www.babylonjs-playground.com/#T80US#2

As you can see, the model is per particle also : there are quads AND triangles in the same system    ... and a little bug, I can't find out for now making sometimes a long stretch particle (probably in the resetParticle function [EDIT] : I think it's fixed now, but I didn't push the fix in the PG)

 

scene from the line 250

 

Many un-needed properties have been deleted (gravity, vel ...) because they were too specific to a given physic model and I want this SPS (solid particle system) to be agnostic in terms of physics, behavior, etc.

So now, you just create the system, then you init it (instead of "start" it) with initParticles, then you set its particles with setParticles (instead of animate, because it's mandatory to animate things, you could just set them once and let them as they are).

 

new = create the mesh, it is to say create all the particles with the given model shapes... for now,  the models and model choices aren't parameters. Should come soon

 

all the function with names in the plural expect to iterate on each particle

all the function with names in the singular are called per particle

 

initParticles : can be over-written ... set initial values like velocities, positions, rotations, etc

setParticles(billboard boolean) : set all the particles in space according to their current properties and to the billboard boolean value (ever facing the camera for plane particles or not)

This function calls the user over-writable updateParticle(particle) for each particle. In this custom function, you can define your particle behavior and even call the recycleParticle(particle) function, which is also over-writable.

 

As you can see, the vertex stuff is hidden in the system.

The user needs only to deal with particles, positions (particle positions), velocities, rotations, etc

[Wingnut]

coooooooool !! Your "bug" is almost surely an off-by-one situation. The first vertex of the first particle, or the last vertex of the last particle... isn't getting a position change.

 

(Like I'd know).

 

But that's what it looks like to me.    Fun demo, though.  Particles are fun, period.  Ready to put a smoke-generator particleSystem on each particle?  Faery dust sparkly particle trails (fireworks)?  Your emitter would become an emitter emitter.    Let's hope it doesn't emit emitter emitters.  Rabbit farm!

 

It all started on the planet of Orthogona...  64 particleSystems resided on Orthogona, but only 4 emitters, on the entire planet.  The particleSystem that was the closest to exploding from too many particles... gets an emitter immediately, long enough to belch out some particles. 

 

You've seen the particle explosion upon window focus, right Jerome?  One of your demos does an explosion and then settles down to normal spraying.  Windows users can sometimes alt-tab into a new window for awhile, and then come back to a BJS particleSystem... and it will "puff".  Its pretty fun.  Maybe only on slow machines. 

 

It's as if you plugged its spray nozzle when you left the window, and unplugged it when you re-focused. 

 

But, no.  That's not where Jerome is headed.  He's headed for... um... getting some thickness to his particles... extruding them.  Yep. I bet.