Failure to decode some Draco data from glTF Sample Assets

[javagl]

First of all: Thanks for providing this library! This library is the only promising solution for decoding Draco in Java that I found until now. The context where I'm trying to use this library is for decoding Draco data from glTF assets. And I managed to decode several test assets. But there are two things that do not seem to work right now.
(I have not yet "deeply" investigated this - eventually, this issue may have to be split up into two separate issues).

Here is an archive that contains two Draco encoded files:

opeinize-drako-java issue data 2026-01-28.zip

They are extracted from the following glTF Sample Assets:

• https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/RiggedSimple
• https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/SunglassesKhronos

The files contain the data of the buffer view (as mentioned in their name) that contains the encoded data.

The following is a small test for reading these files and printing the corresponding draco meshes:

package de.javagl.jme.draco;

import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Arrays;

import dev.fileformat.drako.Draco;
import dev.fileformat.drako.DracoMesh;
import dev.fileformat.drako.PointAttribute;

public class JmeDracoTestOnly {
	public static void main(String[] args) throws Exception {
		readAndPrint("./data/RiggedSimple_bufferView4.bin");
		readAndPrint("./data/SunglassesKhronos_bufferView0.bin");
	}
	
	private static void readAndPrint(String fileName) throws Exception
	{
		byte[] bytes = Files.readAllBytes(Paths.get(fileName));
		DracoMesh dracoMesh = (DracoMesh) Draco.decode(bytes);
		System.out.println("dracoMesh " + dracoMesh);
		if (dracoMesh == null) {
			return;
		}
		int n = dracoMesh.getNumAttributes();
		for (int i = 0; i < n; i++) {
			PointAttribute attribute = dracoMesh.attribute(i);
			System.out.println("Attribute " + i + " is " + attribute);
			byte[] rawData = attribute.getBuffer().getBuffer();
			System.out.println("  First 100 bytes of raw data: " + Arrays.toString(Arrays.copyOf(rawData, 100)));
		}
		
	}
}

---

For the RiggedSimple_bufferView4.bin, the issue is that the data of the first attribute does not seem to be decoded. In particular, this is the data that is the JOINTS_0 attribute from the glTF file. So it is not one of the simple (position/normal/texcoord...) attributes. Instead, it is an attribute that contains the joint indices for vertex skinning, as unsigned short values. It prints

Attribute 0 is #0 4 : 4[4]
  First 100 bytes of raw data: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

I.e. the decoded data seems to be all zeros.

Note that this applies to all models that contain vertex skinning. So apparently, this type of data/attribute is not handled properly.

---

For the SunglassesKhronos_bufferView0.bin, there is another issue: Trying to read this data will return null. With some debugging, I found that the reason is that the quantizationBits that are read in SequentialQuantizationAttributeDecoder#decodeQuantizedDataInfo are invalid - they are -88 (turning into 168 with the signed conversion).

To my understanding, this part should reflect the ParseQuantizationBits from the spec, which is a U8, but I don't know where the wrong value is coming from right now.

---

One thing that will also (likely) prevent this data from being read properly: There is a bug in Unsafe#toFloatArray. The for-loop is checking i < ret.length, but that should be d < ret.length. For example, for a 3-element float[] ret array, it will only decode the first value.
(I could open a PR for this, but would wait for further feedback or thoughts here...)

[lexchou-aspose]

Thanks for the report.

This repository was ported from our internal tool, so I have to fix it in the C# version, then port it back, I'm looking into the issues you reported.

[javagl]

@lexchou-aspose Thanks for looking into it. The process of how this library was created (and specifically, which part of it is auto-generated or manually ported) is not entirely clear.

The issue until now describes three things that could be tracked individually:

• The skinning data being all zeros
• The quantization information not being read properly
• The bug in toFloatArray

The last one is very apparent when using this library to decode glTF models (some details in jMonkeyEngine/jmonkeyengine#2591 (comment) ).

And as mentioned in that comment: Depending on how much effort it is to fix each of these issues, it could be worthwhile to consider fixing the last one and publishing that as a version 1.4.3, if addressing the first ones takes more time. (There is no timeline for that linked PR either, but I wanted to make clear that the last one could literally be fixed by replacing i with d - I did that locally, and it resolved the issue)

[javagl]

Another issue, and I'm only adding this here because it might, at the core, be the same as (or at least related to) the issue of the skinning data being all zeros: When reading Draco data that contains unsigned short values, then the attribute buffers are all zeros as well.

Attached is a simple GLB model, and the corresponding .bin file of the Draco-encoded data.

unitSquare11x11_unsignedShortTexCoords-draco.zip

Reading an printing this with the snipped shown above will print

Reading ./data/unitSquare11x11_unsignedShortTexCoords-draco_bufferView1.bin
dracoMesh dev.fileformat.drako.DracoMesh@36f6e879
Attribute 0 is #0 0 : 9[3]
  First 100 bytes of raw data: [0, 2, 0, 63, 0, 2, 0, 63, 0, 0, 0, 0, 51, -53, -52, 62, 102, -102, 25, 63, 0, 0, 0, 0, 51, -53, -52, 62, 0, 2, 0, 63, 0, 0, 0, 0, 102, -102, -103, 62, 102, -102, 25, 63, 0, 0, 0, 0, 102, -102, -103, 62, -51, 50, 51, 63, 0, 0, 0, 0, 51, -53, -52, 62, -51, 50, 51, 63, 0, 0, 0, 0, 0, 2, 0, 63, 102, -102, 25, 63, 0, 0, 0, 0, 102, -102, 25, 63, 0, 2, 0, 63, 0, 0, 0, 0, 102, -102, 25, 63]
Attribute 1 is #1 1 : 9[3]
  First 100 bytes of raw data: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 0]
Attribute 2 is #2 3 : 4[2]
  First 100 bytes of raw data: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Showing that the texture coordinates (stored as unsigned short and supposed to be "normalized" to float later) are all zeros as well.

Maybe the general issue (both for the joints of the skinning data, as well as the unsigned short texture coordinates) is that the library does not properly handle non-float data...?

[lexchou-aspose]

The issues in SunglassesKhronos_bufferView0.bin is not caused by the wrong decoding in [SequentialQuantizationAttributeDecoder#decodeQuantizedDataInfo](https://github.com/openize-com/openize-drako-java/blob/4d99a762fbd2a167922bf3e27535b5651e114a30/src/decoder/dev/fileformat/drako/SequentialQuantizationAttributeDecoder.java#L66), but it used an unimplemented prediction scheme, I'll try to finish this today or tomorrow.

[lexchou-aspose]

@javagl
All these issues fixed, I'll deploy to maven tomorrow with version 1.4.4 (code including pom.xml are all ported).

[javagl]

@lexchou-aspose It's great to see that this was addressed so quickly! As mentioned in the linked PR: This project/repository did not appear to be really actively maintained, and I was concerned that bugs might not be addressed. But maybe that inactivity was mainly because this library was not yet used so widely. And I imagine that this could change quickly: It will probably soon be used in jMonkeyEngine, and of course, it will also be my first choice for Draco-support in JglTF.

(BTW: I have not yet investigated the details of the vertex skinning/JOINTS issue, and am curious to see whether this will also be resolved with the new release. Do you happen to know whether there have been any changes, beyond what I drafted in #8 ? )

EDIT: I Just saw that the release happened a few minutes ago. I'll give it a try ASAP.

[lexchou-aspose]

@javagl

I spent hours comparing the Draco C++ and Openize.Drako for .NET to track down the issue, and was finally able to resolve it. However, upon further review, I noticed that the change is identical to one in your pull request.

Given that this project was generated by my porting tool, I believe it's not practical for us to maintain it manually. My porter ensures that any bug fixes made in the Openize.Drako for .NET will be accurately reflected in the openize-drako-java. To manage bugs in this repository, I follow a specific workflow: fix the issue in the Openize.Drako for .NET, run the porter, and commit the changes to openize-drako-java.

This is why your PR was not merged. I have reviewed all of your files in openize-drako-java , and it appears that they are now correct.

[javagl]

The linked PR is clearly marked as a draft, and "not supposed to be merged". It was only what I found by debuggstepping through the decoding process. But it's impossible (for me) to say whether this is an appropriate fix or not.

For example: Maybe that getValues function is called elsewhere, with a different numEntries parameter than during the first call, meaning that it has to create a new, freshly initialized attribute? If that was the case, then the change from the PR could cause a regression. (From looking at Openize.Drako.Tests/UnitTest1.cs, there doesn't seem to be a really extensive test coverage...)

However: Aligning such implementations across C++/.NET/Java can be tricky. There certainly is a lot of "noise and unnecessary stuff" in this repository. And I considered to carve out the minimal set of classes, and assemble them into a small, clean package. But given the complexity of Draco itself, it would be nearly impossible to maintain something like this, even for the smallest bugfix in the original (C++ or .NET) repo.

Maybe, one day, Draco itself and the library will be ~100% stable and have ~100% test coverage. And at this point, one could extract the relevant classes from the auto-generated code, and create a new, clean package from that. For now, the approach of fixing bugs only in the .NET version (and relying on the porter to update the Java version) seems like the only reasonable path.

[javagl]

Just a short heads-up: From some first tests, it looks like all the issues have been resolved with the latest version. I'll try to confirm and check a few things, but it's looking good right now. (Will probably close this issue a bit later)

[javagl]

@lexchou-aspose Unfortunately, the fix from f518c12 was overwritten by some regeneration via 9363376#diff-df9524ffd208542f6e5b3911d8a3c22a05b24dc43716d480b30a9b9a5e274938R159

Apparently, the issue was not fixed in the "upstream" at https://github.com/openize-com/openize-drako-net/blob/93295d916dbe3ac98c89def60222901e56d8e9b7/Openize.Drako/Utils/Unsafe.cs#L220