mesh based particle system

[GameMonetize]

THIS DEFINITELY SOUNDS LIKE a BJS 2.2 feature

[jerome]

Nice demo and thank you for the feedback 

 

I will look into the CPU profiler with Chrome.

I usually take care about not allocating anything (except some tiny var with scalar types, but no array nor object) once the render loop is started.

Maybe I missed something this time ... not that simple to keep concentration when people come and chat in the office, pfffff

 

I will review my code, I have yet a lead to avoid the anymous function call (a closure actually). I need to check if I can reduce the number of total iterations. Iterations take time when we deal with dozen of thousands vertices. 

ComputeNormals() does this kind of iteration also. The right way would be to integrate the normal computation within the global vertex iteration, instead of doing it twice successively. Definetly not a DRY approach to recode the computeNormals() method 

 

And as the SPS can handle as well plane particles as well solide ones (unpredictable shape if I can achieve the duplicate method for any mesh model), it's quite impossible to implement a new (new algo) dedicated computeNormals()

 

BTW, if the light doesn't need to reflect on the particles (emissive color or whatever), we can ever set mesh.freezeNormals()

 

 

My SPS has no rate nor capacity. It is possible not to shoot everything at the beginning.

Actually everything is possible and nothing is implemented by default. I want to keep it behavior agnostic 

 

Note you can make a different behavior per particle, per shape, per color, etc ...

[jerome]

CPU Profiling done ....

 

As I focused on the GC activity, I modified the custom recycle function here : http://www.babylonjs-playground.com/#2KSQ1R#11

As you can see, there is no more object creation (I mean no new BABYLON.Vector3) by the user, I just set directly numeric values to particle properties. This means that the GC collector activity, if any, will now be only related to the internal SPS.setParticles() function.

 

The CPU profiler result shows absolutely no difference : 16% GC with this modification.

Reviewing the setParticles() code, I note there is no object creation, except the use of 4 temporary variables for storing index integers... this wouldn't disturb the GC !

 

So I just tried to set mesh.freezeNormals() before calling setParticles(). Light reflection on particles is not mandatory in many cases.

 

What happened then in the CPU profiler ?

No more GC activity !

 

This means the GC activity is related to the computeNormals() usage on really big meshes updated (changing shape) each frame.

As I am one the gulty guy to have coded this method, I just reviewed it here : https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.vertexData.ts#L1206

 

As you can read it (if you've got the courage to do it), you can notice that computeNormals() only creates 9 temporary Vector3 each call, it is to say each frame here.

 

So I wonder why these poor object creations could generate 16 % GC activity ?

Or am I missing someting ...?

Yet, I stressed a lot the computeNormals method when I optimized it and never noticed any GC pertinent activity at this time

 

Unless there is another cause I just can't see ...

[jerome]

here is a pure computeNormals test

line 56 comment/uncomment freezeNormals()

line 44, set a decent mesh size for your own machine

 

Feeling confused about the GC behavior on heavy meshes

 

 

That said... the SPS runs yet quite well (60 fps) up to 2-3000 real 3D particles here with Chrome. It's not intended to compete with the current ultra powerful particle system but to provide something else

[RaananW]

https://github.com/BabylonJSX/SolidParticleSystem - It's getting more and more interesting :-)

[qqdarren]

jerome I started a new thread for discussion of the computeNormals() function, which might hopefully fix the GC problem: http://www.html5gamedevs.com/topic/15377-optimizing-computenormals/   There seemed to be lots of low-hanging optimization fruit, so I suspect I'm missing something important :-)

[fenomas]

I changed my lighter model to store all its data in one contiguous float32Array, and along with some other changes this greatly reduced the memory usage and solved the GC issues. It will now happily do 100K particles locally (but far fewer in the playground for some reason).

http://www.babylonjs-playground.com/#QPQQC#1

 

From the looks of things maybe I'd better rename this one, eh?

[jerome]

yep the PG has side effects ...

 

You stored everything in one float32Array ? vertex positions ?

 

I can't see where you update an pass the normals here. Don't you do it ?

[fenomas]

I played with profiling in the PG a little but gave up. Some stuff I could get around but as a whole my app profiles way differently there than in a local page.

 

For data, yeah, I stored everything in one big Float32Array( capacity * 7 ), stored as [ x, y, z, dx, dy, dz, size ]. Next I should probably add alpha and color, which would make it 11 floats per particle, I guess. And rotation/rotationSpeed, if I can fix the billboarding bug. But I haven't played with alpha or colors yet to see if they're possible and feasible.

 

For normals, yeah, typically particles aren't shiny so I just left them out. But even before I wasn't using computeNormals, I was just setting them analytically (since the particles are all separate quads there's nothing to calculate).

[jerome]

nice choice

 

For my part, I will keep the particle property system because I want to provide to the user the way to add its own properties and own behavior to the SPS.

So my idea is to have something the more possible versatile, the more possible accurate and as powerful as possible. If it deals with 1000 complex 3D particles, the job will be done imho. For dozens or hundreds of thousands particles, well, the current BJS system or yours will be better. 

[fenomas]

Sure, and I guess I should probably rename what I'm doing.

 

To be clear, I'm not actually expecting anyone to use 100k particles in a scene, it just lets me find where the stresses are. A real scene will have lots of other stuff besides particles, each of which loads the CPU and the GC, so the whole scene will perform better if each individual part deals well with stress.

[jerome]

Hi people,

 

"a feature a day keeps the DK away"

 

Today : addPolygons(nb, size, vertexNumber)

 

http://www.babylonjs-playground.com/#2KSQ1R#12

 

As there are only plane particles, I reset this PG in billboard mode.

As you can see from the line 42 :

      PS.addPolygons(200, 5, 5);     // adds 200 ploygons sized 5 with 5 vertices each : pentagons      PS.addPolygons(200, 5, 6);     // adds 200 polygons sized 5  with 6 vertices each : hexagons      PS.addPolygons(200, 4, 16);   // adds 200 polygons sized 4 with 16 vertices each... they look like discs

So why to keep dedicated triangle and quad shapes then (addTriangles and addQuads) if we can do polygons with 3 or 4 vertices each ?

Because the addPolygons() function has an automatic texture uvs computation around the polygon center whereas triangle and quad shapes have a dedicated uvs computation process based on the sides of the figure.

 

BJSX doc updated : https://github.com/BabylonJSX/SolidParticleSystem

[jerome]

Hi again

 

I can't resist to introduce you this new feature from a Jahow's original idea :

SPS.addShape(mesh);

Before I write a decent post and a nice PG, just take a look at this : http://jerome.bousquie.fr/BJS/SolidParticleSystem/solidparticles.html

Runs at 60 fps in my chrome here

100 spheres + 100 torus knots emitted

[jerome]

here is the PG : http://www.babylonjs-playground.com/#2KSQ1R#13

I reduced in purpose the number of particles so it could run in the PG on many machines.

 

As you can read from the line 38, I create 3 mesh models.

I just add them to the SPS system, line 47,  with :

SPS.addShape(mesh, nb, optional_shape_id);

Then remove them (line 51)

 

And that's all ...

 

The addShape() function copies into the SPS the original mesh geometry, uvs and vertex colors if any.

[jahow]

Looking good great work, Jerome!

[Wingnut]

That... is friggin' awesome!  Well done!  But...  every 3 seconds... my scene freezes for about 1/4 second.  I also see this happen with MY demented mesh-spewing things:

 

http://urbanproductions.com/wingy/babylon/particlefun/splode/pharticles02.htm

  &

http://urbanproductions.com/wingy/babylon/particlefun/splode/thump02.htm

 

MY stuttering is faster than YOUR stuttering. 

 

The stuttering might be a "Wingnut only" thing.  Anyone else seeing stutter?  (thx).  Again, awesome scene, J!  AND, Jerome is using a new background color!  Did he FINALLY leave behind his world-famous "putty gray"? 

[jerome]

thanks guys

 

You may perhaps reduce the mesh definition ex : have sphere with lower tessellation, idem for knots which are really heavy in terms of vertices

 

There's no magic : the more vertices to update, the slower

Here I have a local demo running for 8' now in Chrome at 60 fps with 200 spheres sized 4 and tessellated 4

 

 

 

huu.. I wouldn't try with the skull mesh

[qqdarren]

Wingnut, I see the stuttering in Firefox, but not in Chrome. I believe this is the garbage collection issue mentioned earlier in this thread. (BTW, it is happening with Jerome's own link, http://jerome.bousqu...dparticles.html, not just in the playground.)

 

If that issue can be fixed it'll be great: this demo looks like an explosion in a balloon factory... I'm sure it is 80% of the way to a great game. Perhaps add a flamethrower or machine gun, and your job is to make sure none of the balloons hit the ground by destroying them first. :-)

[jerome]

mmh... ballons or anything else

 

Let's try a parametric shape, well, a ribbon (what a surprise !)

Not any ribbon... our famous SH !

 

iiihhhaaaaa : http://www.babylonjs-playground.com/#2KSQ1R#15

 

line 66 : number of SH types

line 67 : number of particles in each type, so the total particles number will be the multiplication of these two values

 

the SH tessellation is related to the two lat, long parameters line 77

you can reduce them, ex with 8,8 instead of  16, 16 : http://www.babylonjs-playground.com/#2KSQ1R#16

 

As each SH is randomly computed, you will get different shapes each time you run the PG

 

reduce the initial speed line 70, if you want them jump lower ex : speed = 1.2

 

have fun

 

 

[EDIT] : this demo runs at 60 fps in the PG in my Chrome here : http://www.babylonjs-playground.com/#2KSQ1R#17

nbSH = 5

nbPartPerSH = 150

SH = 8,8

[jahow]

huu.. I wouldn't try with the skull mesh 

 

That is sad. This mesh is 75% of why I love BJS.

[jerome]

ok, I delete the SPS repo then ...

[Wingnut]

Fantastic!  So now, on to the "emit from emitter vertex points in the normal's direction" feature? (spray from 6 corners of a box, for starters)  And then, the "particle uses vertex color" feature?  And then... "cycle through this array of materials" or "use the emitter's material on the particles"?  And the subMesh emitter... and subMaterial emitter... where each vertex emitter uses the material of its subMesh or subMaterial.  Wow! 

 

There's a whole new section of SPS... that starts with the new Babylon.Tools.AdvancedParticleEmitter    Maybe it's a smart emitter.  Just send it a wad of particles, and IT will material them, launch them on its vertices, and update them itself.  Woah.  Shared workload between particleSystem and emitter.  Err... maybe not.

 

What is taking so long? 

[jerome]

aarrff...Wingy, you're laughing at me but I like this 

 

Actually, I don't know if you read the github doc, it is really user-friendly to choose the particle types :

SPS.addCubes(nb, size);SPS.addQuads(nb, size);// or from an existing mesh, say a sphereSPS.addShape(sphere, nb);

I have to admit it is less user-friendly then to design one's own SPS behavior (trajectories, physics or nothing if you just want static particles set somewhere)

 

 

can't stop playing... this one runs at 60 fps on my pushcart laptop : http://www.babylonjs-playground.com/#2KSQ1R#18

[jerome]

the same with random SH tessellations each run : http://www.babylonjs-playground.com/#2KSQ1R#19

60 fps on my pushcart, 120 complex "particles" only but a random total number of vertices each run

[Wingnut]

hehe.  I love it.  It's so flamboyant and joyous and pastel!  Like a Martha Stewart parade/party.    (South Park - Queef Sisters ep) 

 

Jerome, what I am laughing-at... is a phenomena called "creaping featurism"... and by making suggestions about smart emitters and thinking-up a thousand new features to add... I'm feeding that... and it makes me chuckle.  But so does the look of the demos.  They are... something.   Gleeful.    Nice work... I'm enjoying the show.