OMI glTF Working Group Meeting 2023-08-31

[antpb]

This meeting is on 08/31/2023 at 9:30 PM (UTC) / 2:30 PM (PST) in the OMI Discord within the #omi-weekly-meeting channel. During the meeting, we will be using the #omi-gltf-extensions channel to manage a speaker queue, post links, and for any sidebar discussions.

To be notified of this meeting and others, subscribe to the OMI Meetings and Events Calendar or add yourself to the @omi-gltf-subgroup role in the #roles channel of the OMI Discord.

Agenda:

• Let's talk physics
• Questions asked in the gltf room: Why is it not good enough to have the MSFT spec? How is it bad that assets get sucked into Unity packages?

Backlog:

• OMI Vehicles Extensions Research
• OMI / MX Components Extension
• We discussed https://openmv.org (Open Metaverse Foundation) and how we can synergize with their efforts. Should we make a showcase of our projects to open up a broader discussion?
• jin - proposals how to make our specs and work more accessible to others. showcase gltf models
• Review pull requests https://github.com/omigroup/gltf-extensions/pulls
• EXT_skin_humanoid
• OMI_link
• OMI_spawn_point
• Review MSFT_physics
  • glTF_Physics_Blender_Exporter
  • glTF_Physics_Godot_Importer
• Licensing Extension https://twitter.com/superhoge/status/1596757861882740736
• KHR_audio / Khronos feedback
  • gltf-sample-assets
• Third Room Extensions
• glXF
• Show and tell
• Create next weeks agenda

To propose another item for the agenda, comment below (preferably before the meeting).

[antpb]

Noting stated reasons in the meeting "why not use MSFT":
-We don't have people in the meetings to discuss things so we have stayed contained in our group working on ours with consideration for theirs. Developing our own spec is demonstrating how a different approach can work.
-Having multiple specs gives wider coverage for experimenting.
-We've seen fast adoption of the OMI spec with more frequent feedback and discussions happening within OMI.

Note: MSFT is renaming some physics related extensions to the KHR prefix.

[aaronfranke]

Also worth noting about fast adoption of OMI: MSFT has had this too, Eoin from Microsoft has said that they have customers using MSFT physics which is part of what makes him resistant to change things.

[antpb]

Aaron mentioned a need for folks to jump in and take some time to review and comment on this issue: eoineoineoin/glTF_Physics#19

Some extended history can be found here: KhronosGroup/glTF#2258 (comment)

We realize its a lot but very few are participating. We could use some outside perspective.

[antpb]

There was some discussion about triggers. @madjin mentioned a discussion on behaviors in MSF. Transcribed here: https://hackmd.io/@XR/metaversestandards/https%3A%2F%2Fhackmd.io%2F%40XR%2Fgltf-interactivity

https://www.youtube.com/@metaversestandardsforum

[antpb]

We discussed KHR_audio and the recommendation to rename it to KHR_audio_emitter which better describes the behavior of the extension. Some historical reasoning behind the decision to rename OMI_audio_emitter to KHR_audio can be found here: #73

TLDR reasoning it was renamed in the past:

The extension has been renamed from OMI_audio_emitter to KHR_audio. KHR_audio both reflects the intent for this to be an official Khronos ratified extension and a more general audio extension to form the basis for additional extensions to provide features such as audio mixing, animation/one shot triggering of clips, additional audio format support, etc.

There was general agreement that it should be KHR_audio_emitter

KHR recommendation for naming extensions can be found here: https://github.com/KhronosGroup/glTF/tree/main/extensions#naming

The recommendation is to use KHR_scope_action so in our recommendation it makes sense that audio_emitter is the scope and action.

Names SHOULD be structured as , where scope is an existing glTF concept (e.g. mesh, texture, image) and feature describes the functionality being added within that scope. This structure is recommended, but not required.

[antpb]

worth noting material extension is named materials which kinda deviates from the recommendation. Still, a good justification for action_scope in renaming KHR_audio.

[antpb]

I mentioned a need for the MSFT proposed extensions to be renamed to follow the scope and action suggestion in KHR extension naming. @antpb to open an issue.

Currently there is KHR_collision_shapes (which has the same issue as the materials plural extension)

and there is KHR_rigid_bodies which probably shouldn't break up the word and also be scope_action.

Suggestion KHR_physics_body and KHR_physics_shape

[antpb]

issue opened here: eoineoineoin/glTF_Physics#23