Web-based client-side preview and validation

[emackey]

On a recent call, the working group expressed a desire for a web-based glTF preview and validation application. The wish-list for such an app could be along these lines:

• Drag-and-drop glTF model preview, similar to Don's gltf-viewer and the Babylon Sandbox, but with user-selectable display engines similar to the gltf-vscode extension.

• The glTF validator automatically runs as soon as any model is dropped, so that validation errors are visible alongside the model preview.

• Ideally, this all happens client-side, so that a clone of the app can work locally without any Internet connection. A local NodeJS server may still be required.

• Separately, a version of this app could be tied to a GitHub preview button, similar to Don's glTF-Browser-Extension.

Note that the VSCode extension implements its engine selection inside the HTML preview window, so it may be possible to re-use most of that code for this app. There's an issue open for adding full glTF validation (as opposed to the current JSON schema validation). But for VSCode, that validation would likely happen in the extension code, not in the HTML preview window. So that validation code will likely differ from client-side validation, but, they should both call the same gltf-validator npm package once that becomes available.

[donmccurdy]

To what extent can we combine/reuse code here? I'm not at all familiar with writing VSCode extensions... I'm open to forking my viewer as an official Khronos viewer, adding support for other engines, but if the existing VSCode HTML preview window or Babylon Sandbox would be better starting points I have no complaints about that either. 🙂

Ideally, this all happens client-side, so that a clone of the app can work locally without any Internet connection. A local NodeJS server may still be required.

I can't think of any reason a NodeJS server would be necessary. Keeping it static seems reasonable to me.

[emackey]

@donmccurdy The start of the glTF preview window happens in previewModel.html, which references several other files from the same folder. The contents of the main HTML have some template strings that get replaced at runtime before being loaded into the preview window, for example ${gltfContent} is replaced by actual JSON-encoded glTF content from the editor. So these files can't be used as-is outside of the extension, but they could be a useful starting point.

One other idea I had is that the different engines could be in an iframe below the main preview window, such that when the user switched preview engines they would essentially trigger a full page load inside the iframe. This would be cleaner but perhaps not as performant as the in-page switching that happens now, so it may be something to avoid rather than embrace.

[pjcozzi]

Thanks for the write-up, @emackey.

This would be incredibly useful to exporter and tools developers so that they can quickly test generated glTF models. I'll add:

• Start with preview using three.js, BabylonJS, or Cesium. Longer-term, we can add more engines so that both exporters and engines can get more testing.
• A super simple way (may just a link) for users to submit bugs about the engines or the spec.
• Is it useful and possible to have an Electron version that could be brought up from the command line with a given model? Could be useful for scripting.

[pjcozzi]

@cx20 your input would be valuable here as perhaps you could even use this in your testing.

[emackey]

Is it useful and possible to have an Electron version

@pjcozzi VSCode is an Electron app, so the existing glTF extension is basically the Electron version of this already. I'm sure it can be opened from a command line. It just needs the upgrade for the full validator.

[alteous]

In response to #1051 (comment)

It may be a reasonable option. What's the state of Rust-to-WASM pipeline?

It's still experimental as far as I'm aware, but there are projects such as cargo web which make Rust-to-WASM compilation simple.

[alteous]

wasm32-unknown-emscripten is currently a 'tier 2' platform, meaning code is guaranteed to build but not guaranteed to work in all scenarios.

[bwasty]

@lexaknyazev To answer the question about the Rust-to-WASM pipeline, I've created a small prototype:
https://gltf-rs.github.io/gltf-validator-web/
https://github.com/gltf-rs/gltf-validator-web

Arbitrary models can be loaded via URL parameter. The validation is the 'complete' validation layer of the gltf crate, which actually is pretty far from complete at the moment.

[donmccurdy]

I've started working on integrating glTF-Validator into my viewer (https://gltf-viewer.donmccurdy.com/). Filed some issues, but when they're resolved I don't think it will take long to set up.

Longer term, what end-state do we want? On the call this week we had discussed combined web viewing and validation in a single location once more, as proposed in the OP here. A strawman idea here, then:

1. I'll add validation reports to my three.js viewer.
2. I'll do some abstraction of the viewer code so that other engines can be included and selected from a dropdown. Each would need to support some subset of the current options shown, but not necessarily everything. Each engine being able to load drag-and-dropped models through Blob URLs would be a requirement I think (I'd rather not maintain forked versions of any engines for this).
3. Others can contribute engines, probably starting with BabylonJS and Cesium.
4. Re-name the whole thing to https://gltfviewer.io or something more official-sounding.

Thoughts? Also open to using VSCode as the starting point, i just have less idea about how to adapt it.

[pjcozzi]

@donmccurdy sounds great to me!!!

It does seem that there is a lot of redundancy between this and the VSCode plugin - and that I thought the original plan was to bring the VSCode plugin to the web instead of having two separate codebases for multi-engine viewer + validation, but I do not know enough about the implementation details to say if this is still feasible. Two separate codebases is probably not a huge deal in this case. @emackey?

[emackey]

Longer term, what end-state do we want?

Good question. I've been trying to wrap my head around the boundaries where a general-purpose web-based glTF viewer would share code with the VSCode extension. I imagine there could be some kind of "glTF viewer widget" sub-project that could be injected into a web page, that would preview the glTF in a variety of engines with various options for animations and backgrounds.

Some random thoughts:

• Once a glTF is loaded, it would be nice to have shared code/UI for engine selection, animation controls, wireframe, lights, and other viewing-related options.

• The outer framework is different: The VSCode version doesn't want much in the way of main menu or navigation, it's just an embedded preview window for a specific glTF file. The web-based version wants a more friendly welcome screen with a drag-and-drop target visible, and some kind of top-bar controls.

• The lifecycle is different: The web version stays in the browser a while, while the user looks for a file to drop and such. The VSCode version is much more temporary, it gets reloaded from scratch every time the user saves their glTF file from the editor, and generally it just wants to get the glTF preview up and running ASAP because it may be recovering from one of these complete reloads. Luckily all of its assets are local files.

• File access is different. The VSCode version in particular may try to load a glTF from in-memory contents, with references to external files on the local disk. The web version has to rely on the user to drop any needed files.

• Validation is different. In VSCode this is hooked up outside of the HTML preview window, running on the Electron framework directly and reporting its results to VSCode. The web-based version would need the validator to run in a web environment and report results back to the HTML window. There's likely no sharing to be done here, other than both projects have the same npm dependency on the validator itself.

Basically I think Don's existing web-based viewer is a better starting point for a web-based version simply because the thing has to sit on the open web and accept file drops. But I wonder if there's a reasonable way to break off the actual glTF viewing portion (not including validation, fetch/XHR, drag/drop, etc) as a sub-project that could be included in other projects like a VSCode preview window.

[donmccurdy]

Validation is available on https://gltf-viewer.donmccurdy.com/ now:

https://twitter.com/donrmccurdy/status/931049899038089216

---

Re widgetizing viewer portion: I'm not sure yet how feasible that is. There are HTML Custom Elements for three.js and now BabylonJS that do basic viewing nicely. It's also possible to iframe my viewer in "kiosk" mode:

<iframe src="https://gltf-viewer.donmccurdy.com#kiosk=1&amp;model=https://storage.googleapis.com/blocks-town/tmp/busterDrone/busterDrone.gltf" height="400px" frameborder="0" style="width: 100%;"></iframe>

But I'm guessing neither of those is much use to the VSCode preview window.

[emackey]

I haven't tried it, but I would expect such an iframe to work fine in the preview window. It's a Chromium-powered window. I couldn't take it as-is, though, because I have users who want access to glTF previews from disconnected networks (no CDNs, etc).

It may still make sense to keep these projects separate and only share "lessons learned," due to the different needs of the UI. But I will mention I've looked at source code of both your viewer and the Babylon Sandbox for good clues as to what I should be doing in the preview window. There may be code there already that bears a striking resemblance, particularly the changes that went in for the +z orientation fix.

[lexaknyazev]

@emackey @donmccurdy Can we close this?

[donmccurdy]

I think so, given ongoing work.

[pjcozzi]

Seems OK to me to close as well, especially given the recent validator VSCode extension integration.