Public enemy #1, engine.createIndexBuffer()

[JCPalmer]

I have been generating in-line JS code for my geometry from Blender, and running it from my local machine (fast and has 32 bit indexes).  It did not feel like it was near fast enough.  A mere 242k worth of positions / normals / uvs / indices / sk weight / sk indices was taking 1.9 seconds. 

This is across 6 meshes, though this one is the biggest by far, and all others are children. ( I backed down the influencers to 4 to avoid extra weights & indices, but did not help):

num positions      :  13656
num normals        :  13656
num uvs            :  27312
num uvs2           :  0
num colors         :  0
num indices        :  65832
Skeleton stats:  
	WARNING: Maximum # of influencers exceeded for 897 vertices, extras ignored
	Total Influencers:  24129
	Avg # of influencers per vertex:  1.7669
	Highest # of influencers observed:  6, num vertices with this:  36
	exported as 4 influencers
	num skeletonWeights and skeletonIndices:  54624

Since I am generating source code, it is not quite as pesky to put in a massing amount of timings / loggings.  I thought it was going to show everything was just sluggish & nothing you could do about it,  but I was fuckin' wrong!!!!!!  Here are the 5 child messes.  They are basically nothing, but indexes are taking up an undo amount of that nothing:

	positions: 0.007 secs
	indexes: 0.036 secs
	normals: 0.001 secs
	uvs: 0.000 secs
	sk weights: 0.001 secs
	sk ixds: 0.000 secs
defined mesh: Jogger.Female_runner_Shoes06 completed:  0.06, geometry:  0.05 secs

	positions: 0.001 secs
	indexes: 0.005 secs
	normals: 0.000 secs
	uvs: 0.000 secs
	sk weights: 0.000 secs
	sk ixds: 0.000 secs
defined mesh: Jogger.Female_runner_Eyelashes02 completed:  0.01, geometry:  0.01 secs

	positions: 0.000 secs
	indexes: 0.003 secs
	normals: 0.000 secs
	uvs: 0.000 secs
	sk weights: 0.000 secs
	sk ixds: 0.000 secs
defined mesh: Jogger.Female_runner_Eyebrow001 completed:  0.01, geometry:  0.01 secs

	positions: 0.001 secs
	indexes: 0.002 secs
	normals: 0.000 secs
	uvs: 0.000 secs
	sk weights: 0.000 secs
	sk ixds: 0.000 secs
defined mesh: Jogger.Female_runner_Low_poly completed:  0.01, geometry:  0.01 secs

	positions: 0.006 secs
	indexes: 0.151 secs
	normals: 0.001 secs
	uvs: 0.001 secs
	sk weights: 0.001 secs
	sk ixds: 0.001 secs
defined mesh: Jogger.Female_runner_Braid01 completed:  0.17, geometry:  0.17 secs

The big mesh, stats shown above, took 1.573 of the 1.59 sec for geometry.  FYI, total time for the parent mesh, 1.90, includes children & other overheadI did not break out).

	positions: 0.007 secs
	indexes: 1.573 secs
	normals: 0.003 secs
	uvs: 0.001 secs
	sk weights: 0.003 secs
	sk ixds: 0.002 secs
defined mesh: Jogger completed:  1.90, geometry:  1.59 secs
Texture Load delay:  2.60 secs

Once I knew it indexes, I starting digging into the source code.  I noticed you could also pass a Uint32, so I tried that.  It cause a massive increase in time!!!

	positions: 0.009 secs
	indexes: 3.817 secs
	normals: 0.003 secs
	uvs: 0.001 secs
	sk weights: 0.003 secs
	sk ixds: 0.002 secs
defined mesh: Jogger completed:  4.17, geometry:  3.84 secs

I am done for the day, so this primarily a note myself to pick up tomorrow.  I probably need to put tracking in Engine.createIndexBuffer itself to really isolate.  @Deltakosh, any thoughts?

[JCPalmer]

With fresh eyes, I narrowed the problem to outside Engine.  QI.Mesh overrides setIndices to perform additional processing.  I put a log of just the super call:

/** 
 * @override
 * wrappered so this._vertexMemberOfFaces can be built after super.setIndices() called
 */
public setIndices(indices: number[]): void {
    var sup = BABYLON.Tools.Now;
    super.setIndices(indices);
    sup = (BABYLON.Tools.Now - sup) / 1000;
    console.log("super setIndices: " + sup.toFixed(3));

    // my processing to get list of faces to avoid calc'ing normals 
    // for entire mesh when a shapekey is only part of a mesh
    ...
}

        positions: 0.006 secs
super setIndices: 0.002
        indexes: 1.582 secs
        normals: 0.003 secs
        uvs: 0.001 secs
        sk weights: 0.003 secs
        sk ixds: 0.002 secs
defined mesh: Jogger completed:  1.92, geometry:  1.60 secs

I am pleased the fixes are outside Engine.  I can stay with 2.4, and potentially move this processing into python, or even determine just calculating normals for the entire mesh is too small a gain to worry about.  Am in the final pre-game performance tune up.

Sorry, if I got peoples hopes up of cutting time out of their loads.

[GameMonetize]

I'm not sure to follow. What do you suggest? using int32 for indices loading?

[JCPalmer]

I fixed it my code!  I switched to using the BJS VertexData.ComputeNormals of the entire mesh, and grabbed the stuff I needed.  Now I do not need to do all this extra stuff in my override of setIndices.  Dumped a lot of arcane code too.

Instancing the same Jogger mesh is now very fast.  Down from 1.92 seconds to 0.14 seconds.  Geometry went from 1.6 to 0.02 seconds.  The textures delay the mesh from actually displaying in 0.66 seconds though.

Using my version of computing normals comes from a time where the BJS version was much slower.  @jerome, took away that advantage.  I was also computing normals for the parts of the mesh that morphed every frame.  Now I just do it once I know the end point & interpolate it just like the positions.