Draco Submodule Should Point to Exact Version about dracopy HOT 5 OPEN

Hi Zevbo,

This seems like a very good suggestion! Would you mind trying to compile DracoPy like that and see if it fixes it for you?

from dracopy.

Sounds reasonable. I've cloned DracoPy to my machine and have the reference to the correct draco. How can I now recompile DracoPy?

from dracopy.

Shouldn't be too difficult hopefully! Make sure you have cmake installed and just do python setup.py develop if you are on windows or linux. If you are on a Mac, especially an M1 or M2, edit ./build-macos-arm.sh to work with your existing virutalenv and then run it. It will generate fat binaries that work on x86 and arm64.

from dracopy.

Wasn't too dificult, but alas it didn't fix my issue. This raises the concern that this is a different bug, though one I don't know the source of. Just to recount what I've seen:

• I can encode a PCD using DracoPy than decode it with the 1.5.2 draco_decoder binary from draco, and colors are correct
• If I decode it using three.js, also pointed to the 1.5.2 decoder, the colors are treated as if they are on a 0-1 scale, when they are really on 0-255, meaning all colors are either on or off
• With the point cloud I am currently trying to encode, the 25th byte in the drc file is 1. Using the draco_encoder binary, it is a 0. This is the only difference, and when I switch it back, colors are decoded correctly.

Wondering if somehow DracoPy accidentally encodes in that bit that it is a 0-1 scale?

from dracopy.

Hi Zevbo,

Good detective work! Hopefully I can look into this more in a bit, but check out this PR in the meantime. It might have a clue.

#32

from dracopy.