Adding prefix to Object3D id

[NicolasRannou]

Using 2 different libraries (A and B) based on threejs.

Each library generates valid threejs meshes independently. However, the id of the meshes from library A and B can conflict (i.e. be the same). Then when we add meshes from library A and B into the same scene it does not render properly.

Is there a mechanism we can use to generate meshes independently and ensure IDs do not conflict while rendering it in the same scene?

One idea is to add a prefix concept:

Object.defineProperty( this, 'id', { value: object3DId ++ } );
=>
Object.defineProperty( this, 'id', { value: `${prefix}-${object3DId ++}` } );

Not quite sure which would be the best way to pass the prefix though.

Any thoughts on that?

Thanks

[NicolasRannou]

I believe that updating the object ID after calling the constructor is not enough (or is it?):

class HelpersContour extends Object3D {
  constructor(stack, geometry, texture) {
    //
    super();
    this.id = 'mynew' + this.id;
    // should I loop though all children and update IDs in the same way?

[NicolasRannou]

We would need to make id reconfigurable in such a case.

Object.defineProperty( this, 'id', { value: object3DId ++, writable: true } );

[Mugen87]

Set writable to true seems the easiest way to solve this problem. You can manage a global object ID on app level and overwrite the .id property immediately after object creation or a super() call.

[NicolasRannou]

Yes, definitely - I'd be happy to make a PR if it is fine with you.

Would updating the ID of the object extending Object3D be enough for threejs to render it nicely of should we also update IDs of all children (if any)?

class SuperArrow extends ArrowHelper {
  constructor(stack, geometry, texture) {
    //
    super();
    this.id = 'mynew' + this.id;
    // should I loop though all children and update IDs in the same way?
    // or not needed?

Thanks!

[Mugen87]

You have to update all objects. I think it is also necessary to overwrite the ids of geometries, materials and textures if both of your libraries generate these types of objects.

I'd be happy to make a PR if it is fine with you.

Let's see what other developers think if the suggestion.

[NicolasRannou]

Yes - so the suggestion is to make id writable in Object3D:

Object.defineProperty( this, 'id', { value: object3DId ++, writable: true } );

[Mugen87]

To be consistent, I would also perform this change for Geometry, BufferGeometry, Material and Texture.

[haroldiedema]

I think it would be more beneficial to have a form of a generator for this.

For example:

// Your app.
let id = 0;

function ThreeIdGenerator() {
    return id++;
}

THREE.idGenerator = ThreeIdGenerator;

And have something similar in threejs itself to use by default. Since objects aren't (under normal circumstances) created in real-time, there should be very little to no overhead, while letting developers using threejs determine their own ID generation-style.

This way, developers don't have to "hack around" objects generated by THREE and having a mechanism like this also ensures consistency between the instantiation of different types of objects. Also, if there comes a time where THREE keeps track of object ID's it has created, functionality will break if your app decides to change the numbers after the object was created.

[NicolasRannou]

I see what you suggested but unfortunately, it relies on global variables and I'm not sure it would work all the time: for instance, how would you go to update the "generator" function without using the global variable window.THREE?

import {Mesh} from 'three';

// how do you update the ThreeIdGenerator ?
const myMesh = new Mesh();

I'm still in favor of having ids writable :)

import {Mesh} from 'three';

const myMesh = new Mesh();
myMesh.id = `customId-${myMesh.id}`

I like the idea of providing custom ID generators but I'm not sure that is doable

[haroldiedema]

The way module resolving works in javascript is that every time you import a module, you effectively get back the same "instance" of a module.

So if THREE has a module called IdGenerator, it can use it internally, and you can overwrite it.

For example:

import {IdGenerator} from 'three';

let id = 0;
IdGenerator.generate = function(id) {
    return id++;
}

While inside THREE itself, it looks like this:

function Mesh ( ) {
    this.id = THREE.IdGenerator.generate();
}

[Usnul]

a few things.

1. Having library-wide generator be global, and editable is not a good idea. If you have 2 libraries: A and B that rely on THREE.js and both rewrite that generator - you're not in a good situation.
2. suffixes are a bad idea. Currently, ID follows a standard - UUID spec of IETF, adding anything to that string will basically make it garbage instead of a standardized ID.

I think your pursuit is misguided in the first place. If 2 libraries make use of three.js - they should make use of the same instance of three.js, this avoids version conflicts, separate caches, gl contexts etc. I also don't consider it to be a good design to include the same library twice, especially if you plan to mix the outputs of those two copies.

[NicolasRannou]

@haroldiedema I like your suggestion if we can make it work (it seems we need different id generators for meshes, materials, etc.)

@Usnul

Having library-wide generator be global, and editable is not a good idea. If you have 2 libraries: A and B that rely on THREE.js and both rewrite that generator - you're not in a good situation.

Can you detail? What if you build extensions for threeJS, say a set of new material for "cinema" and a set of helpers for "video games". That would be great if people can just import it into their existing app and just use it without worrying about conflict of ids.

suffixes are a bad idea. Currently, ID follows a standard - UUID spec of IETF, adding anything to that string will basically make it garbage instead of a standardized ID.

There are 2 things there, uuid and id. I am proposing to extend the id.

I understand what you say about caching, gl context, etc.. I agree, we should only use 1 version of threeJS for all the rendering part but would be nice to be able to pick meshes/materials/geometries from different places seamlessly.

Developers have to make sure versions are compatible of course.

[Usnul]

Can you detail? What if you build extensions for threeJS, say a set of new material for "cinema" and a set of helpers for "video games". That would be great if people can just import it into their existing app and just use it without worrying about conflict of ids.

Sure, lets say you have a global namespace THREE, now if your App A sets a property value THREE.generator to X and your app B sets a property value for the same property to Y - only one of those will actually stick. This is more about the case where you do, in fact, have only 1 instance of the library.

There are 2 things there, uuid and id. I am proposing to extend the id.

Okay, sorry, I made a pre-emptive conclusion. There are some other considerations though, if ID is an integer - it maps very well to an array index, if it's a string, however, your arrays becomes a glorified map with a lot of properties which are not actually indices - this leads to degraded performance for one, and makes any attempts at index-based iteration over that array fruitless, including built-in methods such as .forEach, .map, .filter etc.

[haroldiedema]

Sure, lets say you have a global namespace THREE, now if your App A sets a property value THREE.generator to X and your app B sets a property value for the same property to Y - only one of those will actually stick.

Now I think about it, I think you have bigger problems if there are actually multiple instances of THREE loaded in your app. If you manage to let both libraries use the same instance, then your problems will also be gone. I would suggest trying this instead of "hacking" around the ID generation.

[Usnul]

@haroldiedema
Yeah, that would be my suggestion too.

Make those libraries accept three.js instance as an input in the initialization code (e.g. constructor) or just the relevant parts.