Avoid dots and colons being deleted from model's name

Hi there!

Is there a way to avoid dots and colons being deleted from the model’s name when loading it?

1 Like

This question was already discussed here:

To make it short: Sanitization of node names is necessary so they are compatible to the animation system of three.js.

3 Likes

Thank you for the reference! :slight_smile:

I ran into this because it unexpectedly caused an app to break when a certain model was introduced with a colon in its name.

The workaround is to strip characters for use for searching for objects by name:

const modifiedName = actualName.replace(':', '')
const node = root.getObjectByName(name)

Is this reliable?

It seems like it would be better to separate the target name from the property path instead of having them together. For example instead of this,

{
  name: 'someModel.quaternion'
}

have this,

{
  target: 'someModel',
  path: '.quaternion'
}

then target would not need to be touched. For example:

{
  target: 'my:cool.model',
  path: '.quaternion'
}

Looks like GLTF does something similar to this idea, where path does not also contain a node name.

I’ve been bitten by this but… I also think its ok to impose restrictions on the paths.
A lot of the exporters and importers would have to be changed… and a bunch of the internal logic of animations and even scene logic would probably have to be reworked. Loads of peoples pipelines would break… The way it works now, the path can be composed/decomposed by join(‘.’) and split(‘.’) and then iterated to drill down into custom properties inside an object. Allowing . and : would complicate that logic…

So… while I feel your pain… I wouldn’t expect this to become a priority.

It is about the node names. F.e. this breaks:

const mesh = new THREE.Mesh(...)
mesh.name = 'foo:bar' // some other code depending on node name breaks (f.e. load a Mixamo model).

I know. Mixamo also has like 3 different rig naming conventions like mixamorig_v1 and stuff… it’s a mess. And blender will rename bones if there are 2 in the scene with the same name due to it’s own restrictions. That’s why you often see bone_1 etc… in exports, because in blender:
Bone got cloned and became Bone.001 and blender requires object names to be unique… so it makes them unique, then rewrites the animations etc. So… there will always be some kind of “normalization” of object names, animation paths, etc. and allowing . and : doesn’t really fix that. It just makes property/path computation more complex.