Stationary camera I think just to use onProjectionMatrixChangedObservable, but I didn’t know about how to check for animations - even a rotation/position change on a mesh without using lots of observables. I’m supporting an isPaused parameter that leaves implementation up to caller. Nice work!
As it is written in the readme, “HTML3DElement will choose an underlying engine by default, and how it chooses will change over time.”
I am still wondering what does it mean
There is a comment in the viewerFactory.ts code referenced above about “fully” production ready. It is production ready, but I’m guessing that means 100% compatible. On the one hand it is nice how the CanvasViewerOptions type infers from “engine” value by discriminated union! Using a fallback required both as types. You can always do the check yourself and defer rendering with current implementation.
I thought about this, but so far I was leaning away from having it as a feature because it seems like it should be easy to do in the consuming code (e.g. hide the while loading so the user sees an image that the consuming code configured, and show the when loading is complete). I haven’t actually tried this though, so I don’t know for sure if it is as easy as it seems like it should be.
Great suggestion, I will add this to the feature list! And thanks for the pointer to existing code that does this!
It basically means we want WebGPU to be the default when the browser supports it, but we hit some problems and are not quite ready to commit to that. Most notably, we recently saw a big perf regression with WebGPU in Chrome when upgrading to MacOS 15 (such that WebGPU, even in snapshot rendering mode, performs worse than WebGL2).
I believe it is just one property which will not do any harm.
The final implementation may be similar to Sketchfab pages, where there are a lot of static images/screenshots which, when pointer is over, are showing loading progress and finally start to render 3D.
Moreover, it is quite easy to add to the future UI configurator the ability to create and save screenshots for such cases.
As for other features I think it is worth to think about something like configurable plugins or extensions for the Viewer. In this way the core will be compact as possible, and needed features may be plugged in with additional config and/or import.
Dare I say we could consider the inspector and playground to inherit this viewer class… Or the viewer is a class that can easily be initiated in code with global access/context of the web component. Plugins can then easily be imported into the viewer for ease of functionality (parsing and error handling for versions etc). I bet a lot of the work is already done but I’m imagining a basic Viewer will have extended functionality for importing glb, Babylon files, plugins, exporting etc. Playgrounds serve as the plugin repository (searchable). A playground should be easily package-able as a BJS plugin. For NME: it could be a click of a button to package a plugin for shaders, material collections, PostProcess logic etc. My thoughts are around more accessible and linked coding and production without setting up environments. Again a lot of this is already done, do we need to re-organise it.
Apologies, lots of words happen when you down a coffee!
Thanks, appreciate the feedback! I will go ahead and add this to the feature list. For the configurator part, would you expect it to just help you capture a screenshot and help you discover a preview-image attribute or something like that? Or would you expect more, like encoding the screenshot into a base64 data uri directly in the html snippet?
The Babylon API itself exposes “extension” points, such as adding new “file loaders” (scene loader plugins), glTF extensions, etc. Since the viewer exposes the Babylon API, my thought is people can already use those extension points without adding a new layer for this in the viewer itself. Additionally, we’ve been doing a lot of work around dynamic imports to keep the API simple (minimal or no configuration needed) and still only get the features you need/use.
If I’m following, I think your overall idea here is to be able to use existing tools (like Playground and NME) to create and test code snippets and be able to bring those snippets directly into the Viewer, is that right? Are you imagining you would just point the Viewer to a snippet id and it would be dynamically loaded, or that you would save the code and build/bundle it yourself, or what? I’m having a little bit of a hard time seeing concretely how these things could fit together.
Can you explain a bit more what you mean by “tag support?” We do have QuickLook in the potential feature list, which I think is the same as what you mean by “AR view on Apple platforms?”
Thanks everyone for all the feedback and thoughs, much appreciated!
Yes that’s it. I imagine the Viewer to always have a simple UI with optional (documented) functionalities, helpers and facility to import a Playground snippet. I suggest by the same URL parameter.
The Playground could define a namespace like this:
const gui = BABYLON.GUI.AdvancedDynamicTexture.CreateFullscreenUI("customUi");
const viewer = new BABYLON.Viewer({maxVersion: "10.0.1", gui: gui }); // Optional custom GUI so the default isn't constructed.
BABYLON.Viewer.register(viewer); // Picked-up by the actual Viewer app. Probably not required but you get the idea.
viewer.onInitialize = (canvas, engine) => { /* do stuff like load Assets or shaders, could be async and must return true or false? false is error. */ };
viewer.onModelLoaded = (scene) => { ... };
Not trying to complicate things but we could also have Extensions to dynamically extend:
const extensionA = new BABYLON.Extension();
BABYLON.Extension.register(extensionA); // Also picked-up by the Viewer and would be loaded before init finished
// Alternative way to dynamically register snippets like NME?
const extensionB = new BABYLON.Extension("https://nme.babylonjs.com/#GHS3I2");
BABYLON.Extension.register(extensionB);
Is it possible to set the rotation speed (scene.activeCamera.autoRotationBehavior.idleRotationSpeed)
together with camera-auto-orbit parameter in HTML element?
I guess you already noticed I added camera-auto-orbit Other attributes/properties that were recently added and are now in the latest build are:
camera-orbit (manually setting the camera orbit values)
camera-target (manually setting the camera target)
selected-animation (default animation index to select upon loading)
animation-auto-play (automatically plays the selected or default animation)
skybox-blur (how much to blur the skybox, from 0 to 1)
tone-mapping (the tone mapping mode, KHR PBR Neutral by default)
contrast (the post process contrast level)
exposure (the post process exposure level)
This is now fixed as well.
I didn’t add an attribute/property for this, but we can if it is valuable. It could either be a new attribute/property (e.g. camera-auto-orbit-speed), or we could allow camera-auto-orbit to be a number (meaning yes I want auto orbit and this is the speed I want).
It was quite popular question among ‘old’ viewer users - how to change the default rotation speed.
To have no abiility to change rotation speed without JS may be a bit confusing.
Hey folks, just wanted to provide an update on some recent progress on the Viewer:
Camera auto orbit speed and delay can now be specified through attributes/properties.
There is now a default progress bar, which can be styled or entirely replaced.
Inspector now works with the Viewer, though it is not yet included in the distribution or in the Viewer API. You can however consume both @babylonjs/viewer and @babylonjs/inspector and show the inspector within the viewer. Having an API in the viewer itself to show the inspector is still on the table but has some complexities and will come later.
The viewer HTML element now pauses the render loop when it is not visible within the browser viewport (thanks @brianzinn for the tips on this one!).
Static world space hotspots are now supported, there is default UI to focus on a hotspot, and there is a new custom element for creating 2D html annotations that track hotspots. (Note that hotspots are difficult to use right now until we finish the tooling to make it simple to configure them).
Very soon we will be working on more complete documentation as well!
I have the feeling that if there is no environment the light intensity could be bigger. As far as I understand, there is no direct way to set this value?
Also, I wonder what is the best way to have the environment without skybox and with transparent clearColor.
Correct, the Viewer itself does not expose any API for light intensity. I think once we get to that level of granularity, it is better to just do this directly through the BJS API.
It’s not possible with the Viewer API right now, but I think it should be. I will add this to the feature list.
There is now default UI for material variants, and an attribute for selecting the default variant:
Previously a double click/tap anywhere in the Viewer would reset the camera pose. Now, if you double click/tap on the model, it will reset the camera target to the hit position so you can easily move the camera around that point.
Panning sensitivity is now relative to the distance from the camera target, so that even when you zoom in close, you can still easily pan the camera.
A few other input handling updates to improve the experience on mobile devices.
Documentation is up next, and after that we intend to flip the switch and make the new Viewer be the default for the @babylonjs/viewer npm package.
Pending any other community feedback, we plan to flip the switch to remove the -alpha suffix, the @preview tag, and have the new Viewer package fully replace the old Viewer package on npmjs.org right after the new year.
