Export room with objects as gltf for use in Spoke

[johnshaughnessy]

Is your feature request related to a problem? Please describe. People collaboratively aggregate media in a hubs room, but cannot tweak or move this media to a new room later. We have the objects.gltf file for the room, and it would be nice if we gave users a way to export these room objects (with the current scene) for use in Spoke as a new scene.

Describe the solution you'd like A "remix this room in Spoke" button that exports the current room state as gltf or glb and then loads it into Spoke.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

┆Issue is synchronized with this Jira Task

[misslivirose]

Some general thoughts - can we limit this to the room owner being able to export? Should we?

It would be nice to get this in on the earlier part of the quarter since I know that it's a major ask from the IEEEVR folks

[robinkwilson]

Summarizing the discord conversation starting here Contributers @misslivirose @gfodor @blairmacintyre @robertlong

MVP Options

Minimum MVP export .spoke file design by Liv:

• Export + Close their room
• HC Admin can toggle on. Room owner gets option. Creates .spoke file to import into Spoke
• We don't put this on in HMC
  • Pros:
    • +1 simple to understand
    • Export to .spoke button could work in the interim "experimental/not supported"
  • Cons:
    • Creating external file leaks abstraction
    • It will need to export assets stored within the hubs instance along with the scene file and room file with pinned assets
    • Importing it back into hubs (this instance or another) should create a room that feels the same (external assets could be pulled in, like from sketchfab, again; assets that were only stored in the hubs server should point at assets stored in the current hubs server -- if it's the same server, it could reuse the same assets, but if a different server, it should upload them from the exported archive)

Direct transition to spoke

• Update an existing project or be used to create a new one, "Save room to existing Spoke project" or "Remix room as new Spoke project" — Robert
• Design considerations:
  • Lose data if you save changes to the spoke project after you publishing it overriding changes.
    • Can warn you are overriding changes made since last publish. Expose to admins when project was last updated and last published.
  • Use inverse of gltf-component-mappings by adding some additional nodes to it based on what's pinned in the room — Robert
  • We actually can round trip the existing assets in that way. Just the objects in the room.
• Pros:
  • +1 simple to understand
  • If you aren't the project owner you're creating a new project based on published project in the remixable scene. So there's no room for data loss there.
• Cons:
  • No interactables in Spoke and meshes are combined on export. Round trippin assets are impossible

Paste a hubs room url into it and it pulls the scene + assets into it by Blair

• Pull everything across, creating new assets, creating the room, copying the scene, etc.
• If I had appropriate permission: Could do this in HMC or ANY hubs-cloud enabled export via URL instance.
  • HC Admins can enable cloud export via URL
• Blair's instance examples
  • • hubs.mozilla.com -> my personal hubs-cloud (rooms I've built there that I'd like to move)
  • ieeevr -> hubs.mozilla.com (for attendees who want to have their private room moved ... I'd tell them to message me)
  • ieeevr -> my personal hubs-cloud (a bunch of rooms that I want to preserve copies off and play with)

Push Specific assets to scene:

• If we retained a link between a scene and the original project (making note when that doesn't exist), we could just do that: don't think of it as room export, think of it as "asset export" where you could pick one or more objects in the room to "push to the scene"

Stretch goals:

• Live editing

Issues and frustrating circumstances to avoid

Avoid data loss

• Scenario by Greg:
  • Catch-22 concretely:
  • user adds a video in hubs
  • exports to spoke
  • user tweaks video audio settings in spoke
  • user adds another video in hubs
  • exports to spoke
  • realizes later their audio settings were blown away, or just has their brain implode when it says "overwrite existing scene" after they just spent a half hour tuning audio settings
  • you are cutting off a tool and now have to lose work. basically its as if you opened a new tab of spoke, and half the features were disabled, and you didn't realize it yet, and then you had to choose which 'half' of the features you wanted to stick with, and any changes you made in the interim with the wrong half are gone
• Scene exporter may allow for changes to not be saved
  • if export to .spoke -> add to existing scene which overwrites -> re-publish works that seems ok to me. one risk is it may induce data loss. if you edit your scene, then import the spoke file, it will blow away your changes.

Scene sprawl

• Completely new scene created if one thing in the room changes

If we close rooms, links will become invalid.

• Have option to keep a deleted room around, but reset to empty space. We do something like when you export to a scene, it gives you the option to keep the room around, but resets it's scene to the empty space. so, after I finish with spoke, I need to go in and reset the room scene to the new scene. Want to click a button that opens the room in spoke as a new scene
• Downstream workflow issues
  • Update spoke, push to hubs, or either, how does that interface with the pinned objects state?

How does 'scene-owned-entities' work

[misslivirose]

Given the scope of doing this, we're going to push this out of Q2.

[jywarren]

Any updates to this in light of the sunsetting plan, perhaps to allow people to export their whole room in glb/gtlf for archiving? Thank you! ❤️❤️

[jywarren]

Noting the export to GLTF code from Spoke is here: https://github.com/mozilla/Spoke/blob/9fe7af7e0b4eab5908d1ada17c06aab223c978ce/src/editor/gltf/GLTFExporter.js#L617-L664

Including image media object export (highlighted). But, in testing this out, it seems perhaps image objects aren't exported -- they don't seem to be in the resulting .glb and when a scene contains only an image, i get the "e is not iterable" error which indicates it can't find anything to export.

[jywarren]

I didn't actually know though that objects.gltf was generated for every room! I was able to download it for a room I am looking to archive. The URL is simply the same as the room URL but the last string (the customizable one) is replaced with objects.gltf: https://hubs.mozilla.com/ZbPnoCW/objects.gltf

The format is so simple, very nice: https://gist.github.com/jywarren/a2447ae2e236b20b7fe2d57f36f61c7d (this is simplified to show just one image)

So no exporter is required, but the actual images shown are part of a hubs specific usage, not standard GLTF format - so to archive this and make it viewable in a simple GLTF viewer like https://gltf-viewer.donmccurdy.com/, we would have to:

1. Create standard GLTF image objects, rather than Hubs specific ones (need to find an example file for this - here or maybe this)
2. Possibly embed the files as data-urls, before Reticulum gets shut down, and to make the room export fully
3. Possibly combine with the gltf export of the scene?

This seems a little steep a climb for me, but plausible... would others find this to be useful? I'm imagining a web form where you input the URL of your room and it fetches the objects.gltf file, but also offers to convert it to a standard GLTF format so you can view the images in a standard viewer?

[jywarren]

I wanted to note that with help, I found the scene is provided in glb format in every room, and a URL is noted in the console when it loads. However it is named with a .bin extension. When renaming it to .glb (watch for Mac extension hiding issues) it loads fine consistently for all rooms. Moz export tools will also make this available in a bulk interface.