Since you mention CanvasViewerOptions, I assume your code is using the lower layers (not HTML3DElement). If that is the case, and you are calling loadModel yourself, then one option that works today is to pass in an option to disable the MSFT_audio_emitter glTF extension:
This is very new and somewhat still in flux, but you can inherit from ViewerElement and specify a different class that inherits from Viewer if you want to subclass it as well. You can also override ViewerElement._createViewer to customize the viewer creation process. From there, Viewer and ViewerElement both expose a number of protected properties and functions that let you heavily customize many aspects of the viewer. For example, there is a protected function to load a model, which allows you to load many models at the same time if this is what makes sense for your scenario. You also of course have full access to the scene and can directly manipulate it in whatever way makes sense (for example, adding primitive shapes like cubes or spheres, etc.). This part of the Viewer is a new, advanced use case, and is not fully fleshed out, so itâs not documented yet, but a lot is possible (and in fact others are already building on it in this way!).
Heads up, as of version 7.50.0, WebGPU (with âfast snapshot rendering,â e.g. GPURenderBundles) will be used by default in Chromium browsers when supported. Depending on the model being rendered, this can result in a sizable performance boost. As WebGPU matures in other browsers, we will default to WebGPU in those browsers as well.
As of 7.51.1, the Viewer will now try to render at full native resolution, and dynamically reduce rendering resolution as needed to try to achieve the target frame rate (currently hardcoded at 60fps). This improves rendering quality on high dpi devices (mobile, etc.).
When the Viewer suspends the render loop (e.g. when nothing is visually changing frame to frame), it will render the final frame at full native resolution so the âfrozen frameâ is max quality.
Great work! Some requests based on our potential company usage:
Ability to import and parse HTML to restore the state. Reason being: if there are lots of hotspots, we want to be able to restore edits. If youâre accepting PRs to the configurator at this time, Iâll happily give it a go.
Connection to SharePoint model viewer where all features can be implemented. This gives a wider practical use of the configurator. Modern SharePoint doesnât allow for easy HTML/script insertion and there are too many ICT barriers for the majority of large companies.
My first thought was the ability to export as a GLTF with the metadata and SharePoint parses this. Disconnected from the configurator (but this is okay).
As a quick work-around, could core SharePoint devs accept <babylon-viewer> element in Pages and auto-load the SharePoint CDN hosted script into a Page for any 3D model?
An alternative is adding a BabylonJS Viewer app to the SharePoint marketplace which allows copying/pasting the HTML snippet with access to the configurator (could be the Edit button similar to Pages). Maybe youâre planning to embed this into SharePoint directly like this? Iâd like to make a free marketplace app but pointless if MS have great plans
Regarding restoring state, this is part of a broader change that I have under way that will be completed after the Babylon 8.0 release. This change will bring the following (assuming no unexpected blockers):
Most or all properties will be added to the ViewerOptions. These will be used as the default values for the properties.
This will mean ViewerOptions can easily be parsed from a json string.
The Viewer Configurator will output this json in addition to the html. This means the Viewer Configurator will be useful if you are using the lower Viewer layers as well, not just the html layer.
The Viewer Configurator will add the ability to save the current state to a unique url, just like many of the other Babylon tools. This will save encode the current configuration into the ViewerOptions object, stringify it, and store the json on the Babylon snippet server like other tools, and you will be able to just load the Configurator with that snippet id to restore the state.
These changes are under way, but thank you for the offer to help! If there is a piece of this work that can be done independently, I may ping you!
There are no plans to do this, and it seems you know more about SharePoint than I do, so Iâd say go for it if you have some ideas here. Not sure if the json configuration stuff mentioned above would help with this as well. E.g. instead of copying/pasting the html from the Configurator, copy/paste the json and either pass it into the HTML3DElement constructor, or use the ConfigureCustomViewerElement helper function to create a specialized custom element with this configuration and an html tag name of your choice.
Yes, that would be great! We often use the viewer - Model Viewer. Due to the presence of the AR function there.
If the same thing could be implemented in Babylon Viewer, it would be really cool!
There is now a save button. Clicking this will save a snippet and add the snippet id to the url, just like other Babylon tools. Reloading the url with the snippet id will restore the saved configurator state.
There is now a dropdown to switch from html output to json output. The json can be used as the ViewerOptions for any layer of the Viewer (Viewer, CreateViewerForCanvas, HTLM3DElement, ConfigureCustomViewerElement).
The reason that there are 2 parameters is that 1) you may use different skybox 2) you may rotate the environment with environment-rotation attribute. One may use the shorthand environment as well.