Why is getting my "SPS" cube holes when updating only part of it

hey guys,
i am relativly new to babylon.js.
i managed to create the transparent cube that i want which is made of transparent cubes itself. i want to change the color of one particle (one cube) at a time which kinda works…
because i needed faster FPS, i created it using solid particle system (SPS).
because even that had to be optimized i stumpled upon the option to update only part of the SPS system… (line 129)… the “setParticles” function allows parameters to only update part of it, shown here in the doc: Optimizing Solid Particle Systems | Babylon.js Documentation (“optimize a SPS”)

heres my demo: https://playground.babylonjs.com/#2V1C4Z#28

the problem is…: as i hope you can see, i get HOLES in my cube when using this “optimized update strategy”… and i don’t know why?

when i use the standard setParticles update function (line 130 as comment) everything works fine but i don’t get the performance boost that i want…

why is it not working, why do i get these HOLES ?


P.S.: please zoom a little bit out to see it…

Maybe @jerome will be able to help, but be patient as it holidays time.

At first sight, I don’t know why although I like this final unexpexted effect :smiley:
Each time that you call setParticles(), each particle updateFunction() is called and I can’t see it in your code (unless it’s wanted).
BTW, to improve perfs, don’t create a new Color3 object each frame per particle, just reuse it (or them). Only 3 or 4 global color objects shall be enough for the whole SPS.

I’ll keep digging…


Maybe the computation result of ii % nbBoxes isn’t always defined actually

1 Like

yes, sometimes this unexpected effect even results in something very symmetrical, but obviously i like to get rid of it… it’s still a mystery to me. isn’t the updateFunction you refering to called from within the babylon libary? you say you can’t see it in my code…

no, the “ii % nbBoxes” is probably not the cause of this, because if i just update let’s say particles 1 to 100 i get the same effect. ii is always defined and nbBoxes as well…

Ok gotcha :slight_smile:
It’s because of the enableDepthSort parameter. Here set to false (obviously the transparent rendering is now wrong) : https://playground.babylonjs.com/#2V1C4Z#32

The particle depth sort requires setParticles() to iterate over all the particles in order to sort their geometries according to their distances to the camera.
setParticles(i, j) limits the iterations in the loop only from the i-th to the j-th particle, so the depth sort can’t be completed.

So if you still want the depth sort for the transparency, you need to iterate over the whole SPS and then to call just setParticles() anyway.

This should be documented, I agree : depth sort simply requires setParticles().

1 Like

thanks a lot jerome, that makes it clear!!
sure, it has to be in the docs…
i guess i will iterate over the whole thing, i like the transparency effect too much. :wink:

if there is any other way i can optimize my demo for speed that comes to mind, let me know… i played a bit with instances but there were transparency issues…

It’s hard to optimize by reducing the total number of computations when enabling a depth sort. Indeed, depth sorting means computing each particle distance to the cam, then to sort the whole underlying indices buffer so that that the rendering process draws first the farthest particles before the closest.

Now, the thing that can be done is to reduce certain computations (skip the particle rotation and texture computations for instance).
Another approach would be to call setParticles() not every frame, but only when a particle color change is triggered or only when the cam moves. You’ll get a better fps rate then.

okay thanks a lot so far!

now the thing i want to do is not change the whole particle (box) color but only one face color of each particle (box). i think this can be done with changing the vertex buffer, but i dont know how. so how can this be done with code?