ThreeJS: Any drawbacks to using objects without a UUID?

Questions
1

I’m exporting some 3D models from Blender to ThreeJS JSON. In it, I see that all objects are exported with a pre-defined UUID:

{
"name":"Disc",
"uuid":"9B60F750-C64F-433A-8C1E-9E88639DC503",
"visible":true,
"type":"Mesh",
"castShadow":false,
"receiveShadow":false
}

If I remove this “uuid” property, the scene still renders with no problem. When checking the Mesh properties, I get "uuid": undefined as expected.

This raises the question: What’s the benefit of having an auto-generated UUID in ThreeJS, besides using getObjectById()? Does the WebGLRenderer need it for something? Additionally, if we need to use getObjectById(), we would already need to KNOW the ID, which means a self-styled ID would be more useful than a completely unique, randomly generated ID, no?

2

THREE.WebGLRenderer internally does a lot of caching, and i believe it may be using the uuid’s for that. Although your example would say otherwise. There were some issues with the performance of uuids which might be worth looking up on github.

3

I saw the thread about UUIDs taking up a lot of memory on Github, which prompted my interest into this.

I understand why UUIDs are important, for instance, in databases, where many servers will be generating and accessing the same data, and duplication could be harmful. But in a local WebGLRenderer environment, I don’t see the usefulness of it. It could just as easily be an incremental [1, 2, 3, 4, ...] list of integers, instead of a 128-bit UUID. Am I correct in making this assumption?

4

I believe you are, but i’m not savvy in this area, i’ve fiddled with the caches but do not know how they’re indexed. I’ve never serialized a single three.js object other than a vector.

List of integers, maybe even a list of bit masks (each number could store more than one index?), probably lots of avenues to explore.