GLTFLoader: Don't duplicate vertex buffers when loading triangle fans and strips

[ericman314]

GLTFLoader: Don't duplicate vertex buffers when loading triangle fans and strips

[takahirox]

I would like to try shared WebGL buffers (shared attributes) first. Shared Interleaved buffers would be based on it even if we would support shared interleaved buffers with different parameters.

[takahirox]

I think it's nice if attribute (= WebGL buffer) can be shared among geometries. I don't really remember but like according to the codes below, currently attributes are not allowed to be shared among geometries, are they?

three.js/src/renderers/webgl/WebGLAttributes.js

Lines 130 to 144 in 07ec4e8

	function remove( attribute ) {
	if ( attribute.isInterleavedBufferAttribute ) attribute = attribute.data;
	const data = buffers.get( attribute );
	if ( data ) {
	gl.deleteBuffer( data.buffer );
	buffers.delete( attribute );
	}
	}

three.js/src/renderers/webgl/WebGLGeometries.js

Lines 9 to 36 in 39305cf

	function onGeometryDispose( event ) {
	const geometry = event.target;
	if ( geometry.index !== null ) {
	attributes.remove( geometry.index );
	}
	for ( const name in geometry.attributes ) {
	attributes.remove( geometry.attributes[ name ] );
	}
	for ( const name in geometry.morphAttributes ) {
	const array = geometry.morphAttributes[ name ];
	for ( let i = 0, l = array.length; i < l; i ++ ) {
	attributes.remove( array[ i ] );
	}
	}

In #17089 we were thinking of shared buffers with different parameters and the change became complex. But, I haven't deeply thought yet, can't just shared attributes (so same parameters) be implemented much easier with reference counter without API change and be good start?

Perhaps I guess we don't really want to make an effort for WebGL right now because we want to spend more time for WebGPU (this is just my guess) but small changes would be acceptable?

Any thoughts on WebGL shared buffer support? @mrdoob @Mugen87 @donmccurdy I'm willing to work on it and fix this issue if it sounds good.

[donmccurdy]

I've added some debugging output to glTF Transform, to calculate the effective "vertex count" in a few different ways:

gltf-transform inspect oval.gltf --format md

render	render-optimistic	upload	upload-optimistic
73,166	64,407	386,437,472	38,924

See definitions for each vertex count method. The "upload" vertex count is what we upload to the GPU today, to my understanding. And "upload-optimistic" is what could be uploaded ideally, either by attribute or by interleaved buffer.

Big difference on this model – 386,437,472 vertices if we upload attributes per-geometry (current), only 38,924 if we upload attributes individually or per by interleaved buffer. Lot of draw calls either way. :)

... can't just shared attributes (so same parameters) be implemented much easier ...

Perhaps! I'm not sure how simple this is compared to #17089, but I'm open to it. We'd need to think about what to do with interleaved buffers — both gltfpack and gltf-transform will interleave vertex data by default. I'm not sure how much binding and unbinding buffers in WebGL costs us in performance, but for models that don't reuse attributes in this way (probably more common) we don't want a performance regression there.

Naturally, I've tried optimizing the GLTF file using both gltfpack and gltf-transform. And although both of those do work, they end up taking just as much memory to do the optimization.

I'm fairly optimistic I can reduce the memory cost of optimizing this model in glTF Transform dramatically, if that helps anyone. Tracking this in donmccurdy/glTF-Transform#1315.