-
Notifications
You must be signed in to change notification settings - Fork 971
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
certain files encoded with 1.3.6 cannot be decoded with 1.4.1 #704
Comments
I've tried the same using the 1.4.1 encoder. I didn't expect the 1.3.6 decoder to be able to decode it if there had been a change in the bitstream format, but the 1.4.1 decoder also fails on it. Reducing the quantization parameters to 24 allows both version of the decoders to read the file again. (R3DS Wrap uses 30 as a default value for the position, texture and normal quantization parameters, so these files exist in the wild. R3DS Wrap can also read files that it produces with those default parameters, which 1.3.6 can but 1.4.1 can't)
|
The previous version breaks on Fedora 34, and likely other distros with recent compilers due to not including cstddef and limits headers. This is already fixed upstream, but only in master. And looking at google/draco#704 there may be compatibility issues with using the latest code. So for now we're upgrading from 1.3.3 to 1.3.6 and adding the fix.
The previous version breaks on Fedora 34, and likely other distros with recent compilers due to not including cstddef and limits headers. This is already fixed upstream, but only in master. And looking at google/draco#704 there may be compatibility issues with using the latest code. So for now we're upgrading from 1.3.3 to 1.3.6 and adding the fix.
I encountered this issue in draco files produced by a third party application (R3DS Wrap), however I've reproduced it exclusively using version 1.3.6 and 1.4.1 of the draco releases.
Basically, if I encode a OBJ file with 1.3.6 and use quantization parameters higher than 25, the resulting draco fails to be able to be decoded and fails with "Failed to decode the input file Failed to decode point attributes."
I have not observed any obj file dependent behaviour.
The text was updated successfully, but these errors were encountered: