Closed majksner closed 3 years ago
Hi @majksner Is this happening with all of your 3d models?
Are you trying to display glTF draco models? Or only draco models (I.e. .drc files)?
@FrankGalligan it is happening for all my models and they are glTF draco models.
I have tested https://threejs.org/examples/?q=gltf#webgl_loader_gltf_extensions with 1.4.0 and I haven't seen any issues.
Do you have a glTF draco file I could try which exhibits the issue?
Here is the file.
I've also noticed something weird in the response headers from https://www.gstatic.com/draco/v1/decoders/draco_wasm_wrapper.js see image below, especially last-modified header.
Other file https://www.gstatic.com/draco/v1/decoders/draco_decoder.wasm has yesterday's last-modified date.
Hmmm that is weird. Let me try your file.
So I tried your file in three.js using 1.4.0 and it rendered. Looked like some kind rainbow sports car.
I also checked the links for draco_decoder.wasm and draco_wasm_wrapper.js from https://www.gstatic.com/draco/v1/decoders/ and it looks like it is serving the correct files.
Can you try clearing your cache and see it that fixes the issue?
Also do yo have link to your website that is public? I could try that as well.
Do you mind checking this file against three.js with 1.4.0?
I am having trouble with it in a non-three.js loader using 1.4.0 (and which I can't readily test against older Draco builds), which could easily be my own fault, but it did work in three.js with an older version of Draco.
@FrankGalligan here is the public link where you can check. I don't think it is a cache problem as I have developer tools open with disabled cache option. I can replicate issue with multiple different devices, iPad, Linux and Mac, Firefox, Safari, Chrome.
Thanks for checking!
@majksner I tried your link. I think it worked. I saw the same sports cars but it was blue and red, not rainbow like I saw locally.
@donmccurdy I tried your file locally with three.js using 1.4.0 and it worked fine for me. It was some kind of animated three claw drone robot.
We're running into this issue too. Using the airshaper link @majksner posted I found:
Chrome profile 1: Loads correctly Chrome profile 2: No load (error) Incognito: No load (error)
Generally profile 1 is used for development so seems likely it would have cached it.
Clearing the cache of profile 1 results in it also no longer loading.
Same, all my projects that depended on this are now broken.
If you're using the evergreen URL hosted on the CDN, you may want to pin the URL to the previous version for now:
https://www.gstatic.com/draco/versioned/decoders/1.3.6/
https://www.gstatic.com/draco/versioned/decoders/1.4.0/
Thanks @donmccurdy making that change to the draco loader is working for us as a temporary fix.
// Preload Draco
const draco = new DRACOLoader()
.setDecoderPath("https://www.gstatic.com/draco/versioned/decoders/1.3.6/")
.preload();
I still cannot reproduce the error on airshaper or elsewhere.
Anyone else have steps I can try?
Thanks
I think that issue has to do with the CDN caching. For me, it loads draco_wasm_wrapper.js that has a header with the last-modified date of Tue, 03 Mar 2020 16:55:20 GMT which is an old version and then not compatible with the version of draco_encoder.wasm which has the last-modified | Tue, 01 Dec 2020 21:53:06 GMT
See the screenshot below of the diff between version from CDN https://www.gstatic.com/draco/v1/decoders vs one from https://github.com/google/draco/blob/master/javascript/draco_wasm_wrapper.js
Using https://www.gstatic.com/draco/versioned/decoders/1.3.6/ fixes the problem for me as well.
Thanks @majksner I will have to see if we can lock the two files form the CDN side when we do an update.
Is it possible to also mention the versioned CDN paths in the documentation? I wasn't aware this was available.
@willkelleher We will. Up until now we thought it would be better for most projects to pull the unversioned files because:
But we didn't foresee this problem. We actually are not totally sure what is going on. My best guess is some proxy is holding on to a cached version of one file and not another.
What we do know is if we use the versioned URLs we shouldn't have this issue. But projects then are susceptible to 1 and 2 above. As a whole running into this issue is worse then 1 and 2, so we will change the documentation and examples to use the versioned URLs from now on. It will be the onus of the projects to update their URLs.
We will release a new version with those changes soon. Hopefully next week.
I think caching is preventing the issue, not causing it, clearing the cache on the problematic machine did nothing, but clearing it on the machine on which it had been working, caused the issue to begin. (as @camnewnham also found) @FrankGalligan - So replicating it on the machine it wasn't affecting was just a matter of clearing the browsing data manually (browsing history, download history, cookies and cached images/files) So yeah, caching is a red herring, it sounds as if you're just delivering the wrong combination of wasm and js wrapper, to anyone who's browser hasn't cached those files when the were correctly organised. (I'm on windows 10 64-bit, chrome and edge, both machines, asking for a specific draco version also fixed it for me)
I don't think it is serving the wrong versions. We have had a lot of people try and we always get the correct version.
Can anyone else try?
Open Chrome developers tools. Then download both files: https://www.gstatic.com/draco/v1/decoders/draco_wasm_wrapper.js https://www.gstatic.com/draco/v1/decoders/draco_decoder.wasm
Then in the network tab you can click on the file and check the "last-modified" date in the Headers section.
On Sun, Dec 6, 2020 at 11:38 AM John Cotterell notifications@github.com wrote:
I think caching is preventing the issue, not causing it, clearing the cache on the problematic machine did nothing, but clearing it on the machine on which it had been working, caused the issue to begin. (as @camnewnham https://github.com/camnewnham also found) So replicating it on the machine it wasn't affecting was just a matter of clearing the browsing data manually (browsing history, download history, cookies and cached images/files) So yeah, caching is a red herring, it sounds as if you're just delivering the wrong combination of wasm and js wrapper, to anyone who's browser hasn't cached those files when the were correctly organised. (I'm on windows 10 64-bit, chrome and edge, both machines, asking for a specific draco version also fixed it for me)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/draco/issues/653#issuecomment-739552113, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEY2JT6UAJO3ZQFPEUTR4TSTPMT7ANCNFSM4UKQFTNA .
Clearing cache, and viewing the wasm directly, i still get the one last modified in march. And like I said, in one case this only happened after i cleared the cache.
@Cotterzz I think in the one case you had 1.3.6 unversioned URLs. Then cleared your cache. No you get 1.4.0 for one file and 1.3.6 for the other file. From a proxy that has cached one file and not the other. Most likely base on file type.
@majksner Can you try changing your path to https://www.gstatic.com/draco/versioned/decoders/1.4.0/
You shouldn't have a mismatch.
@FrankGalligan will give it a try tomorrow.
@FrankGalligan I can confirm that using https://www.gstatic.com/draco/versioned/decoders/1.4.0/ works fine. Both files have the same last-modifed header. Tue, 01 Dec 2020 21:52:04 GMT
Documentation updates and moving to the versioned URLs seems to have sorted this out. Please reopen this, or open a new issue if there's still a problem.
Hi,
Seems like new release broke my 3d viewer that displays Draco compressed files. Anyone else has this issue?
I'm using https://www.gstatic.com/draco/v1/decoders/ to load .wasm files.