Three.js: WebGLIndexedBufferRenderer.setIndex 'type' is undefined (with an odd number of meshes?)

[joshstrike]

Three.js version

• [ x ] r97

Browser

• [x] Chrome
• [x] Firefox

OS

• [x] macOS

This error appears to happen when some meshes are NOT created, but doesn't occur if they ARE created. It's almost as if it's happening only when there's an odd number of geometries. This has had me stuck for days because there seems no rhyme or reason to it, but I've finally made it reproducible.

Specifically, attributes.get( index ) is returning _undefined_ when looking up the Uint16BufferAttribute for a sphere based on SphereBufferGeometry. The really weird thing is, if I create a mesh right before that sphere, without even adding it to the scene, there's no error.

I'm writing this in a Typescript project structure, but here's a working JS example:
http://thestrikeagency.com/vrtest2/

From the blank start screen, if you press the "S" key it will try to draw a controller beam, a cube and 3 spheres, and fire the error when it gets around to rendering one of the spheres (I infer this from the size of the buffer attribute). If you press the "W" key from the start screen, it will instantiate a mesh right before drawing the first sphere, and there is no error. The only difference is on line 31 of Level.js (where it uses a key event to decide whether to create that unnecessary mesh):
http://thestrikeagency.com/vrtest2/js/app/game/pong/Level.js

edit:
Also worth noting, in http://thestrikeagency.com/vrtest2/js/app/game/Game.js on line 29 I instantiate a "Cursor" class (class link: http://thestrikeagency.com/vrtest2/js/app/vr/controls/cursors/Cursor.js ). This is actually done after the spheres. In this example, all it does is create a CylinderGeometry (Cursor.js line 48) and a mesh from that. I've tried it with CylinderBufferGeometry with the same result. It doesn't do anything further or attach it to the display chain. What I've found is that if I don't create the CylinderGeometry there, whether or not I create an empty mesh, the error doesn't fire.

[WestLangley]

Sorry, we cannot debug your project. If you need help, you can try the forum.

If you are subsequently able to demonstrate a three.js bug, you may reopen this issue.

[joshstrike]

I'd certainly never ask you to do so. Thanks for the good work.
For future reference, anyone using Typescript and seeing buffers overrun or hit unknown parts at random: Make sure you're not importing Three.js twice via includes or require. Never import * as THREE. Just reference path it. Two copies of Three.js running simultaneously will attempt to read/write the same buffer attributes and hit something undefined anytime they're accessed from a subsequent include. The only way to properly use in Typescript is to not import Three.js at all, just put it in a script tag in your HTML and use a reference path to the definition file. Don't import 'three' from various parts of your project. It tends to load more than one copy and they all write to the same canvas and try to access the same buffers.

Hopefully this saves someone some time.

[davidarnarsson]

Just in case someone wanders in from google. I ran into this issue on a gatsby typescript stack when trying to create a minimal three.js bundle using webpack's resolve.alias. What fixed it for me was making absolutely sure that any postprocessing pass I was referencing was not itself explicitly referencing three.module.js. Which meant copy/pasting the contents of all the threejs modules I was using from the examples/ directory into my project and fixing their references. A bit tedious but worked.