WebGPURenderer: InstancedPoints Revision

[RenaudRohlinger]

Related issue: #29269

Description

• Refactored InstancedPointsNodeMaterial:

  • Added support for map, alphaTest, and fog by propagating of the view position to positionView, simplifying the internal logic.
  • Introduced sizeAttenuation to control particle size scaling based on screen-space distance.

• Fixed UV handling in InstancedPointsGeometry (when debugging the UV value was incorrect).

• Added a new example webgpu_instance_points_billboards for behavior comparison with the existing webgl_points_billboards.

• Safeguarded the renderer from breaking when alphaToCoverage is used without multisampling (common when antialias is disabled).

/cc @sunag @aardgoose @WestLangley

This contribution is funded by Utsubo

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	685.24 169.64	685.24 169.64	+0 B +0 B
WebGPU	826.41 221.63	826.87 221.74	+461 B +110 B
WebGPU Nodes	825.99 221.54	826.45 221.64	+461 B +106 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	462.02 111.48	462.02 111.48	+0 B +0 B
WebGPU	525.5 141.64	525.57 141.66	+70 B +18 B
WebGPU Nodes	482.15 131.46	482.23 131.47	+70 B +15 B

[WestLangley]

Added support for map, alphaTest...

This is a design decision. /ping @mrdoob, @gkjohnson. Should instanced points and instances sprites be separate? I believed they should be.

Please read this comment carefully.
#26930 (comment)

[RenaudRohlinger]

From my understanding, InstancedPoints essentially extend the old THREE.Points API, with the new added feature of circle-like rendering.
It functions as a quad of pixel size (pointWidth) and supports texture mapping since it has a UV attribute. For Developers transitioning from WebGLRenderer to WebGPURenderer, the primary changes would to be prefixing the Points class with Instanced and replacing size with pointWidth basically.

I’m fine with moving the material node changes to a new Sprite class, but it feels a bit redundant and somehow confusing as to why most of the WebGL Points will become Sprites in WebGPU and InstancedPoints basically unneeded since everything will be achievable as InstancedSprite.

[WestLangley]

@WestLangley said:

Instanced sprites have a map, are sized in world units, can be size-attenuated, and can be rotated.

Points are sized in pixels, and are just a "fat" point-list primitive.

The two are fundamentally different.

[gkjohnson]

Instanced sprites have a map, are sized in world units, can be size-attenuated, and can be rotated.

I don't know if there's a universal definition for points in that sense. More pragmatically it may depend on what's intending to be rendered. I've often rendered point clouds with attenuated, world-space point sizes to avoid the implicit surface becoming to sparse as you zoom in. Potree, a pretty widely used point cloud rendering library, also uses world point sizes seemingly derived from point cloud density for similar reasons and likewise uses a map to augment the point shape (this may be done with a shader in Potree but I've used a map to render a circle for a point rather than a box in the past):

Potree demo page

What I do think is probably consistent is that points will not be rotated while sprites will be. Other than that I think the implementation between the two concepts can be almost completely shared. At some point I think the naming is mostly about usability. If a user is trying to render a point cloud they will likely be looking for a "points" renderer and if they are making a 2d game they may more likely be looking for "sprites" - even if they are almost the same implementation.