Closed i3roly closed 1 year ago
It might be that some resources referenced by the .gltf
file are failing to load, but the rest of the content appears. Have you opened the JavaScript console and network tab to look for failures or errors?
It might be that some resources referenced by the
.gltf
file are failing to load, but the rest of the content appears. Have you opened the JavaScript console and network tab to look for failures or errors?
i tried to find something, but the box pops up and then goes away once it starts loading.
check out https://www.g-a.ca and see what happens.
if you go to one of the 'bigger pages' (click the UM_1 link once you arrive at the main page), you'll see the box pop up quickly and then go away.
it is referencing this error in src/app.js:
https://github.com/donmccurdy/three-gltf-viewer/blob/main/src/app.js#L136
Is this this the UM_1 link you're referring to? https://www.g-a.ca/um1.html
I'm not seeing any errors or dialogs popping up when visiting the link myself.
That said — the JavaScript console in your browser's developer tab contains important information you'll need when developing and debugging web applications. You can open it before visiting a link, or open it and then refresh the page, and you may find more information about the error than the dialog box shows.
hey man @donmccurdy here's a video. in this case it's very brief but you can still see it.
sometimes if you click around it'll show up for a bit longer.
I see it in your video, but this isn't happening for me, sorry. There are no errors when I visit this page, either in popups or in the javascript console.
I would strongly urge you to open a javascript console, and the network tab in your browser's developer tools. Without the error messages those tools are designed to provide, there's nothing I can do to help you here.
i think the error is related to interrupting the loading page by going to another, because that's usually when this happens.
seems like this is what the screenie suggests?
Is the iframe on the page before iframeEl0.setAttribute('src', ...)
is called by your code? It may be that it begins to load something but is then interrupted when you set the src
attribute on the iframe.
When you mean called by my code do you mean the html?
All of the pages use the same format. Depending on how many rows I need, I set them to iframeEl0-iframeEl1.
So it is very possible for the page that is interrupted to be using the same iframe variable name as the new page, but with a different src argument.
Would this explain the issue? Should I use distinct iframe variable names for each page?
From: Don McCurdy Sent: Monday, 3 October 2022 6:51 AM To: donmccurdy/three-gltf-viewer Reply To: donmccurdy/three-gltf-viewer Cc: gagan sidhu; Author Subject: Re: [donmccurdy/three-gltf-viewer] optimal to call the viewer with locally-hosted gltf files (Issue #311)
Is the iframe on the page before iframeEl0.setAttribute('src', ...) is called by your code? It may be that it begins to load something but is then interrupted when you set the src attribute on the iframe.
— Reply to this email directly, view it on GitHubhttps://github.com/donmccurdy/three-gltf-viewer/issues/311#issuecomment-1265393432, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEG46WHS2HHZV7UAQQNDWBLJDVANCNFSM6AAAAAAQUG72UY. You are receiving this because you authored the thread.Message ID: @.***>
Never mind – I thought perhaps the iframe was added to the page before its src
was assigned. Looking at your code (below) that doesn't seem to be the issue. The variable names are fine.
var demoEl6 = document.querySelector('#rowone');
var iframeEl6 = document.createElement('iframe');
iframeEl6.setAttribute('src', '//www.g-a.ca/public#kiosk=1&model=../mapsgl/UM_1/h_map_dim7.gltf');
iframeEl6.style.width = '500px';
iframeEl6.setAttribute('height', '500px');
iframeEl6.setAttribute('frameborder', '0');
demoEl6.append(iframeEl6);
If you've made local changes to the viewer anyway, it might be easier just to remove the warnings. I'm not sure why you're seeing the popups unfortunately.
I don't think I've made any changes save enabling the skeleton mode as a default. I'll do a diff later but i'm pretty sure that's it
From: Don McCurdy Sent: Monday, 3 October 2022 7:12 AM To: donmccurdy/three-gltf-viewer Reply To: donmccurdy/three-gltf-viewer Cc: gagan sidhu; Author Subject: Re: [donmccurdy/three-gltf-viewer] optimal to call the viewer with locally-hosted gltf files (Issue #311)
If you've made local changes to the viewer anyway, it might be easier just to remove the warnings. I'm not sure why you're seeing the popups unfortunately.
— Reply to this email directly, view it on GitHubhttps://github.com/donmccurdy/three-gltf-viewer/issues/311#issuecomment-1265418085, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEG2XQRBL2CYXBOP5OV3WBLLSDANCNFSM6AAAAAAQUG72UY. You are receiving this because you authored the thread.Message ID: @.***>
I suggest making a change to remove these warnings. I added them to help people debug when pulling a (possibly invalid) model into my viewer, but it seems like they're causing more trouble than they're worth in your use case.
No trouble.
Was just wondering why it'd show up the odd time.
I admit I probably am pushing this thing to its intended limits.
Nobody is loading webpages in the tens of megabytes, let alone hundreds.
My best solution may be to find a faster webhost. I'll have to look into it.
From: Don McCurdy Sent: Monday, 3 October 2022 7:23 AM To: donmccurdy/three-gltf-viewer Reply To: donmccurdy/three-gltf-viewer Cc: gagan sidhu; Author Subject: Re: [donmccurdy/three-gltf-viewer] optimal to call the viewer with locally-hosted gltf files (Issue #311)
I suggest making a change to remove these warnings. I added them to help people debug when pulling a (possibly invalid) model into my viewer, but it seems like they're causing more trouble than they're worth in your use case.
— Reply to this email directly, view it on GitHubhttps://github.com/donmccurdy/three-gltf-viewer/issues/311#issuecomment-1265433996, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEG7ICLJVRERW3AP4T5DWBLM3VANCNFSM6AAAAAAQUG72UY. You are receiving this because you authored the thread.Message ID: @.***>
It'd also load faster with a viewer like https://modelviewer.dev/. The overhead of loading a separate iframe for each model is pretty heavy, and modelviewer (1) avoids iframes, and (2) does some other smart things to optimize for pages with multiple 3D models. However I don't think they'll support debugging options like wireframe mode and skeleton helpers.
If you try to view the gltf without skeleton mode, it's not helpful. Try it yourself.
As I understand it, webGL 2.0 or gltf files can't do transparent voxels easily, right?
That's why I use skeleton mode. Because without it all of the voxels that are intended to be transparent, obfuscate the ones that are coloured.
From: Don McCurdy Sent: Monday, 3 October 2022 7:29 AM To: donmccurdy/three-gltf-viewer Reply To: donmccurdy/three-gltf-viewer Cc: gagan sidhu; Author Subject: Re: [donmccurdy/three-gltf-viewer] optimal to call the viewer with locally-hosted gltf files (Issue #311)
It'd also load faster with a viewer like https://modelviewer.dev/. The overhead of loading a separate iframe for each model is pretty heavy, and modelviewer (1) avoids iframes, and (2) does some other smart things to optimize for pages with multiple 3D models. However I don't think they'll support debugging options like wireframe mode and skeleton helpers.
— Reply to this email directly, view it on GitHubhttps://github.com/donmccurdy/three-gltf-viewer/issues/311#issuecomment-1265441996, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEG2L7OY6C4OAD67QNR3WBLNRZANCNFSM6AAAAAAQUG72UY. You are receiving this because you authored the thread.Message ID: @.***>
Really, to me, while the iframes may incur some additional cpu time, it seems to me the throughput of my host is what limits the speed of the rendering.
Usually the viewer is there with a gray background until the gltf is fully received from the host.
From: Gagan Sidhu Sent: Monday, 3 October 2022 7:31 AM To: Don McCurdy Subject: Re: [donmccurdy/three-gltf-viewer] optimal to call the viewer with locally-hosted gltf files (Issue #311)
If you try to view the gltf without skeleton mode, it's not helpful. Try it yourself.
As I understand it, webGL 2.0 or gltf files can't do transparent voxels easily, right?
That's why I use skeleton mode. Because without it all of the voxels that are intended to be transparent, obfuscate the ones that are coloured.
From: Don McCurdy Sent: Monday, 3 October 2022 7:29 AM To: donmccurdy/three-gltf-viewer Reply To: donmccurdy/three-gltf-viewer Cc: gagan sidhu; Author Subject: Re: [donmccurdy/three-gltf-viewer] optimal to call the viewer with locally-hosted gltf files (Issue #311)
It'd also load faster with a viewer like https://modelviewer.dev/. The overhead of loading a separate iframe for each model is pretty heavy, and modelviewer (1) avoids iframes, and (2) does some other smart things to optimize for pages with multiple 3D models. However I don't think they'll support debugging options like wireframe mode and skeleton helpers.
— Reply to this email directly, view it on GitHubhttps://github.com/donmccurdy/three-gltf-viewer/issues/311#issuecomment-1265441996, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEG2L7OY6C4OAD67QNR3WBLNRZANCNFSM6AAAAAAQUG72UY. You are receiving this because you authored the thread.Message ID: @.***>
Just offering ideas. :)
As I understand it, webGL 2.0 or gltf files can't do transparent voxels easily, right?
Regardless of the graphics API or file format, I think most renderers would need some customization to render alpha blended voxels efficiently and without any edge cases. A renderer that supports alpha hashed transparency might do better, but I don't know of any on the web.
hi @donmccurdy,
hope you're doing well.
i noticed a little quirk when i'm using this amasing (lol) viewer.
when i have files hosted locally (on the server) and try to load them as follows:
i notice that the viewer will occasionally pop up with a javascript error that goes away once the files start loading:
"Unable to retrieve this file. Check JS console and browser network tab"
the way i'm doing it may be suboptimal.
the html file is sitting on the same server where the files and viewer are hosted.
as you can see i'm calling the viewer in a url-ish form which seems to be part of the issue (?).
this seems like something i'm doing wrong but i am hoping it's so obvious to you that you could make a recommendation.