decoded mesh with texture looks worse with cl=0 vs. the default cl=5 about draco HOT 5 CLOSED

Thanks for the report. Can you please also attach the encoded .drc file and the decoded .obj file? (for -cl 0 would be sufficient).

I tried to reproduce it on our end and I it worked as expected (no artifacts for either -cl 0 or -cl 5 (default)). It was on Linux though so it is possible, there is some windows specific bug, I'll investigate more.

from draco.

Sure, no problem. See below! Thanks for looking into it.
mesh_decoded.zip

from draco.

I also tried on Linux and confirm that this is a Windows specific bug. Linux results looks good on my end.

from draco.

Hi Dave,

Sorry it took so long. We were setting up a windows development machine. So we figured out what the issue is.

For some reason in your mesh_decoded.obj file the first line got messed up. Here are the first two lines:
mtllib ./mesh.obj.mtl usemtl material_0v -62.325630 -129.229721 -69.757767
v -61.428375 -129.248032 -71.479034

The problem is you only have a CR between material_0v -62.325630. If you add a windows line ending (LF) then your file works great. E.g.
mtllib ./mesh.obj.mtl
usemtl material_0
v -62.325630 -129.229721 -69.757767
v -61.428375 -129.248032 -71.479034

from draco.

No problem on the delay! Thank you for looking into this. I confirm the problem is indeed with line endings.

I was using Notepad++ on the decoded OBJ file so I could add back in the MTL lines. The file was bieng opened in "Macintosh" mode.

If I copy/paste all the lines into a new Notepad++ file (default is Dos\Windows format) and save the file... everything works again.

Thanks again for Draco! I am getting really good results with it so far.

from draco.