New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web-based client-side preview and validation #1081

Open
emackey opened this Issue Aug 28, 2017 · 13 comments

Comments

Projects
None yet
5 participants
@emackey
Member

emackey commented Aug 28, 2017

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

This comment has been minimized.

Member

donmccurdy commented Aug 29, 2017

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

This comment has been minimized.

Member

emackey commented Aug 29, 2017

@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

This comment has been minimized.

Member

pjcozzi commented Aug 29, 2017

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

This comment has been minimized.

Member

pjcozzi commented Aug 29, 2017

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

@emackey

This comment has been minimized.

Member

emackey commented Aug 29, 2017

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

This comment has been minimized.

alteous commented Aug 31, 2017

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

This comment has been minimized.

alteous commented Aug 31, 2017

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

@bwasty

This comment has been minimized.

bwasty commented Oct 2, 2017

@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

This comment has been minimized.

Member

donmccurdy commented Nov 11, 2017

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

This comment has been minimized.

Member

pjcozzi commented Nov 12, 2017

@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

This comment has been minimized.

Member

emackey commented Nov 12, 2017

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

This comment has been minimized.

Member

donmccurdy commented Nov 16, 2017

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

This comment has been minimized.

Member

emackey commented Nov 16, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment