Quick3D materials can lead to unbound vertex input attributes with models that do not provide all possible attributes

Take a model like teapot.mesh that does not provide tangents and binormals (so no attr_textan or attr_binorm are provided in the mesh).

If this now gets used together with a default material that has the shader code paths for tangents etc. enabled, the resulting shader will have vertex inputs for attr_textan and others:

        if (includeSSAOSSDOVars || specularEnabled || metalnessEnabled || hasIblProbe || enableBumpNormal)
            vertexShader.generateVarTangentAndBinormal();

leads to shader code like this:

layout(location = 0) in vec3 attr_binormal;
layout(location = 1) in vec3 attr_textan;
layout(location = 2) in vec3 attr_pos;
layout(location = 3) in vec3 attr_norm

From the graphics APIs perspective this will mean that there will be vertex input entries that will not be bound to any actual data. (with the teapot example, only attr_pos and attr_norm will be specified in the input layout for the pipeline, simply because that's what the teapot provides)

This is incompatible with most graphics APIs: In D3D and Metal this is a fatal error. In Vulkan it is a validation error (causing a warning from the validation layer), although it is handled gracefully otherwise. With OpenGL it is silently accepted, with reads to the unspecified vertex inputs resulting in reading a value of 0 (presumably).

We need to figure out something. Probably using the shader key to include more information about the subsetRenderable.

Right now this means that it is impossible to run a scene correctly on Metal and D3D with models not providing all attributes, while using features that cause the (includeSSAOSSDOVars || specularEnabled || metalnessEnabled || hasIblProbe || enableBumpNormal) condition in the default material generator to evaluate to true.