Add support for alternate 3D preview engines #8
Conversation
Renaming \pages\previewModel.* to pages\cesium.* Moving \Cesium\* to engines\Cesium\* Fixing references to those locations in the generated preview HTML.
(three.js not working yet)
Need to still do a gltf loader version selector for threejs
* Remove Three.js glTFLoader (glTF2Loader appears to be a superset and handles both versions) * Updated Three.js README to reflect this. * Better documented how the cleanup() functions work * Added warning UI to Cesium so that you can know if it has fallen back to loading the model from the file vs from the current editor tab content. * Minor commmenting improvements to previewModel.js * Style cleanup in three.js, and removed some additional unreferenced code. * Cesium.js: Can't use window.alert since window is sandboxed -- changed to window.onerror * Three.js: added disabled logic on cleanup to stop animation which fixed the error when switching away from Three.js rendering back to Cesium.
Updating the `cleanup()` logic for all of the engiens. Properly removes eventListeners, stops rendering loops, etc..
No longer necessary nwo that we have good debug instructions thanks to pull request AnalyticalGraphicsInc#7.
We're having issues with global namespace variables (like enabled) being overwritten by different engines, but callback methods from previous engines are referencing them. This is a temp fix. There will be a follow-up change that moves all js code into separate namespaces so that we don't get these conflicts.
Updated the logic for each of the engine preview handlers to use namespaces (declaring all logic within function/classes/objects) so that there can be no conflicts with any callback code that runs after the current preview engine has changed.
* Link the Three.js and Babylon.js logos to the respective websites * Moved the fadeIn/fadeOut/showWarning/clearWarning to be common. * Updated the content in previewModel.html to match the actual content from the provider.
|
Super exciting, thanks @HowardWolosky! |
|
I merged this into my
This turned out to be an easy change to make. I'm still planning to review a few more things, but I hope to be able to open a PR from |
|
Thanks -- I took a look at your change and it seemed not only reasonable, but a good idea. Any idea when you'll be pushing the glTF2.0 branch into master and publishing that to the extensions marketplace? |
|
@HowardWolosky Thanks! Hopefully I will get this all merged and deployed either tonight or tomorrow night. I realize the clock is ticking. |
|
This was published moments ago. Thanks again @HowardWolosky! |
Summary
At its core, this adds the ability to preview glTF models with three different engines:
Users have the ability to change the current preview engine on the fly via an embedded menu (using dat.gui, as well as being able to set what the default preview engine should be via a new VS Code setting.
The design of this change is a little complicated due to the limitations of VS Code preview windows as well as with the 3D engines themselves.
Known limitations
Overall design
VS Code preview windows cannot navigate to other files/pages within the same preview window. They also get reloaded any time you navigate away and back to them. You also can't access any URI that is registered within your VS Code extension.
Given all that, the preview window has a "content"
divthat dynamically changes what content it displays based on the currently selected 3D engine. We can't explicitly execute a script that that is being referenced by asrcattribute, and it _won't _be automatically executed when it gets dynamically inserted into thediv, but it will be executed if added to thehead.linkelements (for .css files) have the same issue. So...whenever we add new content to thediv, we check to see if there are anyscriptorlinkelements, and we add them to theheadso that they get executed. We'll remove them whenever the engine changes. Now, unfortunately, there are race conditions with this, so we can't dynamically insert/remove the 3D engine javascript files the way we do for the javascript that controls the "page" for the preview. So, those will always statically be loaded...we need to be sure that the engines are fully loaded before we dynamically insert any content that tries to reference them.Review notes
enginesfolder. So, you'll see a ton of file changes for the "Cesium" engine. There were no actual file content changes...the files were simply moved from<root>\Cesium\to<root>\engines\Cesium\.Resolves #5