Accessing mesh names from jgltf-model

[laserallan]

It seems like mesh names are not available when accessing a scene using the jgltf-model. It seems like they are available in jgltf-impl-v2.
Is this by design or is there a way to find them that I have overlooked?

[javagl]

The names are indeed not accessible. The name is part of the glTFChildOfRootProperty schema But right now, this name is not passed through the "model" interfaces.

There is no striking reason to not do this, except for my general tendency to start with a small interface and extend it later (when necessary), rather than having methods in an interface that have to be omitted/deprecated in a subsequent release.

For the case of the names, I think it could be justifiable to also pass it through the interface. The names may be useful for identifying the objects. Although, on implementation level, this may tempt users to attach some sort of semantics to these names (which is certainly not a good idea), it may at least be useful for some sort of user feedback in a UI. Additionally, the names exist in glTF 1.0 and 2.0, will certainly not be omitted in a future release, and have rather trivial constraints: They may be an arbitrary string (or null).

So introducing a high-level interface (involving names like Named and/or ModelElement) that only declares the getName() method may be one solution here. What do you think?

[laserallan]

Thanks for you answer. I think it would make a lot of sense to keep them around. In cases where you do any type of scene graph exploration. Also any back conversion or roundtripping through an application would lose that information for no good reason if using jgltf-model to explore the scene. Ideally I'd like to see it on nodes and other types in the API too where they seem to be lost as well (also much of the sample gltf files I find seem to omit names for some reason) so the proposed solution would work great for me and I don't see how it makes things significantly more complicated. With that said, as a lightweight solution to the problem (presenting and editing the the scene graph in a treeview) something like a map of optional attributes would also work if it feels less like cluttering up the API (the names are optional in gltf after all). Regards David

…

On Fri, Oct 6, 2017 at 8:52 AM, Marco Hutter ***@***.***> wrote: The names are indeed not accessible. The name is part of the glTFChildOfRootProperty schema <https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/schema/glTFChildOfRootProperty.schema.json#L7> But right now, this name is not passed through the "model" interfaces. There is no striking reason to *not* do this, except for my general tendency to start with a small interface and extend it later (when necessary), rather than having methods in an interface that have to be omitted/deprecated in a subsequent release. For the case of the names, I think it could be justifiable to also pass it through the interface. The names may be useful for identifying the objects. Although, on implementation level, this may tempt users to attach some sort of *semantics* to these names (which is certainly not a good idea), it may at least be useful for some sort of user feedback in a UI. Additionally, the names exist in glTF 1.0 and 2.0, will certainly not be omitted in a future release, and have rather trivial constraints: They may be an arbitrary string (or null). So introducing a high-level interface (involving names like Named and/or ModelElement) that only declares the getName() method may be one solution here. What do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABswG3QkVo5qQ5tpkXURdwJahsC4gopwks5spkymgaJpZM4Pv_Pd> .

[javagl]

presenting and editing the the scene graph in a treeview

Right now, there is a tree shown in the jgltf-browser, but this only presents the file structure (and it is implemented in a very crude and "pragmatic" way, without any real knowledge of what glTF or its structure is). An additional tree view that presents the scene structure is already on my TODO list. (There already are similar tools, but nevertheless). However, this immediately raises the question of how much editing should actually be possible in this context. After all, glTF is intended as a runtime format, and not really supposed to be edited. The JglTF infrastructure currently aims at simplifying the rendering in Java, and (via the jgltf-browser) some basic inspection/debugging. For editing, the preferred file format would be COLLADA, and there are authoring tools like Blender, Maya and MAX, going slightly beyond what I tried to accomplish with JglTF ;-)

However, retaining the names certainly makes sense. I'll tackle this ASAP.

[laserallan]

Thanks, I appreciate how quickly you are dealing with this.

…

On Sat, Oct 7, 2017 at 12:03 PM, Marco Hutter ***@***.***> wrote: presenting and editing the the scene graph in a treeview Right now, there is a tree shown in the jgltf-browser, but this only presents the file structure (and it is implemented in a very crude and "pragmatic" way, without any real knowledge of what glTF or its structure is). An additional tree view that presents the *scene* structure is already on my TODO list. (There already are similar tools, but nevertheless). However, this immediately raises the question of how much *editing* should actually be possible in this context. After all, glTF is intended as a *runtime* format, and not really supposed to be edited. The JglTF infrastructure currently aims at simplifying the rendering in Java, and (via the jgltf-browser) some basic inspection/debugging. For editing, the preferred file format would be COLLADA, and there are authoring tools like Blender, Maya and MAX, going *slightly* beyond what I tried to accomplish with JglTF ;-) However, retaining the *names* certainly makes sense. I'll tackle this ASAP. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABswG073BrXNGwvPTmDJtvI-0CrdQ0pfks5sp8sMgaJpZM4Pv_Pd> .

[javagl]

As of 82bb96b , there is a NamedModelElement interface that the relevant model interfaces (including the MeshModel) inherit from, and it offers a getName() method that returns the name that the element had in the glTF asset.

(Note: The CameraModel interface already had a getName method. This has now been renamed to getInstanceName, as it returns a string identifying the actual camera instance, which is created from the combination of the node and the camera itself)

Closing here for now, but feel free to add further comments.

[laserallan]

Thanks. I managed to get the new version and it seems to work. Thanks again. David

…

On Tue, Oct 10, 2017 at 3:20 PM, Marco Hutter ***@***.***> wrote: As of 82bb96b <82bb96b> , there is a NamedModelElement interface that the relevant model interfaces (including the MeshModel) inherit from, and it offers a getName() method that returns the name that the element had in the glTF asset. (Note: The CameraModel interface already had a getName method. This has now been renamed to getInstanceName, as it returns a string identifying the actual camera *instance*, which is created from the combination of the *node* and the *camera* itself) Closing here for now, but feel free to add further comments. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABswG_g2VfnInfn0HfbfYY0-FPs140roks5sq-3EgaJpZM4Pv_Pd> .