WebGPURenderer: Instance Sprite Example

[RenaudRohlinger]

Related comment: #29491 (comment)

Description

Third attempt to provide a fallback for THREE.Points with sizeAttenuation support. This PR demonstrates how to combine Sprite Meshes with instanceBufferAttribute. /cc @WestLangley

This contribution is funded by Segments.AI & Utsubo

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	687.15 170.18	687.15 170.18	+0 B +0 B
WebGPU	805.7 216.91	805.73 216.91	+26 B +10 B
WebGPU Nodes	805.21 216.77	805.24 216.78	+26 B +11 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	462.85 111.79	462.85 111.79	+0 B +0 B
WebGPU	535.49 144.49	535.52 144.5	+26 B +9 B
WebGPU Nodes	491.67 134.26	491.67 134.26	+0 B +0 B

[WestLangley]

This is a thing of beauty. ❤️

I have hacked your example to test some scaling issues...

A Plane and a Sprite of unit size render the same size by design. So should a single instanced Sprite.

Currently the instanced Sprite is too big by a factor of two. This is because the geometry is twice as big. I temporarily fix it by scaling the uniform, but you will have to scale the geometry instead.

[RenaudRohlinger]

Thanks! 😊 I’ve scaled the geometry accordingly, so it should be now fixed.

[WestLangley]

Do you think InstancedSprites should have a .center property, like Sprite does.

Granted, you can add the property and it works.

const sprites = new InstancedSprites( geometry, material );
sprites.center = new THREE.Vector2( 0.5, 0 );

[sunag]

We can already make instanced sprites, this would be an additional redundancy in the library, more code, documentation and maintenance, object.count should be intended to instantiate any object

const material = new THREE.SpriteNodeMaterial( { sizeAttenuation: true, map: sprite, alphaMap: sprite, alphaTest: 0.1, transparent: true } );
material.positionNode = instancedBufferAttribute( new THREE.InstancedBufferAttribute( new Float32Array( positions ), 3 ) );

const particles = new THREE.Sprite( material );
particles.count = 10000;
scene.add( particles );

[sunag]

Could we use the object.count approach instead of creating new objects and materials? This example would be very useful.

[RenaudRohlinger]

Ahh, we all forgot about this obvious one. That's why you're the boss 😄.

Updated the PR consequently.

[sunag]

The nodes allow so many combinations. It also took me a while to process this possibility, luckily the implementation has evolved this far 🙏.

[WestLangley]

The original purpose of this PR was to add InstanceSprite -- just as we have InstanceMesh. Both are convenience classes.

But InstanceSprite was removed from this PR, and the PR was merged.

What is the plan for:

1. computing the correct bounding volumes necessary for frustum culling,

2. handling raycasting,

3. updating the position of one of the instances.

[RenaudRohlinger]

My initial idea was just rendering multiples sprites but I understand these elements are importants.

I can still cherry pick my previous commit if we want to add a new Class in the future with all these functions included just like InstancedMesh.

[WestLangley]

@RenaudRohlinger I do think your original PR was excellent.

[sunag]

@WestLangley These possibilities also came to my mind, but I think we should upgrade these apporachs based on GPU-Compute and abandon approchs using CPU. We could handle some internal rules using object.count > 1 as well, working with GPU on this should give us more performance and compatibility with procedural stuff, and the unification will reduce maintenance, documentation.