SPS too awesome to be true

Questions
1

Hello guys, I am considering to rewrite my game to use SPS extensively.

From performance point of view I was at the end of my abilities three days ago. I did

  • Reused meshes (disabled when hidden, enabled when needed again)
  • Merge what doesnt move
  • Used instances for whatever was moving (problem with light.includedOnlyMeshes there)
  • Frozen world matrices
  • Frozen active meshes only to unfreeze once every 30 frames for recount - this one provides BIG improvement and maybe deserve more publicity !

I have to say that with above setup I was pretty much ok even on my Galaxy S7 - UNTIL (sadly) I have added more moving objects (monsters). When I have done this, then I felt that even with all that optimizations I have seen lowered FPS soon on my phone.

I said myself ok, probably thats just the limit, until I found SOLID PARTICLE SYSTEM.

At first - I tried to use it for my tile-based terrain. Whole background terrain is just one mesh with texture atlas and it works like a charm - one draw call (before it was like 10 - 20 draw calls) and you are done baby.

It seems to be so powerfull that I am considering to use SPS for my objects too (trees, bushes, fences) basically all that are expected to be in 10+ entities (instances for those that arent expected to be repeated too much).

I will end with one SPS for every “object type” with possibility to even merge more object types into one SPS later (objects of same material).

I am considering to use SPS even for monsters (one SPS per monster type or per monster - not sure yet).

And that leads to my humble question - this will take a lot of effort and I am afraid that there will come some problem that will ruin it all :smiley: Is there some disadvantage of SPS that is not clear at the first look ?

I think that I might end with like 50 SPS objects when full scene (objects, monsters, players) - it is just 50 draw calls which is something that I cannot achieve “standard” way.

What I am afraid of:

  • Shadows - my SPSes will be big meshes (boundary wise) with lot of empty space inside and I am afraid that it could cause trouble on generation of shadows (although by this time I have seen that the gibber object, the more precise shadow).

  • That SPSes will have like 50 - 100 particles but those could be spread well over screen thus most of these SPSes will be “big meshes” at the end (even with lot of empty space inside them). Which could lead to some trouble maybe.

  • I am not sure about overhead of SPS in comparison with normal mesh. Will be lets say 30 - 50 SPSes manageable or is there something to be concerned with ? Worth to mention that most of SPSes will be static objects that would not be updated often.

  • I cannot add new shape into existing mesh (is this still the case ?) which means that I will need to add enough particles at the start (it will be at least 50 - 100 for each SPS but lot of then will be alive = false most of the time)

  • As most of my scene would be consisted of large SPSes (large by boundary size, not complexity) I am afraid that it may cuase some problem for lights (I am using one spot and 3 - 8 point lights usually) - but maybe it is just about complexity of mesh and not about its absolute size, I am not sure here.

  • Something that I cannot even imagine

If none of these aforementioned aspects will cause serious trouble, then it is awesome and SPS will just save the world, but when something is THAT GOOD, I am always little bit nervous :slight_smile:

Thanx everyone for some insight into this !!!

And thanx again to those who invented this brilliant SPS object !

1 Like
2

Let me summon the creator of the SPS: @jerome

(and btw thanks for the kind words)

1 Like
3

Short answer : yes, SPS is pure magic. :blush: just kidding, of course.

That said, the SPS can bring lots of performance gain because it lowers a lot the draw call number what can often be (actually, what often is) the bottleneck.
For instance, this project (not sure it’s still online) Creating a city building simulator - Demos and Projects - HTML5 Game Devs Forum went to work properly with the help of the SPS.

As you understood it, each SPS is a standard mesh, updatable or not. It has no better nor lesser performance than another mesh. The SPS is just a layer of features to build, then to dynamically modify the mesh subparts that we call here “solid particles”.
So regarding the light, the shadows, etc, it strictly behaves like any other mesh.

When updated each frame for instance, the SPS performance is directly related to the global number of vertices, not the number of particles. Updating 5,000 boxes maybe way faster than updating 500 high poly particles like the skull mesh used in the BJS playground examples.
Note : the expandable SPS is not yet implemented, on my to-do list for long now :frowning:

Having 50 SPS rather than 5 is just like having 50 meshes rather than 5.

If you really want to push the optimization to the limits regarding the SPS, you could :

  • make a single immutable SPS containing all your immobile objects, whatever their shapes (model) or types, sizes, colors, textures as long as they use the same material. Refresh the size and the bounding box once after creation, freeze the WM and that’s it. One draw call for everything static in the scene for ever. You can compare with several meshes that are culled to choose the right solution for you.

  • make the less possible SPS for moving objects. Grouping them by types is a solution : it’s easier to code and to maintain. But it’s not the only one : you can choose the put different object types in the SPS, even if they have nothing to do with each others, but just because either they have similar behavior, either share the same material, either … what seems better to you.
    Example : StarFighter
    In this game, the starship lasers (blue balls near the cannons and sharp blue lights), the enemy lasers (red crosses), the blue laser impacts on the enemies, the laser ball lights in the distance, the enemy explosion lights and the animated stars are all in a single SPS !
    Each enemy vessel is also a SPS so it can explode in tiny subparts.

Well, there are plenty ways of doing to achieve the best result for you.
I understand that you wonder if it’s worth it to port everything you’ve already done so far to the SPS (although I would bet on it) because it’s a huge and deep refactor.
So I suggest that you build a simpler prototype scene from scratch with the same scale than what you intend to implement : say, put 500 boxes of different sizes, colors, textures at different positions (something looking like your final scene) in a single immutable SPS then put, say, 50 spheres, 100 boxes or higher poly polyhedra (well choose your model according to their similarity in term of vertex number with your own models : monsters, etc), etc.
Well, just create a simpler SPS-based scene with almost the same number of objects and vertices than your project scene. Don’t care about the animation logic, it will have the same cost, SPS or not.
Add the lights, the shadows, move the cam, explore your scene and just check if it’s worth it :slight_smile:

6 Likes
4

3DMAX exports a door model, which is composed of many sub grids and has animation. How to create SPS more simply? I’ve seen a lot of demos, which are created in a single mesh.

5

Ping @jerome which might be in vacation at the moment so please allow a bit of time for the answer :slight_smile:

6

I’m not sure to understand what you mean by “How to create SPS more simply?”

1 Like
7

For example, a door has many sub mesh and its door opening animation. There are 5000 doors in the scene. How can I implement a good FPS with SPS? It seems that the translation is not good, and I can’t express it clearly

8

there’s no animation support as per se in the SPS, everyone has to implement his own behavior…
Don’t you have a simple example (maybe not from a 3DSMax model, maybe something simpler but looking the same) that you could show in the playground so we could see what could be done ?

9

I am not sure that I understand Zhang´ need well but I suppose that he has “door” that are composed of several submeshes (sections of the door). He wants each section of the door to be one particle of SPS but he need to open the door and he doest know how to keep particles “connected to each other” in the process of opening ?

Maybe particle parenting could be usefull here - just to make one particle as the controller of the door and all other particles of that same door would have this controller as their parent.

https://doc.babylonjs.com/how_to/solid_particles#particle-parenting

If there is bone animation (door somehow bent during opening) then there would be different approach but also possible (I have tried something similar several days ago).

10

yep, parenting seems the way to go if the need is the one described