search

google / draco

Draco is a library for compressing and decompressing 3D geometric meshes and point clouds. It is intended to improve the storage and transmission of 3D graphics.
https://google.github.io/draco/
Apache License 2.0
6.53k stars 967 forks source link

1.4 release throws RuntimeError in the browser console #653

Closed majksner closed 3 years ago

majksner commented 3 years ago

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.

Screenshot 2020-12-02 at 14 33 14
FrankGalligan commented 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)?

majksner commented 3 years ago

@FrankGalligan it is happening for all my models and they are glTF draco models.

FrankGalligan commented 3 years ago

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?

majksner commented 3 years ago

Here is the file.

surfaces.min.zip

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. image

Other file https://www.gstatic.com/draco/v1/decoders/draco_decoder.wasm has yesterday's last-modified date. image

FrankGalligan commented 3 years ago

Hmmm that is weird. Let me try your file.

FrankGalligan commented 3 years ago

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.

donmccurdy commented 3 years ago

Do you mind checking this file against three.js with 1.4.0?

BusterDrone.glb.zip

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.

majksner commented 3 years ago

@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!

FrankGalligan commented 3 years ago

@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.

FrankGalligan commented 3 years ago

@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.

camnewnham commented 3 years ago

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.

adraffy commented 3 years ago

Same, all my projects that depended on this are now broken.

donmccurdy commented 3 years ago

If you're using the evergreen URL hosted on the CDN, you may want to pin the URL to the previous version for now:

camnewnham commented 3 years ago

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();
FrankGalligan commented 3 years ago

I still cannot reproduce the error on airshaper or elsewhere.

Anyone else have steps I can try?

Thanks

majksner commented 3 years ago

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

Screenshot 2020-12-03 at 08 17 05
majksner commented 3 years ago

Using https://www.gstatic.com/draco/versioned/decoders/1.3.6/ fixes the problem for me as well.

FrankGalligan commented 3 years ago

Thanks @majksner I will have to see if we can lock the two files form the CDN side when we do an update.

willkelleher commented 3 years ago

Is it possible to also mention the versioned CDN paths in the documentation? I wasn't aware this was available.

FrankGalligan commented 3 years ago

@willkelleher We will. Up until now we thought it would be better for most projects to pull the unversioned files because:

  1. Projects could get bug fixes & performance improvements automatically.
  2. We were worried projects would pull stale files or use stale documentation saying get version X when the current version is Z.

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.

Cotterzz commented 3 years ago

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)

FrankGalligan commented 3 years ago

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 .

Cotterzz commented 3 years ago

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.

FrankGalligan commented 3 years ago

@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.

FrankGalligan commented 3 years ago

@majksner Can you try changing your path to https://www.gstatic.com/draco/versioned/decoders/1.4.0/

You shouldn't have a mismatch.

majksner commented 3 years ago

@FrankGalligan will give it a try tomorrow.

majksner commented 3 years ago

@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

tomfinegan commented 3 years ago

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.