Three.js: vertex cache optimisation

[makc]

just leaving this here in case someone will be inspired to create geometry util for this:

When rendering each triangle, the vertices it uses must be processed (for example, transformed to screen space and lit in various ways) before rendering. Indexed rendering hardware typically uses a small cache of vertices to avoid re-processing vertices that are shared between recently-rendered triangles. Using a moderately-sized cache (anywhere between 12 and 24 vertices is common) reduces the load on the vertex processing pipeline far more than the older non-indexed strips and fans model – often halving the amount of work required per triangle.
However, the vertex cache relies on the ordering of the triangles to be optimised for its characteristics. If the triangles are sent in a random order, the vertices almost always miss the cache and there is no benefit obtained. If triangles are sent in clusters so that each triangle is close to previously-rendered triangles, it is more likely that more of its vertices are still in the cache.

text
code

[bhouston]

ThreeJS does not generally use indexed vertices. I haven't found ThreeJS to be vertex limited, it is nearly always fragment shader limited, especially on mobile. The reason why ThreeJS isn't generally vertex limited is that no one wants to download large meshes that have a lot of vertices and also because WebGL doesn't have a geometry shader yet that can increase the number of vertices.

So I haven't seen this as an issue yet.

[mrdoob]

I heard that nowadays drivers convert indexed geometries to non-indexed geometries anyway. That article is from 2006...

[SuberFu]

@mrdoob I think it's now called Post Transform Cache.
It does look like there may be some benefit. However, as @bhouston said, the bottleneck is likely in the fragment shader. Furthermore, the additional processing needed to "optimize" the vertices in javascript may outweigh whatever performance gain you get through vertex caching.

Although it would be an interesting exercise for those inclined. Creating a new THREE.BufferGeometry derived object that convert it's internal indices to optimize cache.

[makc]

Furthermore, the additional processing needed to "optimize" the vertices in javascript may outweigh whatever performance gain you get through vertex caching.

not saying this should be done to everything that goes throuhg three.js, but an utility method to run over the output of parsers / loaders would be nice

[bhouston]

Creating a new THREE.BufferGeometry derived object that convert it's internal indices to optimize cache.

Many game engines do this. Although generally you want to optimize prior while serving your assets over the web, not during run-time loading. Indexed geometry is generally smaller to download too, especially if it is in OpenCTM-like formats.

[pailhead]

This could definitely reduce the size of the meshes. Instead of going from indexed to triangle soup, you just use indexed. Should be pre-processed.

[brianchirls]

According to the OpenGL ES Programming Guide for iOS, updated in December 2015, this is still a thing.

Where possible, sort vertex and index data so triangles that share common vertices are drawn reasonably close to each other in the triangle strip. Graphics hardware often caches recent vertex calculations to avoid recalculating a vertex.

But I'd love to see a real benchmark if someone feels motivated to put one together...especially on mobile.