mesh based particle system

[jerome]

a working version : http://www.babylonjs-playground.com/#T80US#3

[GameMonetize]

Just to be sure:: We can do the same with the current particles system: http://www.babylonjs...ound.com/#T80US

 

Or I'm missing something?

[jerome]

yep, you're missing something 

 

For now, I just coded a mesh based particle system with the same behavior (less features actually) than the current one, it is to say : display plane quad particles. Mine is less powerful in terms of particles than the current also...

 

So why to do this ?

 

Because it has other properties the current one doesn't have.

As it is a single mesh blowed in parts, each particle here has the same capabilities than a mesh face : it reflects light, can be textured, rotated, etc.

Above all it has the same z-sort and alpha blending than a mesh !

Look closely at the two boxes : the particles are hidden by the opaque box and are visible through the transparent one : 

http://www.babylonjs-playground.com/#T80US#5

This solve a problem of the current system : http://www.html5gamedevs.com/topic/13628-particles-and-material-alpha/

 

Moreover, it can handle simultaneously different particle shapes in the same system (for now triangles and quads only, the generalization to any plane shape is possible yet) and soon solid particles (cubes, pyramids and maybe any model of existing meshes) : http://www.babylonjs-playground.com/#T80US#4

And if I can achieve it, it will handle a per-particle texture feature too.

 

So the goal of this system (I will probably keep it in a BJSX extension only) is to provide the ability to deal with few solid particles (hundreds to few thousands max) with all mesh properties.

 

It won't implement any behavior (trajectories, physics, etc), so it won't be that straight forward for newbee/impatient users   

[fenomas]

Or I'm missing something?

 

Same thing we talked about a while back - current particles perform great but don't composite with transparent meshes or sprites.

[GameMonetize]

ok gotcha..this is perfectly clear

[jerome]

@wingy : BAAAAOOOMMMMM   http://www.babylonjs-playground.com/#T80US#6 

[Wingnut]

Ok, ya ready for this?  How about...the particles take-on the material of the subMaterials... on the emitter?  Woah.

 

 

Ok, that's a little too... something.  Notice that the streams of particles... are coming from vertex points, likely aimed by... maybe... the normal?  I just set the checkbox to use vertex points and the randomly across surface choice turned off, best I can remember.  (about 10 years ago)

 

Did someone say per-particle texturing?  OMG!

 

 

That's all 3D Max... but... I just wanted to make sure that "the bar" wasn't getting too reachable too soon. 

[jerome]

Very nice demo, Wingy !!

 

Big code refactoring here to plan the integration of the next features.

So new demo : http://www.babylonjs-playground.com/#2KSQ1R#4

 

As you can see in the code below, some things have changed :

    var PS = new SolidParticleSystem('SPS', scene);    PS.addTriangles(500, 1);    PS.addQuads(500, 1);    PS.addTriangles(10, 8);    var mesh = PS.buildMesh();    mesh.material = mat;    mesh.freezeWorldMatrix();    //mesh.freezeNormals();        PS.initParticles();        //scene.debugLayer.show();    // animation    scene.registerBeforeRender(function() {    PS.setParticles(true);    pl.position = camera.position;    });

The SPS constructor just creates an empty particle system.

You have then to add particles to it (here, we add some pre-build types : 500 triangles, size = 1). I wish I can then implement a feature to add an external particle geometry (not only pre-build ones)

You can add different or same particle types as many times you need.

 

When finished, you call the SPS mesh builder which returns the SPS underlying mesh. This one has now support for freezeWorldMatrix (if it is immobile), freezeNormals (if you don't need normals re-computation each frame) and of course to all the Mesh type properties.

 

You can then call the over-writable initParticles() function to set each property of all the particles.

 

Then the setParticles() function will set the particle in space according the current particle property values.

Some custom function like updateParticle() and recycleParticle() can be overwritten and will ba called on each particle by setParticles.

 

I think I will add calls to custom beforeUpdateParticle(particle) and afterUpdateParticle(particle) functions too. These will be useful if the user wants to do to things  within setParticles() before or after the iteration on the whole pool of particles.

 

 

 

 

Note : I added a little trick to import the script instead of to copy/paste it. So please reload (F5) as necessary if the script isn't loaded before the engine starts and press the 'RUN' button after each F5 as the error label doesn't disappear.

 

The current version of this code is available here : https://github.com/BabylonJSX/SolidParticleSystem/blob/master/solidparticlesystem.js

[Wingnut]

Nice!  And what an innovative way to do an external script include in the PG!  Interesting!

[jerome]

working on a cubic particle now   : the first real solid particle type

 

[EDIT] I put the script importator at the start as it works better on some browser.

[jerome]

cubes added : http://www.babylonjs-playground.com/#2KSQ1R#5

 

(won't work in billboard mode, some bug somewhere)

 

 

and you can merge triangles with cubes : http://www.babylonjs-playground.com/#2KSQ1R#6

[GameMonetize]

All demos failed for me as the script is longer to load than expected

[GameMonetize]

Fixed for you: )

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

[jerome]

how did you fix it ? in the PG engine ? Thaaaannk you 

usually, the error is displayed but you can still press "RUN" and it works because the script has been downloaded meanwhile and is cached in the browser.

 

[EDIT] ooopss.. s.onload in the code !

didn't notice at first sight, sorry

[jerome]

I realize that in this example, all particles have the same rotation, although the rotation is per particle. It's because I just forgot to set an initial random rotation to each particle in the initParticle() function

 

So here is an improvement : http://www.babylonjs-playground.com/#2KSQ1R#8

I just overwrite the updateParticle() function and give each particle a rotation according to its own velocity : line 63.

 

This example throws 600 transparent cubes and 1000 triangles and still runs at 60 fps in Chrome on my pushcart old laptop 

[GameMonetize]

This smells like a great new feature of bjs 2.2....

[Dad72]

C'est tip top. nice feature, het is geweldig, 

[jerome]

thanks

 

It looks like BJS 2.2, it smells like BJS 2.2, it tastes like BJS 2.2 but is only Canada Dry BJSX for now 

 

The list of requested features by Jahow and Fenomas, who both have different goals, is long like a day with no bread  (I like translating french idiomatics because they have no sense in english : self fun, sorry). I'm still just at the beginning for now...

 

Thinking well ... I'm simply wondering why I started this stuff since I don't really need for myself 

Maybe just for the challenge and because solid particle fountains are so beautiful

[iiceman]

That's awesome! I already loved the normal particles and now I can't wait to play around with cubes Keep going, I really wanna see what else you do with that. And I want it In BJS...now!! ...well, as soon as possible

[jerome]

Hi people

 

"a feature a day keeps the deltakosh away" : http://www.babylonjs-playground.com/#2KSQ1R#9

 

today the per particle color

In this example (500 cubes, 200 triangles and 200 quads), I don't use any material for the SPS mesh (SPS = solid particle system, please follow tssss)

 

I code the custom functions in purpose in the PG (from the line 50) as the SPS has now no more default behavior. Each SPS function returns directly if not over-written.

As you can see, I just set a random Color4 value (yes, color 4, alpha is enabled !) per particle on each recycleParticle() call.

 

I updated the doc here : https://github.com/BabylonJSX/SolidParticleSystem

[qqdarren]

Jerome, that is a pretty demo (http://www.babylonjs...d.com/#2KSQ1R#9). On Firefox it is going at 60fps, but every 2-3 seconds it freezes (perhaps for 0.2s, enough to drop the frame rate to 45fps) then goes straight back to spewing out pastel cubes. It is fine on Chrome: constantly 60fps, and no freezes at all.

I went back a bit in this discussion, and it is not new today. E.g. the same thing is happening on: http://www.babylonjs-playground.com/#2LFJES#3   (though, not quite as regular or distinctive there)

 

This is different to the Firefox differences from Chromium I've noticed on my own tests, where it is simply a lower FPS. Could it be a garbage-collection issue?

[jerome]

It smells like a GC collection issue, but I can't find it. I will check the CPU profiler.

However, I noticed the PG editor script has side effects on FF. I remarked that when I did the computeNormals() optimization... when you put the finger into mesh live updates, things don't get right in FF is the editor is running.

 

If I run the same example locally (outside the PG), I can't reproduce this FF behavior.

 

I will yet check the CPU profiler.

 

 

[EDIT] : tested... definetly not the GC.

[jerome]

Added tetrahedrons : http://www.babylonjs-playground.com/#2KSQ1R#10

 

line 45

 

I still notice this little lag in FF, don't get why

here is direct sample with more particles : http://jerome.bousquie.fr/BJS/SolidParticleSystem/solidparticles.html

 

 

@jahow : as explained in the doc https://github.com/BabylonJSX/SolidParticleSystem , you can now add your submesh_index property to every particle in the initParticles() function

[fenomas]

I still notice this little lag in FF, don't get why

here is direct sample with more particles : http://jerome.bousquie.fr/BJS/SolidParticleSystem/solidparticles.html

 

Short answer: profile in Chrome.  I mean we all have our favorite browsers for browsing but chrome's profiler is just light years beyond FF. Unless I'm missing something - would be happy to be wrong.

 

With that said, on my machine your demo above spends ~16% time in the GC. I'm no expert at memory debugging but it seems to create and destroy a lot of numbers. It seemed to be happening inside an object/function with an obfuscated name, so if you hunt for it try using debug builds of babylon.

 

Also it spends >30% in computeNormals. You might try doing that analytically - I imagine that the babylon builtin is more complicated than needed for this use case? I'd have thought you could just transform them exactly the way you're transforming positions (but I haven't looked closely..)

[fenomas]

By the way, I have been iterating on this too, in a much different direction. 

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

 

This is a much lighter, simpler version which just tries to emulate regular particles (except the blend mode and the compositing issues).

 

Note that it takes "capacity" and "rate" parameters, so as not to shoot out everything at the beginning. It's meant to billboard the particles, but that bit's broken, so that they rotate with camera angle. Need to dig into the matrixey stuff in the core loop and monkey with it.

 

On my machine it stress tests okay up to ~30k particles; past that the GC gets too heavy. I haven't looked at why yet, but if the GC can be resolved it should go a lot higher..