BatchedMesh: Exception with InterleavedBufferAttribute

[marwie]

Description

Batched mesh addGeometry throws exception for geometry with InterleavedBufferAttributes

Reproduction steps

1. checkout https://github.com/needle-tools/three.js/tree/batched-mesh-interleaved-buffer
2. run webgl_mesh_batch example
3. observe error

The mesh was processed with gltf-transform and simplified

weld: primitive[0] of mesh "Sphere" → tolerance: 0.0001
weld: Tolerance thresholds: POSITION=0.0001, NORMAL=0.05, TANGENT=0.05, TEXCOORD_0=0.0001, TEXCOORD_1=0.0001
weld: 515 → 515 (+0.00%) vertices.
simplify: primitive[0] of mesh "Sphere" → ratio: 0.0625, error: 0.3, lockBorder: true
simplify: 515 → 92 (–82.14%) vertices, error: 0.1558.
sparse: Updated 0 accessors.
sparse: Complete.

Code

see 54b78a0

Sphere.zip

Live example

I have to submit this another time if necessary

Screenshots

Version

162

Device

Desktop

Browser

Chrome

OS

Windows

[marwie]

Here's a bit more info. Seems like when creating a new instance of the InterleavedBufferAttribute class the passed in interleavedBuffer field is actually the array data

[marwie]

A quick hack in _initializeGeometry works needle-tools@fa7e823

Maybe someone can explain why the arrays are created with new array.constructor and suggest a better(?) solution

But the beautiful lowres sphere renders:

[gkjohnson]

These lines are the problematic ones:

const dstAttribute = new srcAttribute.constructor( dstArray, itemSize, normalized );
dstAttribute.setUsage( srcAttribute.usage );

It looks like these lines were added in #25059 but I don't think there shouldn't be any reason to ensure the data is using an InterleavedBufferAttribute if the original geometry is. Likewise I don't believe there's any reason to retain the "usage" setting from the original attribute.

new srcAttribute.constructor should be able to be able to be changed to new BufferAttribute and the setUsage line can be removed, if you'd like to try that out and make a PR.

Maybe someone can explain why the arrays are created with new array.constructor and suggest a better(?) solution

This is done to retain the original precision used for the attribute data and should not change.

[marwie]

Thanks - that seems to work. I'll do some more testing and then open a PR. Thank you

[marwie]

Is it expected that the batched mesh looks like this when enabling wireframe on the material?

[gkjohnson]

Is it expected that the batched mesh looks like this when enabling wireframe on the material?

It's hard to say without knowing what the original geometry looks like. I'm not so familiar with how wireframes work internally but it's possible BatchedMesh needs special handling.