SPS freezing on updates

Questions
1

Hey, I have a doubt about my implementation on the SPS in my game.

The problem:

I have a scene, X,Y,Z with blocks.
Client asks Server for chunks (16x16) as they move around the world.
User freezes a second each time a new chunk is built or modified.
Users need to be able to place and remove blocks.

  • I use only one material, is an atlas with a bunch of 32x32 pixels textures.
  • I decided each chunk to have its own SPS, to avoid rebuilding the entire world mesh on each chunk update. (not sure if ok)

Chunk.SPS:

this._SPS = new SolidParticleSystem(
`sps_${x}_${z}`, this._scene, {
  isPickable: true,
  expandable: true,
  updatable: true
});

material.diffuseTexture = textureAtlas;
SPS.mesh.material = material;

Chunk.Blocks

For each Block in Chunk.blocks, I create a disposable box.

const opts = { faceUV: [Vector4, Vector4, Vector4...])
const box = MeshBuilder.CreateBox(`box`, opts, this.scene);
this.chunk._SPS.addShape(box, 1);
box.dispose();

then I build the mesh once:

this.chunk._SPS.buildMesh();

Is it normal for the scene to freeze entirely during the built?
I dont see it to be happening in this PG here, they all continue to spin.

Is not that the building of the chunk is taking too long, it seems reasonable but id expect the user to be responsive in the meanwhile.

Can’t reproduce in PG, is it a loop-related-thing I ignore?

Thank you.

Edit to add video evidence:

Basically you stop for a second every time you walk over a chunk limit, which is annoyingly noticeable.

(You may recognize a model from orion3dgames/t5c as I needed a quick boilerplate)

2

You need one box only and call addShape(box, 16 * 16). Create a tile texture. Assign texture to SPS mesh. Assign correct UVs.

Why do you even need a box here? Use a plane.

See this example:

Regarding your tiling system:
You should prerender tiles in the direction the player is moving. I would opt for a plane with 16 segments, you don’t need SPS. One tile texture. Correct UVs.

3

Hi Roland,

Please ignore the current flatness of the word. The key is in this part:

Users need to be able to place and remove blocks.

I see that particle.uvs expects a Vector4, not an array of UV faces. That’s why I was creating each box individually, to make use of the faceUV property.

Do you know a way to change UVs per face in a particle?
I can, as you say, build the “block” using 6 plane particles, one Vector4 each.

Some walls for better example (top and side uvs are different)
image

4

Each is a Vector4(u1, v1, u2, v2) so it defines an UV area. So if you’ll have a tile texture with 4 tiles each covering 1/4 of the texture and the layout is 2x2 you’ll end up with UVs:
tile1 - (0,0, 0.5,0.5)
tile2 - (0.5,0, 1,0.5)
tile3 - (0,0.5, 0.5,1)
tile4 - (0.5,0.5, 1,1)

if the texture layout is 4x1:
(0,0, 0.25,1)
(0.25,0, 0.5,1)
(0.5,0, 0.75,1)
(0.75,0, 1,1)

1 Like
5

Hi,
Adding or removing solid particles from a SPS is quite expensive as its whole geometry and all its vertex buffers are rebuilt from scratch (and this adds also more work to the GC to sweep the former geometry and buffers, so a lot of data).
If you have to regurlary add and remove some particles, knowing in advance their shapes, maybe a good solution would be to create a pool of some extra solid particles with the right geometry, then set them as invisible/disabled (so they aren’t computed at all) and use or recycle them when needed.

In this very old example StarFighter there’s a constant number of : gliding stars, purple laser impacts, fading out in the distance purple laser dots, orange enemy cross fires and cannons blue laser lines… in a single SPS.
Everything is set in a pool, say, max 10 simultaneous laser lines, 60 enemy cross fires, 30 dots in the distance, 20 impacts, 60 gliding stars, etc because all their geometry are know in advance.
Even if each frame, only 45 stars are displayed because noone shoots at all.
Everything is enabled when needed, then recycled in the pool.

The same for this old example : Test Babylon SP Terrain
The logical terrain is huge but a recycled SPS is used to display on each known position the right solid particles with the right (know in advance) shape. Nothing is added nor removed. The SPS is just a pool of a certain number of expected shapes, enough of each kind to be seen in a single frame.

Hope this could be helpful :wink:

3 Likes
6

:heart_eyes_cat: :heart_eyes_cat: :heart_eyes_cat:

Maybe thin instances pool can be more convenient to handle.

A long time ago a created this, it’s reusing thin instances:

1 Like
7

Both have their pros and cons depending on your needs.
And thin instances are really cool.

1 Like
8

< unrelated> @jerome so cool to see you here !!! < /unrelated>

1 Like
9

thanks buddy :wink:

1 Like
10

Can’t agree more :slight_smile:

1 Like