Search the Community

Hi, People usually love the Solid Particle System (aka SPS). Some of them sometimes ask for new features like the ability to extend it once created (coming soon) or for some extra speed by the ability to disable some computations. I made some study about how things could get faster. The short answer is : go to a lower lever in the implementation (replace the arrays of objects by typed arrays of floats, for instance), then use if possible other processes (GPU or workers). Well, here are the current status of my prototypes, so you can compare on your computer and browser the differences. The SPS of reference is really big, filled with 40K (yes, 40, 000 !) boxes and tetrahedrons. It's far more than we usually ask to a SPS with animated solid particles in the PG examples you could find in the forum posts. So your browser may suffer a bit ... Reference legacy SPS : http://jerome.bousquie.fr/BJS/test/spsReference.html Then comes the lighter typed array based version : http://jerome.bousquie.fr/BJS/test/spsBuffer.html As you can notice, it's a bit faster. Not only because of the usage of buffers/typed arrays, but also because it has less features than the legacy SPS for now. Let's go on... [EDIT] (from here, your need to have a browser with sharedArrayBuffer enabled) Here comes his new friend, the worker based SPS : http://jerome.bousquie.fr/BJS/test/spsProtoWorker.html This one is really faster. In this version, the particle logic (what the user want them to do) is still in the main thread and the worker only computes the transformations (the final vertex coordinates from the particle rotations, positions, scaling values, etc). At last, here's the second worker version : http://jerome.bousquie.fr/BJS/test/spsProtoWorker2.html It looks faster ... at least on my browsers. In this last version, the particle logic is deported in the worker. The main thread only carries for updating the mesh from the vertex buffers. In both worker versions, the worker computations are decoupled from the render loop. This means that the worker computes, then answers the main thread it has finished and this one just orders it to compute again, whatever the render loop is currently doing at this moment. The render loop just reads the data currently updated by the worker in a shared buffer (shared between the worker and the main thread) Next study step to come (not soon) : the GPU based SPS Please wait for a while until the frame counter stabilizes to the current average value if you run the tests.

Hi people, The Solid Particle System, also know as SPS, is nearly ready in the core... just waiting for PR now. It is a port from the BJSX experimental version. Some things have changed : 1 ) There are no longer any shape dedicated methods like addTriangles(), addQuads(), addTetrahedrons(), etc. Now you just create a classical BJS mesh with CreateXXX() methods or import it and then you add it to the SPS. var torus = BABYLON.Mesh.CreateTorus("t", {}, scene);var sps = new BABYLON.SolidParticleSystem("sps", scene);sps.addShape(torus, 50); // adds 50 torus particlesvar spsMesh = sps.buildMesh(); // build the SPS meshtorus.dispose();the same for any wanted shape. 2 ) Each particle is now double linked to its previous and next ones var next = particle.next;var prev = particle.previous;This can be useful to manage particles one by one : recycling, etc 3 ) setParticles(), beforeUpdateParticles() and afterUpdateParticles() have now three optional parameters start : start index to start iterating over the particles (default = 0)end : end index to stop iterating over the particles (default = nbParticles - 1)update : boolean, if the mesh must be updated (default = true)This is useful if you call setParticles() , or also the two others functions, each frame but you don't want, for performance reasons, to compute everything for all the particles at once or you don't want to update the mesh (VBO) each frame. Example : you have, say, 30K particles. frame 1 : compute positions for particles from 0 to 9999, don't update the mesh frame 2 : compute positions for particles from 10000 to 19999, don't update the mesh frame 3 : compute positions for particles from 20000 to 29999 and update the mesh The documentation is also already started in the documentation github repo here : https://github.com/BabylonJS/Documentation/tree/master/content/tutorials/03_Advanced (PR awating)

Hello All, Is it possible to use the EdgesRenderer with the Solid Particle System? I cannot get it to work with a simple box. I'm able to create a box with edges, and a SPS with lots of boxes, but not both at the same time. Any pointers would be appreciated. Here is a small section of my code. The boxes show but without any edges. var box = BABYLON.MeshBuilder.CreateBox("b", options, scene); box.enableEdgesRendering(); box.edgesWidth = 10.0; box.edgesColor = new BABYLON.Color4(0, 0, 1, 1); var mat = new BABYLON.StandardMaterial("mat1", scene); box.material = mat; // SPS creation ========================================================== var sps = new BABYLON.SolidParticleSystem("sps1", scene); sps.addShape(box, nb); box.dispose();

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