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...?