Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grab draco3d from npm instead of gstatic #9841

Merged
merged 10 commits into from
Oct 1, 2021
Merged

Grab draco3d from npm instead of gstatic #9841

merged 10 commits into from
Oct 1, 2021

Conversation

ebogo1
Copy link
Contributor

@ebogo1 ebogo1 commented Sep 28, 2021

Band-aid fix for #9787.

This PR is a temporary workaround for streamlining all our third party libraries to come from npm. Unfortunately, as mentioned in the above issue, the draco3d npm package seems to have a bug with quantization so this PR introduces a regression by disabling quantization in our decodeDraco worker.

The examples on the draco3d repo instantiate the .wasm module using the Decoder API, but doing so with our current npm build system doesn't play nicely with rollup because the Decoder module requires Node built-in libraries (fs and path) which are missing at build time. Because of all this, the PR changes are:

  1. Add the draco3d npm package to package.json
  2. In the postinstall script, copy the wrapper (now named draco_decoder_nodejs.js instead of draco_wasm_wrapper.js) and .wasm file from node_modules/ to their original locations in Source/ThirdParty/.
  3. Comment out the lines dealing with quantization for meshes in the decodeDraco worker. A few specs failed because of this change so for now they are xit'd out.

This also updates Draco to 1.4.1.

@cesium-concierge
Copy link

Thanks for the pull request @ebogo1!

  • ✔️ Signed CLA found.
  • CHANGES.md was not updated.
    • If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

  • Cesium Viewer works.
  • Works in 2D/CV.
  • Works (or fails gracefully) in IE11.

dracoDecoder.SkipAttributeTransform(draco[attributesToSkip[i]]);
}
}
// var attributesToSkip = ["POSITION", "NORMAL", "COLOR", "TEX_COORD"];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lilleyse Is this ok to merge as is? I remember you suggested commenting out the line in Model.js instead? I think it was -

this._dequantizeInShader = defaultValue(options.dequantizeInShader, true);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is ok to merge as is.

Copy link
Contributor

@lilleyse lilleyse Sep 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, can we keep this code and only enable "NORMAL"? Since it is working for normals we may as well take what we can get.

@ebogo1
Copy link
Contributor Author

ebogo1 commented Sep 28, 2021

Looks like CI/specs are failing with a few more that I missed, I think those should be xit'd too:

1) loads Duck
     Scene/GltfLoader
2) adds a dequantization function
     Scene/ModelExperimental/DequantizationPipelineStage
3) adds dequantization uniforms
     Scene/ModelExperimental/DequantizationPipelineStage
4) prepares Draco model for dequantization stage
     Scene/ModelExperimental/GeometryPipelineStage

Comment on lines 279 to 284
// var attributesToSkip = ["POSITION", "NORMAL", "COLOR", "TEX_COORD"];
// if (parameters.dequantizeInShader) {
// for (var i = 0; i < attributesToSkip.length; ++i) {
// dracoDecoder.SkipAttributeTransform(draco[attributesToSkip[i]]);
// }
// }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To help keep the code clean let's delete this code and failing tests in a single isolated commit, then in a new issue mention that the commit should be reverted once the draco issue is fixed upstream and we update the npm package.

@lilleyse
Copy link
Contributor

I just want to emphasize that this PR is an unfortunate but necessary tradeoff that we hope is just temporary.

Geometry memory usage for 3D Tiles will double because we can no longer dequantize data on the GPU due to a bug in newer versions of draco google/draco#742. We can no longer use our older working version of Draco due to a requirement to move all third party libraries to npm, which is further complicated by the fact that older versions of draco on npm use asm.js instead of WebAssemly and aren't compatible with our web worker system.

@lilleyse
Copy link
Contributor

@ebogo1 just had an idea - even though draco will return the full decoded data now, we can still quantize the data ourselves in the worker so that we don't have to resort to doubling the memory usage. We'll just need to convert the Float32Array back to a Uint16Array or Uint8Array manually.

}
var range = max[0] - min[0];
for (i = 1; i < numComponents; ++i) {
range = Math.max(max[i] - min[i], range);
Copy link
Contributor Author

@ebogo1 ebogo1 Sep 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not what I expected - the draco source code says range is the "max delta over all components." I first thought this would mean the magnitude of max - min, but doing it this way matches the range returned by the decoder in main.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I didn't see this, maybe ignore my comment in the PR review 😅

Copy link
Contributor

@ptrgags ptrgags left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ebogo1 looks pretty good, though I'm noticing one problem with the NYC dataset, picking is now selecting way too many buildings:

Maybe check if the _BATCH_ID property is going down the correct path?

image

The milk truck model worked fine though!

Source/WorkersES6/decodeDraco.js Outdated Show resolved Hide resolved
@ptrgags
Copy link
Contributor

ptrgags commented Oct 1, 2021

@ebogo1 code looks good (aside from the tests that we want to temporarily remove). NYC dataset is picking correctly again!

let me know when you remove the broken tests and when you've documented what commits need to be reverted after draco is fixed, then I'll merge.

@ptrgags
Copy link
Contributor

ptrgags commented Oct 1, 2021

@ebogo1 changes look good, thanks!

@ptrgags ptrgags merged commit 1de05af into main Oct 1, 2021
@ptrgags ptrgags deleted the no-quantization branch October 1, 2021 14:58
@ebogo1
Copy link
Contributor Author

ebogo1 commented Oct 1, 2021

Thanks @ptrgags - I opened #9847 to follow up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants