.babylon files support for babylon-viewer

Feature requests
1

I would love to be able to load .babylon files into babylon-viewer directly. Or at least to have a helper function that can extract the mesh of interest from .babylon file and pass it to the viewer without loading the original full-weight babylon.js library. Because If I have to load BabylonJS anyway I can just set up my own scene and load .babylon files normally.
Related topic: Can I view .babylon files in babylon-viewer? - Questions - Babylon.js

2

You have my vote! I think it is a good one to do

Cc @ryantrem for awareness

4

What about a new babylon-glb approach? Hear me out…

GLB file that could be viewed/opened in other viewers.

The file could act as an asset container where the babylon scene is loaded via the Viewer (via .extras.babylon). Scene/Engine configuration is also loaded. Geometry and other assets in the GLB could be referenced, alternatively relative URLs? Obviously we would want to make the most of the GLB standards.

I keep questioning the backwards way of this idea but worth a discussion? We should also consider serialisation, efficiency and potentially bloat (if any) within babylon files?

I’m now creating an asset library/viewer from GLB files so it ties in. I’m excited to see Viewer 2 progress though.

1 Like
5

Do you mean the scene represented with .babylon constructs is embedded in the glb? I don’t think I’m quite following why this might be preferable to just loading .babylon files, but maybe I’m just missing something.

Today with the Babylon Viewer, if you are consuming the npm package and building your own bundle, you can in fact make it work with .babylon files quite easily. Specifically, you just need to import the Babylon loader, e.g. import "@babylonjs/core/Loading/Plugins/babylonFileLoader". Just be aware if you do this, it will statically include the Babylon file loader (and everything it depends on) in your bundle.

We have other work planned to allow the Babylon file loader to be dynamically imported (like other loaders from @babylonjs/loaders). Once that is done, bundler code splitting will separate it out and allow it to be downloaded only when needed.

This dynamic import support is what we need to enable this in the pre-bundled Babylon Viewer that can be loaded directly into a webpage from CDN.

So in summary: If you are building your own bundle, it’s already possible to load .babylon files (with additional imports). If you are using the pre-bundled Babylon Viewer via CDN, then we have plans that will enable loading .babylon files.

1 Like
6

Exactly - both.

I don’t think we have much influence over GLTF standards, extras is a way for us to embed data. I propose a simple data standard (based from .babylon constructs like you say, keep it limited and simple). Some cases:

  • For users to facilitate babylon “features” in the Viewer via GLBs such as:
    • Hotspot annotations (imagine in SharePoint where you don’t have to bridge/maintain features you may develop on the viewer).
    • Default settings for any class/object etc.
    • PointCloud view settings.
    • Empty nodes in the GLB could act as proxies for special babylon objects such as skybox, particles etc.
    • Instances can be set to thin.
    • Potential future logic nodes like a Pre-fab or Blueprint.
  • Not impose the .babylon format, but effectively provide a data standard and enable compatibility, without affecting integrity of the GLB.

This effort could act as proof-of-concepts towards developing GLB data/standards. If one day they decide to implement an annotation/hotspot data standard then we can depreciate the functionality through .extras and implement through the GLB read functionality.

I think this is just all food-for-thought but if I requested the SharePoint bjs viewer to fully support .babylon files, would Microsoft have concerns over this?

Embedding babylon data in GLB enables it to be an interchangeable/interoperable format. Of course there’s nothing stopping anyone doing this themselves but should this be officially supported?

1 Like
7

I think using glTF extras for Babylon (Viewer) concepts that don’t exist in glTF, like hotspots, could make sense. For any data that already has a standard glTF representation (like meshes), I don’t think I would want to stuff that into extras. If there was enough interest in being able to view .babylon files in OneDrive, I’d want to just see if we could add direct .babylon file extension support first.

2 Likes