-
-
Notifications
You must be signed in to change notification settings - Fork 35.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GLTFExporter: Add comment for empty strings name #13359
Conversation
Hmm... When would |
Wait, I've misunderstood a bit by any chance... Don't merge yet. |
I think I've misunderstood #13209 so I posted a question there. |
Seems like we can forget about numeric And my original motivation of this PR is I suppose we should allow empty string
with
because I'll update this PR after #13209 is reverted. Or do you think we shouldn't export empty string |
gltfNode.name = object.name; I wouldn't do this, the default in three.js is an empty string and the default in glTF is |
Then when users wanna explicitly export empty string |
They can file an issue and make a case for it. ;) But 99.99% of cases are empty strings because it's three.js's default, and I don't think we should propagate that without a clear use case. |
Shouldn't this work? if ( object.name !== '' ) {
gltfNode.name = object.name;
} |
Lol, now I understand why you want to revert #13209! Folks, from 23 years of experience I can tell you people are going to throw all sorts of nonsense at importers and exporters and they will hope that they work. When it doesn't work they most likely won't be in a position to fix it themselves. Go with the simplest most pragmatic approach you can find. |
@webprofusion-chrisc We have a chance to be strict with the glTF format and make sure that people produce correct files. |
Yeah, I know I'm talking about the edge case so considering when an issue is opened with actual use case would sound reasonable. I feel like adding comment so far, like
or
What do you think? When we assume
What's your suggestion's purpose? |
I wouldn’t call it a TODO, I do not think we should let empty strings be exported as node names (mainly because it’s impossible to differentiate from default empty strings, and not worth having an option for a use case that no one has requested yet and probably won’t). Beyond that I’m OK with any of these changes. |
I came to think we should first clarify what empty strings names mean in Three.js. @mrdoob Which one should Three.js regard the object with empty strings name as
I thought Three.js expects 1., name can be any strings including length 0 strings so I wanted If Three.js expects 2. I don't think |
Shouldn't be a matter of doing this? In if ( node.name !== undefined ) object.name = node.name; In if ( object.name !== '' ) node.name = object.name; Do the glTF validators check that |
With case (2), this's good. With case (1), this may not be good because empty strings name info can be lost. It isn't guaranteed that other viewers convert As you Ricardo suggested so, probably case (2) would be the Three.js .name spec? My motivation is just to clarify Three.js spec and let exporter follow it. |
Definitely (2) is the right idea here. Let's go with #13359 (comment). |
@mrdoob Which one is the right spec in Three.js, (1) or (2)? |
(And if (2) is the right spec,) is the motivation of replacing |
👍 |
This reverts commit f3f9323.
… ) for the code consistency
OK, thank you for your patience, all! We clarified the name spec, then I've updated PR.
And, as I said the above, I'm gonna add note about empty strings name in Doc in another PR. |
Thank you! |
I think we need to compare
object.name
withundefined
to allow 0 and empty string as node name inGLTFExporter
.