three.js: BufferGeometry: .setIndex method does not take null as input

The following TypeScript code does not compile:

const geometry = new THREE.BufferGeometry();

geometry.setIndex(null); // Argument of type `null` is not assignable to parameter of type `BufferAttribute | number[]`.

I guess supporting this code would mean allowing to dynamically turn an indexed geometry into a non-indexed geometry without going through the toNonIndexed helper method e.g. without creating another BufferGeometry instance.

I am wondering if that’s a case that could easily be supported and if I should open a PR for that. If not, feel free to close this issue.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 20 (9 by maintainers)

Most upvoted comments

I just want to add a note on the fact the setIndex implementation might already accept null as input, it’s only the TypeScript definition that lacks this input type.

Then feel free to enhance the respective TS declaration file if this solves your original issue 👍

For me it’s mostly an API consistency and ergonomics issue… if the following code is valid:

var geometry = new BufferGeometry();
geometry.setAttribute( 'position', positionAttribute );

// index is null.
geometry.setIndex( index );
// index is not null.

… then we are allowing users to incrementally construct BufferGeometry instances with “invalid” intermediate states, and as long as the state is valid when rendering, that’s fine. For the reverse — removing an index — not to work feels like a surprising “gotcha” in the API. Patterns exist for immutable objects (Builder patterns, or requiring immutable properties as constructor arguments) but irreversible setters are unusual.

I can contrive some use cases…

  • declarative frameworks like react-three-fiber or A-Frame might want to clear properties in one method and set the new values in another
  • user might use multiple indexes as more flexible draw ranges on a “triangle soup” mesh, or remove that index to draw the entire mesh

… but IMO the priority is “what is least likely to surprise the developer” here.

Um, I did not think of deleteIndex() so far. But I really like it^^.

Yes, I simply expect my users to know what they are doing. So if they change the index, they must change the vertices.