SPS and gryff - the end of the world as we know it?

[gryff]

Well, I took a couple of hours off yesterday - only some many hours you can wrap parcels - and finally decide to experiment with @jerome's SPS system. Here is the result:

SPS Test

I created a mesh in Blender - 10 quads - and used that to create an SPS by using the "SPS.digest" to convert the mesh into something usable . No movement just a static display. Now I can also just display the mesh without breaking it up. So my question is, "What is the benefit of using the SPS system - is it more efficient?"

And one point from the tutorial on SPS  The first line of the basic example should be :

var SPS = new BABYLON.SolidParticleSystem("SPS", scene);

not:

var SPS = new SolidParticleSystem("SPS", scene);

Error messages drove me batty for half an hour. Only when I looked a a PG did i see the issue.

cheers, gryff

[jerome]

Oopps, you're right, there's an error on this line of the tutorial, I'll fix it as soon as I come back to my office computer. Sorry for that and the time wasted ...

About your first question : the SPS can be seen, of course, as a solid particle system (what it is), but also as a kind of API to access a mesh subparts (its "particles") and to move, scale, rotate or color them individually.

Moreover, it's a simple way to merge different meshes into a single one to reduce the number of draw calls by just adding or digesting several models in the same SPS. You can even set each one its own "texture" (what is not possible with the standard mergeMeshes() function) : "concatenate" each image to be given to each subpart into a single texture image file and then set each texture subpart to each wanted subpart with the property particle.uvs, like you would do with a texture atlas.

So the known best uses for now of the SPS are :

- solid particles, of course, animated (http://jerome.bousquie.fr/BJS/demos/blow.html) or not (http://jerome.bousquie.fr/BJS/demos/solidparticlesAsteroid.html)

- kind of instances or merged meshes to depict in one draw call, say, buildings in the distance or even the player environment (example : a maze)

- rightly alpha sorted transparent 2D particles (the SPS was initially designed to solve this problem)

- some mix of all the former arguments... or your own new ideas 

 

For instance, this (not completed) game prototype http://jerome.bousquie.fr/BJS/Starfighter/ is done with many SPS. Actually everything is a SPS in this scene except the cannons what are 4 tube instances, the cockpit what is a marged mesh and the sight what is a simple textured transparent quad.

Each ennemy vessel is a SPS like you would do by digesting a Blender model.

Each laser that you fire is a scaled and rotated particle (a triangle) from a little SPS just a dozen of particles.

Each star, each laser light in the distance once your laser flies far away, each ennemy laser cross, each laser impact on some ennemy and each ennemy explosion are all a particle of the same SPS : so one draw call for stars, ennemy lasers, impacts, explosions, etc. 

 

[EDIT ] You tittle made me laugh a lot 

[gryff]

@jerome: and the starfighter game looks good . Not sure what a high score is - I got 1000 and died. Not a great player of shooter games

The only reason I mentioned the tutorial was to save others the problem. Not being the best javascript coder and only a two finger typist, I tend to use copy and paste a lot . But of course anything from a typo to a simple error can cause grief - one of the natural hazards of copy/paste. Not a big deal - I read the doc more thoroughly. And of course it shows the benefits of the PG  

Quote

some mix of all the former arguments... or your own new ideas

And that is basically the reason I took a look at SPS triggered  by my the redo of my Xmas Village. I wondered if all the trees on the periphery (basically crossed planes) could be done with SPS with billboards. So looking at SPS was motivated in how I could possibly improve things - a reason not to procrastinate anymore.

Here is what I have so far:

Trees

The billboarding is behaving oddly - each quad (with one tree)  is, of course, two triangles and they seem to be splitting up as the camera moves.

I've seen examples with box meshes that seem to work - so maybe it is my code

Any thoughts most welcome.

Ohh and the "SPS.digest((...))" brings a smile to my face. I have this thought of someone sitting at a desk eating from a package of "Jerome's Low Calorie Vertices"

cheers, gryff

[jerome]

about the billboard mode, it seems the expected behavior : it rotates the trees (quads) along all axis to keep them in front of the cam... not sure, it's what you need here, because I suppose you want a Y axis only rotation

[Wingnut]

Hey Gryff and others... mind if I take you on a little tour? I knew ya didn't mind.

There are two functions in standard particle systems... that are user-hacked most often.

updateFunction() and startPositionFunction()

Let's see them in action...

http://www.babylonjs-playground.com/#1CMD3G#18

Lines 12-40 - my custom update function, called with the entire particle "pool" as its parameter.  It has a FOR-loop to iterate thru all particles.

Lines 41-130 - my custom start position function... called on a single NEWLY-DISPLAYED particle, to determine where to initially place it.  No need for a FOR-loop.

The updater func is "wedged-into" the particleSystem at line 136.  The positioner func is wedged-in at line 139.

The default update function usually does lots of things.  It checks particle.age to see if it is time to recycle the particle. It moves the particle, taking gravity and direction settings into consideration.  It uses particle.age to determine which color phase the particle is at... color1, color2, or colorDead.  It also spins the particle on its z-axis, per angularSpeed setting.

Lines 15-21 of myUpdateFunction generally checks if its time to recycle the particle.  If not, it runs the second part of the func. 

The 2nd part really does only 3 custom things - line 26, 27, and 28.  Line 26 makes the particle color be a random color4, line 27 sets a random particle size 0-2... and line 28 turns off the z-rotation... no need.  I could have set ps.angularSpeed = 0, too.  Same affect as remarking-out line 28.  Change the '2' in line 27... to '5'... for easy first-time hacking.  

Needless to say, a particle system's update function... is a fun place to play with things.  It's how I cause "sparticles" (sparkly particles). 

As for myStartPositionFunction, I think you can see what it does PER PARTICLE.  It sets the ps.emitter to a new emitter position... for each new particle.  You can think of it as a "distributor", or card dealer.  I think you can intuitively understand what is happening in that func.

NOW... for SPS.  It does not use an identical system for ITS startPosition and update, but it has just as much power, and likely more. We have all seen SPS particles positioned as city buildings, or as asteroid fields, or as tinsel blades (one of my FIRST EVER uses of SPS - only 2 days ago, so you and I are on the same SPS learning pace, Gryff).

No startPosition function in the tinsel/garland demo above, but the code in lines 55-71 iterates thru all sps.particles, positioning and orienting the entire sps.particles pool.  Gryff, when you look at this garland and its "needles", does it make you think about building pine boughs out of many "clustered pine needles"?  I bet so.  You're thinking well.  Your current project is only about half-way to true SPS hell - using SPS for each pine needle.  Tumor-causing thought, huh?  You will need a "recursive" needle-positioning func from hell... in a programming structure that is sometimes called "tree-walking" or similar.  I wonder where they came-up-with THAT name?    Are you ready to "grow" some SPS pines, Baron von Gryffenstein?  Remember "outlines" from school days?  Main trunk, then a branch, with sub-branches, that have sub-branches, that have sub-branches, that have needles.    Arrays of arrays of arrays of arrays of data-needles. 

Using the tinsel/garland as an example, there's no update() function involved, right?  (well there IS, lines 76-84), but it does nothing at all, except use-up valuable PG space.  This PG is work-in-progress, full of messy things, yet. 

For the tinsel... no animation, no movement, no color changes, no gravity affect, and no need to recycle particles.  No need for updating at all.  But this is true for my simple SPS PG. 

For PG demos like this one, the SPS has an updater FROM HELL.    (lines 68-84).  That author also has a start position function at lines 37-55, but it is MORE than JUST a start positioner.  It is a set_All_Sorts_Of_Initialization_Crap() function. 

Here is the section of SPS docs that talks about these initialization and updater funcs.  Gryff, you might not be needing start-positioner and particle updater funcs quite yet, but I wanted to tell you that these two "actions" are at the heart of all particle systems.  1. Put the particle on screen in some kind of initialized "state" (sometimes positioning it at the location of the emitter), and 2.  What to do for each step of the particle's lifetime (move it, color it, size it, etc).

So, from now forward, every time you hear "particles", you will also think about startPositions (startConditions) and updating (what to do to each particle per particleSystem "step").

Those are "The Big Two" most-popular hack-able functions of particle systems.  Want another demo?  Okay.

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

A VERY powerful Cartesian mess for the startPosition function with lots of helper funcs (makes the sphere-o-particles)... and an updater function that does very little, if anything at all.  If we pasted-in the updater from the sparticles demo, things could get fun! 

Ok, that's enough particle yapping for a single post.  I'm quite far off-topic, sorry... but... I thought you should know about The Big Two, if you didn't already know about them.    And, I get to practice my doc-writing skills.    I think I am still too blabby.  I could probably replace 3/4 of these words... with a diagram or two.  I wish I liked making diagrams.

By the way, scene.clearColor only accepts color4 these days.  This will break a LOT of scenes.  No info in the stale What's New.  Bug?  Intentional?  Anyone know?  thx.