Bad lag (~200ms and increasing) in PushMaterial

[bnolan]

Heya - has anyone come across a problem that as your scene grows (cryptovoxels is loaded as you explore the world), PushMaterial starts taking an inordinate amount of time?

I’ve been digging into PushMaterial#constructor and Material#constructor and can’t see anything in there that would take so much time - am I missing something?

We’re using our own material class like this:

const material = new BoundMaterial('feature/image', this.scene)
material.bindMesh(this.mesh)
material.diffuseTexture = texture
material.alpha = 0.999
material.specularColor.set(0, 0, 0)
material.emissiveColor.set(1, 1, 1)

And BoundMaterial is:

export default class BoundMaterial extends BABYLON.StandardMaterial {

  boundMesh: BABYLON.Mesh

  bindMesh (mesh) {
    this.boundMesh = mesh
  }

  markDirty (...args) {
    if (this.boundMesh) {
      return
    }
  }

  markAsDirty (...args) {
    if (this.boundMesh) {
      return
    }
  }
}

[Evgeni_Popov]

We would need to know which part of PushMaterial is taking time. A repro would probably help in that matter too.

[sebavan]

I wonder if it is because it flags everything as dirty during each material creation introducing latency as we fixed for gltf loading.

The repro would definitely help ensuring this and addressing it.

[bnolan]

Ok, I created this playground and it doesn’t seem to replicate the lag we’re getting…

https://www.babylonjs-playground.com/#1A8B4B#3

Doing a bit more investigation.

[bnolan]

Man this lag is crazy. I’ll update once I work out how to fix it.

[sebavan]

yup definitely need to understand what is taking so long there, keep us posted !!!

[bnolan]

Ok - I have NFI where this while loop is coming from, I can’t see it in the babylon.max.js, but there it is…

[bnolan]

Ok - worked out how to fix it. We’re not using getMaterialById anywhere else, so we can just nerf it.

ganymede:cryptovoxels$ git show 6419aae5dd4e141197a4798d3a44c972c2b42900

    Nerf scene.getMaterialById

diff --git a/src/lib/bound-material.ts b/src/lib/bound-material.ts
index 14788966..b43983a2 100644
--- a/src/lib/bound-material.ts
+++ b/src/lib/bound-material.ts
@@ -1,6 +1,13 @@
 // YOLO DIRTY HACKS FITE ME
 export default class BoundMaterial extends BABYLON.StandardMaterial {
 
+  constructor (name, scene) {
+    // FITE ME
+    scene.getMaterialByID = () => {}
+
+    super(name, scene)
+  }
+

Yes - cryptovoxels is dirty hacks on top of dirty hacks. It’s basically a pile of hacks all the way down.

[sebavan]

Would all your materials have the same name by any chances forcing to over all the mat on every creation ?

In this case simply create unique name for the materials ?

[Evgeni_Popov]

The thing is that getMaterialByID is looping over all existing materials in the scene until a match is found, if any. So there is always at least a full loop done over the existing materials when creating a new material. Maybe we should add a parameter to the Material constructor to allow disabling this loop? It was added some weeks ago to be sure to have unique material ids, but if people don’t want that / know they have unique ids in the first place they could save some performances.

[bnolan]

Yes we have tonnes of materials with the same name.

I guess it’s o(n^2) complexity to find a unique material name where n is number of same named materials?

[sebavan]

Yup agree @Evgeni_Popov we should allow a way to by pass this for perfs could you take care of it ?

[sebavan]

@bnolan you wont need your dirty hack in a bit just seen your twit

[Evgeni_Popov]

PR is created:

Add enforceUniqueId parameter to material constructor

[sebavan]

Will be in on Monday at max Thanks a ton for the PR

[sebavan]

We will actually use a more global approach to prevent the incurred lag Rework #9290 due to perf hit by sebavan · Pull Request #9492 · BabylonJS/Babylon.js · GitHub

You ll be able to have it in the next nightly in about one hour @bnolan