Improve stream handling in Viewer and GraphEditor

[kwokcb]

Issue

Fixes #1495
Fixed #1494

• The glTF loader does not load in multiple texcoords so can't use them if they exist. It does for colors.
• Both the Viewer and GraphEditor force all texcoord node lookups to be 0 so no other set can be used.

Fixes

• Update Mesh class to create "fallback" streams if not found. This is similar action to what the Web Viewer does using three.js. Will handle if normal, tangent, bitangent or color or texcoord sets do not exist. Missing texcoord sets map to texcoord set 0. Missing color sets map to position.
• Change Glsl and Msl renderers to create fallbacks if needed.

Tests

glTF Texcoord Test

• MultiUVTest from glTF Sample Repository. Uses existing texcoord set 1 from glTF file.

<?xml version="1.0"?>
<materialx version="1.38">
  <gltf_pbr name="SHD_Material" type="surfaceshader" xpos="13.768116" ypos="-0.672414">
    <input name="base_color" type="color3" nodename="image_basecolor" />
    <input name="metallic" type="float" value="1" />
    <input name="roughness" type="float" value="1" />
    <input name="occlusion" type="float" value="1" />
    <input name="emissive" type="color3" nodename="image_emission" />
  </gltf_pbr>
  <surfacematerial name="MAT_Material" type="material" xpos="17.391304" ypos="0.000000">
    <input name="surfaceshader" type="surfaceshader" nodename="SHD_Material" />
  </surfacematerial>
  <gltf_image name="image_basecolor" type="color3" xpos="10.144928" ypos="-0.896552">
    <input name="file" type="filename" value="uv0.png" colorspace="srgb_texture" />
  </gltf_image>
  <gltf_image name="image_emission" type="color3" xpos="10.144928" ypos="0.422414">
    <input name="file" type="filename" value="uv1.png" colorspace="srgb_texture" />
    <input name="texcoord" type="vector2" nodename="texcoord" />
  </gltf_image>
  <texcoord name="texcoord" type="vector2" xpos="6.463768" ypos="-0.517241">
    <input name="index" type="integer" value="1" />
  </texcoord>
</materialx>

Missing Stream Test

<?xml version="1.0"?>
<materialx version="1.38">
  <texcoord name="texcoord" type="vector2" xpos="8.666667" ypos="0.870690">
    <input name="index" type="integer" value="10" />
  </texcoord>
  <geomcolor name="geomcolor_color3" type="color3" xpos="8.434783" ypos="-0.810345">
    <input name="index" type="integer" value="100" />
  </geomcolor>
  <checkerboard name="checkerboard_color3" type="color3" xpos="10.637681" ypos="1.146552">
    <input name="texcoord" type="vector2" nodename="texcoord" />
    <input name="uvtiling" type="vector2" value="20, 20" />
    <input name="color1" type="color3" value="0.374083, 0.368595, 0.368595" />
  </checkerboard>
  <surface_unlit name="surface_unlit" type="surfaceshader" xpos="13.797101" ypos="-2.258621">
    <input name="emission_color" type="color3" nodename="geomcolor_color3" />
  </surface_unlit>
  <surface_unlit name="surface_unlit2" type="surfaceshader" xpos="14.000000" ypos="0.931035">
    <input name="emission_color" type="color3" nodename="checkerboard_color3" />
  </surface_unlit>
  <tangent name="tangent_vector3" type="vector3" xpos="8.884058" ypos="3.206897">
    <input name="index" type="integer" value="34" />
  </tangent>
  <bitangent name="bitangent_vector3" type="vector3" xpos="8.565217" ypos="5.801724">
    <input name="index" type="integer" value="200" />
  </bitangent>
  <convert name="convert_vector3_surfaceshader" type="surfaceshader" xpos="12.326087" ypos="3.758621">
    <input name="in" type="vector3" nodename="tangent_vector3" />
  </convert>
  <convert name="convert_vector3_surfaceshader2" type="surfaceshader" xpos="12.028986" ypos="6.232759">
    <input name="in" type="vector3" nodename="bitangent_vector3" />
  </convert>
  <surfacematerial name="surfacematerial" type="material" xpos="16.463768" ypos="-1.620690">
    <input name="surfaceshader" type="surfaceshader" nodename="surface_unlit" />
  </surfacematerial>
  <surfacematerial name="surfacematerial2" type="material" xpos="16.434782" ypos="0.439655">
    <input name="surfaceshader" type="surfaceshader" nodename="surface_unlit2" />
  </surfacematerial>
  <surfacematerial name="surfacematerial3" type="material" xpos="16.695652" ypos="3.629310">
    <input name="surfaceshader" type="surfaceshader" nodename="convert_vector3_surfaceshader" />
  </surfacematerial>
  <surfacematerial name="surfacematerial4" type="material" xpos="16.666666" ypos="5.732759">
    <input name="surfaceshader" type="surfaceshader" nodename="convert_vector3_surfaceshader2" />
  </surfacematerial>
</materialx>

Note

• The render test suite already creates fallbacks for any missing streams before-hand (vs on demand here).

[jstone-lucasfilm]

This looks really promising, thanks @kwokcb, and I should have a chance to take a closer look soon.

[jstone-lucasfilm]

This looks nearly ready to merge, thanks @kwokcb, and I had just a few recommendations for adjustments.

[jstone-lucasfilm]

This is looking very promising, thanks @kwokcb, and I had two notes about design choices in the review comments.

[jstone-lucasfilm]

I'm not sure about this design choice, where the formerly const method Mesh::getStream will silently create new streams when data is missing.

As an alternative design, what if we were to leave Mesh::getStream as a const method, and move the stream construction logic into a new Mesh::createStream method. In the two locations where we need fallbacks for missing streams, we would simply check for a null result from Mesh::getStream and then call Mesh::createStream explicitly.

[jstone-lucasfilm]

This seems like a surprising behavior for Mesh::addStream, where it will silently skip the requested addition when a stream by the same name already exists. In this situation, the caller has no way to know that the mesh stream that they have constructed is not actually referenced or needed by the mesh.

Would it instead be better to thrown an exception in this situation, so that the logic bug leading to this situation can be addressed?

[kwokcb]

Don't really have time to continue pursuing this. Wil close for now.