Hi everyone,
Not sure if this counts as a bug per se, but it does lead to one:
Do not pass scene.meshes to GPUPicker.setPickingList. Otherwise your meshes will be gone when you dispose the picker.
Workaround is to pass a copy of the scene.meshes array (e.g. scene.meshes.filter(()=>true)); See playground.
Best wishes
Joe
That’s an interesting catch 
We try not to make copies of passed resources ourselves. We expect the user to know what data is being passed. However, this probably should be documented, either in the dispose function or the setPickingList - the array passed will be cleared.
Want to submit a PR for the docs?
Oh, BTW - the simplest way to create a copy is [...scene.meshes]. This doesn’t iterate the entire array and technically creates a copy
Ok, on my todo list.
Tested on how many computer settings, OSs, browsers, browser versions? I would not recommend a specifc way to clone. This is user responsibility. The important info is that a passed in reference is changed.
Just clone it yourself 
If Babylon clones it, there is only one possible outcome (-> clone). If Babylon does not, there is two possible outcomes (-> not clone, clone).
As a possible (non-tested) alternative that preserve performance, setPickingList could Object.freeze(list). That would at least more strongly communicate and actually enforce to some extent** that the GPUPicker takes ownership of the array. **extent referes to what Object.freeze actually freezes. But again. I would just clone it myself.
Yep. This is what I think as well
We can have all kinds of smart solutions for this, but eventually you need to know that the array passed will be cleared. Now decide which array you are passing
