LoadAccessorData assumes the presence of nodes, which are optional

Describe the bug The glTF 2.0 spec says

glTF assets MAY define nodes, that is, the objects comprising the scene to render.

On import, if the glTF contains accessors, LoadAccessorData is called. It iterates over gltf.nodes without first checking whether it’s null, which it will be when there aren’t any nodes.

https://github.com/atteneder/glTFast/blob/6c9b3773e5f9fa72ab9540f761216f5f08efed28/Runtime/Scripts/GltfImport.cs#L2351

This throws an exception, which fails the Task and stops the rest of the import process.

Files

Here’s a glTF file with just an accessor and its dependencies which reproduces the issue:

{
    "asset": {
        "generator": "I wrote this by hand",
        "version": "2.0"
    },
    "accessors": [
        {
            "bufferView": 0,
            "componentType": 5126,
            "count": 1,
            "type": "SCALAR"
        }
    ],
    "bufferViews": [
        {
            "buffer": 0,
            "byteLength": 4,
            "byteOffset": 0
        }
    ],
    "buffers": [
        {
            "byteLength": 4,
            "uri": "data:application/gltf-buffer;base64,MTExMQ=="
        }
    ]
}

Side note: although dodgy, it’s technically valid a glTF with "uri": "data:application/gltf-buffer,1111", i.e. with the binary data as a plain ASCII string if all its bytes happen to be valid ASCII, but that triggers another bug in the data URI decoder.

To Reproduce Steps to reproduce the behavior:

1. Put the above glTF into a project’s Assets directory.
2. Observe that a NullReferenceException appears in the Unity console.

The same happens if the asset is loaded at runtime by URI.

Expected behavior The glTF asset is loaded without throwing an exception.

Screenshots N/A

Desktop (please complete the following information):

• glTFast version: 4.8.0
• Unity Editor version: 2020.3.28f1
• Render Pipeline and version: Built-in
• Platform: Presumably all, Windows & Editor tested.

Additional context

I basically copied and pasted most of this report from #417 as it’s the same bad assumption causing the problem.

[chrisdjali-wrld3d]

The one that’s been called EmbedBufferInvalid actually has a valid buffer. The official validator doesn’t complain about the file. Base64-encoding binary data in data URIs is optional. I’ve looked it up, and when base64 isn’t used, printable 7-bit ASCII characters that don’t interfere with anything else (e.g. not " as it’s a quoted string) are okay, but other octets need percent-encoding. Obviously it’s not used much, as for binary data, it’d be bigger than base64 on average, but it’s not invalid, so the name in that repo isn’t good.

[chrisdjali-wrld3d]

The ones I’ve uploaded so far are barely copyrightable (if they’re copyrightable at all) because they’re basically just the boilerplate required to make a glTF file in the first place, so feel free to use them as public domain or CC0.