Can no longer compile aircraft

:green_circle: Required

Have you used Developer Mode?
yes
PC Specs:
i7 32 GB, 1080 Nvidia
Aircraft:
My own
Area of the World / Flight Plan:

Airport (If applicable):

Feedback/Bug Description:
I can no longer compile my aircraft for use in the sim. get console errors that don’t point to what is wrong - cryptic error message

Invalid data (INF, -INF or NAN). In bufferView[1052]: ‘’ for accessor[1052]: ‘’

many many lines like this. Worked before SU7 beta.

:yellow_circle: Optional

[ ] Multiplayer session or [ ] solo flight

Multiplayer settings: [ ] Live Players [ ] All Players [ ] Group Only

Weather settings:

3rd party addons you were using at the time:

Server: [ ] East USA [ ] North Europe [ ] West USA [ ] West Europe [ ] SE Asia

Peripherals:

(PC) Are you using DX12?:

I’m having a similar problem. Says the model.cfg is missing which it isn’t, and not updating the layout.json, or creating it if I do a clean all

1 Like

Hi there,

These errors are an extra validation step added to our build process to detect issues in the .bin files associated to your .gltf which could create visual artefacts upon rendering. What this means is that the .bin file contains values which are either “infinite”, “-infinite” or even “not a number” - this probably comes from an issue/bug in the exporter you are using to create the .gltf.

You can check the said values using Visual Studio Code and the “glTF Tools” extension:
1/ Open the glTF in VSCode
2/ Since it will probably appear on one single line, use Shift+Alt+F to format the document
3/ Search for “accessors” and put your cursor in the first one you see.


4/ See in the navigation bar the bit that ends with “[ ] accessors > { } 0” - it means you are in the first element of the accessors array. Click on the “{ } 0” part and you’ll be able to browse to the ones mentioned in the Console:

5/ Right click in the element and press Alt + D (or right click and glTF > Inspect Data). You’ll see the values stored in the buffer in the “INSPECT DATA” window.
image
Chances are you’ll find odd/wrong/corrupted values in there.

Fixing these values will then depend on the modelling software and/or exporter you are using so it will be tricky to help further without a bit more information about them.

Best regards,

Eric / Asobo

1 Like

Would you be able to send your package sources through PM so that we can assess what the issue is?

Best regards,

Eric / Asobo

Thank-you for the response,

Seems this error is due to the Khronos Blender export core code. The mesh COLOR_ accessors are storing the values an normalized unsigned integers rather than floats. This was not an issue with SU6, but something has changed with SU7 to validate this data.

The Khronos code is doing the following:

def __gather_colors_new_khronos_function_not_used_for_msfs(blender_primitive, export_settings):
    attributes = {}
    if export_settings[gltf2_blender_export_keys.COLORS]:
        color_index = 0
        color_id = 'COLOR_' + str(color_index)
        while blender_primitive["attributes"].get(color_id) is not None:
            colors = blender_primitive["attributes"][color_id]

            if type(colors) is not np.ndarray:
                colors = np.array(colors, dtype=np.float32)
                colors = colors.reshape(len(colors) // 4, 4)

            # Convert to normalized ushorts
            colors *= 65535
            colors += 0.5  # bias for rounding
            colors = colors.astype(np.uint16)

            attributes[color_id] = gltf2_io.Accessor(
                buffer_view=gltf2_io_binary_data.BinaryData(colors.tobytes()),
                byte_offset=None,
                component_type=gltf2_io_constants.ComponentType.UnsignedShort,
                count=len(colors),
                extensions=None,
                extras=None,
                max=None,
                min=None,
                name=None,
                normalized=True,
                sparse=None,
                type=gltf2_io_constants.DataType.Vec4,
            )
            color_index += 1
            color_id = 'COLOR_' + str(color_index)
    return attributes

I might be wrong but this is the code I see in the vanilla glTF exporter that comes with Blender:

def __gather_colors(blender_primitive, export_settings):
    attributes = {}
    if export_settings[gltf2_blender_export_keys.COLORS]:
        color_index = 0
        color_id = 'COLOR_' + str(color_index)
        while blender_primitive["attributes"].get(color_id) is not None:
            internal_color = blender_primitive["attributes"][color_id]
            attributes[color_id] = gltf2_io.Accessor(
                buffer_view=gltf2_io_binary_data.BinaryData.from_list(
                    internal_color, gltf2_io_constants.ComponentType.Float),
                byte_offset=None,
                component_type=gltf2_io_constants.ComponentType.Float,
                count=len(internal_color) // gltf2_io_constants.DataType.num_elements(gltf2_io_constants.DataType.Vec4),
                extensions=None,
                extras=None,
                max=None,
                min=None,
                name=None,
                normalized=None,
                sparse=None,
                type=gltf2_io_constants.DataType.Vec4
            )
            color_index += 1
            color_id = 'COLOR_' + str(color_index)
    return attributes

Aren’t you using some customised exporter ?

Best regards,

Eric / Asobo

I have modified the vitus blender exporter to use the latest Khronos core exporter code on their GitHub site. So Khronos has made this change to their V2.0 Gltf standard.

This function is not compatible with your SU7 update, it did not error out on SU6. So I changed it back to floats and not to use the “normalization” code to unsigned int.

Yes the blender default gltf code is NOT compatible with msfs as you have all the extra Asobo extensions that are required, like dds

The update Khronos gltf ver 2.0.1 shows the following - I would assume this change would affect your babylon.js exporter for 3DS MAX, if you update it. So beware. See COLOR vec4 datatype - I believe this is new compared to your existing standard. If not I’d like to know why it errors out now.

The issue has been confirmed and fixed on our side - unfortunately I don’t know yet when this will be integrated into the sim.
Thanks a lot for the report and apologies for the trouble.

Best regards,

Eric / Asobo

Does this mean that the COLOR_ accessor values are to be normalized unsigned ints and NOT floats?

I can accommodate both, just that the Vitus exporter that everyone uses has Vec4 as floats.

Once the package is built its “optimized” glTFs will always use floats. But our package builder will accept both unsigned shorts and floats as inputs.
It’s then up to you to choose what the exporter should do (I personnally believe it should stick to the standard).

Best regards,

Eric / Asobo

1 Like

Issue no longer occurs.