[BUG] While loading a GLTF file, an error occurs in the MemoryAccessor class, preventing the loading process. about sharpgltf

[nikeruga]

I contacted you with the information you provided.
Confirmed as a bug by pixyz
They say they will fix it.

[vpenades]

That's odd, what is failing is that the calculated bounds of the mesh don't match the ones stored in the file.

you can bypass the issue by doing this:

ModelRoot.Load("Monkey.glb", ValidationMode.Skip);

That will disable the validation checks on load.

This doesn't mean there's no issues with the model itself;

The accessor is reporting the data has these bounds:

axis	min	max
X	-5.352816E-06	5.352816E-06
Y	0	1
Z	-1	1
W	1	1

But there's an element with value:

axis	value
X	-9.244935E-18
Y	-9.681684E-17
Z	1
W	1

So the Y value is below the minimum value of 0 reported by the file.

It's not a critical issue and I suspect you can carry on by skipping the validation, but I guess it's worth to report this to the authors of the gltf exporter to avoid further issues.

[nikeruga]

"I haven't had much experience with 3D, so it's not easy. It might be a good idea to create code that initially opens with 'load(filename)' and then tries 'load(filename, valid)' in case an exception occurs. As you suggested, I will send a bug report to https://www.pixyz-software.com/ to have it checked."

[vpenades]

It might be a good idea to create code that initially opens with 'load(filename)' and then tries 'load(filename, valid)'

Then we would never had the opportunity to catch this issue of pixyz exporter...

Keep in mind most glTF importers and exporters are still incomplete, buggy and under development... so we have two choices: be strict, catch errors and fix them when they appear.... or try to skip and hide them... so they're never fixed.

I understand it's a bit painful, but I think being strict is the right choice in the long run.

[nikeruga]

The company does not see any problems in the Validator below.
I received a reply asking me to check.

https://github.khronos.org/glTF-Validator/

[vpenades]

Really? You can report this back to them:

https://github.khronos.org/glTF-Validator/ is the website frontend, the actual project repository is located here and you can download the command line gltf-validator from here

I ran glTF-Validator (command line) against the model you provided 'Monkey.glb' and it produces this report:

Monkey.glb full report

The report header is:

"uri": "Monkey.glb",
    "mimeType": "model/gltf-binary",
    "validatorVersion": "2.0.0-dev.3.8",
    "issues": {
        "numErrors": 21509,
        "numWarnings": 0,
        "numInfos": 25966,
        "numHints": 0,

So gltf-Validator is reporting that Monkey.glb has 21509 errors, which is far from fine.

Most of the errors are related to accessor bounds being incorrectly calculated, which is the same error SharpGLTF is detecting.

{
    "code": "ACCESSOR_MIN_MISMATCH",
    "message": "Declared minimum value for this component (-0.0) does not match actual minimum (-9.622668166445726e-17).",
    "severity": 0,
    "pointer": "/accessors/15217/min/1"
},
{
    "code": "ACCESSOR_ELEMENT_OUT_OF_MIN_BOUND",
    "message": "Accessor contains 38 element(s) less than declared minimum value -0.0.",
    "severity": 0,
    "pointer": "/accessors/15217/min/1"
},

I suspect what they did was to pass the .GLTF file to the gltf-validator website, without dragging the .BIN, so gltf validator only checks the structure layout and not the actual data, which is located in the .BIN file... that's why I used the .GLB file so it performs a full validation.

In any case, I can assure you that the model is not well formed and has internal errors. These errors are not critical since not many libraries use the accessor bounds, but they're errors nonetheless.