Preview failing for Babylon and Cesium in MacOS #58
Comments
|
+1. Mbp, High Sierra. On Babylon.js preview:
On Cesium: On three.js there's no error, but nothing shows up. WebGL is otherwise running fine on my computer so I'm thinking this is something local. |
|
Yeah there's a shortage of MacOS devices around here to test & debug. Trying to get that problem fixed first. |
|
Great to know. I’ve otherwise been loving the rest of the features and
singing this extension’s praises...
…On Wed, Nov 15, 2017 at 2:10 PM Ed Mackey ***@***.***> wrote:
Yeah there's a shortage of MacOS devices around here to test & debug.
Trying to get that problem fixed first.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#58 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKfQLoaA_aAgLf0vanIh_QGQl874V--9ks5s2zcAgaJpZM4QarnZ>
.
|
|
If you or @donmccurdy or any web developer reading this wants to take a stab before I manage to get my hands on someone else's hardware (just to borrow, of course), you can actually debug this directly from the market-installed extension, without building from source. The instructions for actually getting a Chrome DevTools open are sadly a bit convoluted in that they open the "wrong" DevTools before you get to the right one. But once you get there, you can check the network tab for errors, you can break on JavaScript exceptions, all the usual stuff. Of particular interest seems to be why the URI given for the |
|
That's a good lead - I have forced PTO next week, now I know what I'll be
using it for:)
…On Wed, Nov 15, 2017 at 3:22 PM, Ed Mackey ***@***.***> wrote:
If you or @donmccurdy <https://github.com/donmccurdy> or any web
developer reading this wants to take a stab before I manage to get my hands
on someone else's hardware (just to borrow, of course), you can actually
debug this directly from the market-installed extension, without building
from source. The instructions for actually getting a Chrome DevTools open
<https://github.com/AnalyticalGraphicsInc/gltf-vscode/blob/master/CONTRIBUTING.md#debugging-the-html-preview-window-in-vscode>
are sadly a bit convoluted in that they open the "wrong" DevTools before
you get to the right one. But once you get there, you can check the network
tab for errors, you can break on JavaScript exceptions, all the usual
stuff. Of particular interest seems to be why the URI given for the bin
file is not resolving. It's an Electron environment, so local filesystem
access is enabled. What's different about the bin uri compared to some of
the other uris that do resolve?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#58 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKfQLm2NPE-8AsGWhEBTFNWPRzxcD5PHks5s20gigaJpZM4QarnZ>
.
|
|
Same error in Ubuntu 17.10. |
|
|
|
I have a partial fix going in branch I'll write up a bug for them... it will be convoluted. Also I have thoughts for a workaround here, involving either |
|
Basically, on
But on Mac and Linux systems, there's no drive letter, so, the path ends up looking like a host-relative path, not a true absolute path:
This gets interpreted with completely the wrong protocol (the custom glTF preview protocol). The correct solution appears to be to add the intended protocol:
This fixes it for Cesium and ThreeJS. But Babylon makes a very poor assumption on this line right here, and gets confused by the presence of |
|
Oh look, I was wrong. Cesium messes up |
|
@MichaelHazani If you have a minute, please try out branch |
|
Checking! (Will update w/results shortly) |
|
Try pressing Option-P (what would be CTRL-P on Windows) and typing |
|
(Sorry for deleting the previous comment; I thought it was related to forgetting to yarn beforehand, but it persists and is probably unrelated) Getting the same stack on the Master branch. For posterity (because I deleted the previous message): |
|
What version of node is installed? I'm using 8.9.0, and older versions may not work. Are you opening the root folder of gltf-vscode in VSCode for this? (Meaning, you're not trying to "install" the extension from the source tree itself, right?) |
|
Hmm. Upgrading 8.7 to 9.2 didn't solve the issue - same errors. btw - @donmccurdy, have you had any luck loading and running the extension locally (on either branch)? I have a strong hunch this is a local problem. |
|
Also, this could still be a path error. Clearly, "out" doesn't belong there - the path should be "gltf-vscode/src/extension". But it's nontrivial to debug - I'm not sure where the config for that path is set... |
|
"out/src" is where the compiled files go. There's no |
|
Didn't realize I had to compile first! The local dev instructions in the VS Code docs could be clearer... Fundamentally I think you solved it - working on Babylon. Cesium is throwing an error because apparently the model uses a KHR extension (understandable), and still nothing on threejs - gonna try on a simpler model.
|
|
The Glad you got it working! And yes we expect the KHR extension message, we're going to add support for that to Cesium at some point. I think there's still some lingering initial scale/position problems in both the Cesium and ThreeJS viewers, I need to look into that too. |
|
Okay, got the simple red box from the sample models working on all three engines. Beautiful! If it's not too much trouble, please leave a note here when the extension is officially updated - can't wait to reload it and put it into everyday use. And thanks for shedding light on the VS Code extension dev process as well! |
|
Will do. I think this branch is basically ready to go, except that it's using a not-yet-official branch of Cesium. Once CesiumGS/cesium#5989 gets reviewed & merged, this will be ready. |
|
Published as |
Getting errors when trying to open sample models. I tested with the WaterBottle directory and tried previewing the
.glTFfiles:The text was updated successfully, but these errors were encountered: