Fixed the DAE file conversion errors

[ft-lab]

Description

Fixes #55

Fixed an issue where some urdf_files_datasets could not be converted correctly.
This was all due to issues during DAE file conversion.

Bug fixes

• dae (parse): Fixed to correctly parse even when the dae file structure is corrupted.
  • In cases where the structure of lights or cameras within a dae file was corrupted, parsing would sometimes fail.
• dae (material): Fixed an issue where geometry node material references were sometimes not retrieved correctly.
  • In some cases it was necessary to look up the target assigned to a material ID in the list of GeometryNode.materials.
• dae (material): Fixed a calculation error when the material's Opaque Mode was "RGB_ZERO".
• dae (geometry): Fixed an issue where the UV array could not be acquired correctly in some cases.
  • Modified to retrieve a list of "texcoord_indexset" instead of a list of "texcoord_index".
• dae (material): Fixed an issue where materials with identical names within a single dae file were not bind correctly.
  • We had been identifying materials within a single dae file by their “material name,” but this could result in duplicate names.
  • We have changed the identification method to use the "Material ID". Note that the displayName will adopt the "Material Name".

URDF files for verifying each one

random/robot-assets/ur5/ur5_gripper.urdf

https://github.com/Daniella1/urdf_files_dataset/blob/main/urdf_files/random/robot-assets/ur5/ur5_gripper.urdf

This is referencing a dae file that is partially corrupted.
Previously, the following error occurred.

DaeBrokenRefError: Light #Lamp-light not found in library

This was circumvented with the following implementation.

conversion_collada.py

_collada = collada.Collada(str(input_path), ignore=[collada.DaeError])

random/robot-assets/r2_description/robots/r2c5.urdf

https://github.com/Daniella1/urdf_files_dataset/blob/main/urdf_files/random/robot-assets/r2_description/robots/r2c5.urdf

This had the following bugs.

• Issue where some materials are not bound.
• An issue where some materials were occasionally assigned transparency
• An issue where some UVs were not passed correctly, preventing texture mapping

These issues were fixed in this PR, but since another issue was found, we are separating those problems.
-> Issue #61, Issue #62

The following is rendered entirely as metallic because the Specular Workflow is enabled and SpecularColor(1, 1, 1) is assigned.

matlab/robotiq2F85/urdf/robotiq2F85.urdf

https://github.com/Daniella1/urdf_files_dataset/blob/main/urdf_files/matlab/robotiq2F85/urdf/robotiq2F85.urdf

In the “robotiq_arg2f_85_base_link.dae” referenced by this URDF file, the same material name was assigned to multiple materials.

  <library_materials>
    <material name="mymaterial" id="material100">
      <instance_effect url="#effect100"/>
    </material>
        <material name="mymaterial" id="material0">
      <instance_effect url="#effect0"/>
    </material>
  </library_materials>

In this PR implementation, the material prim names are set to "material100" and "material0", and the displayName is set to "mymaterial".

unit test:

The following files perform unit tests on DAE files with identical material names.

• tests/data/test_displayname.urdf
• tests/data/assets/box_two_materials_same_names.dae

Checklist

• I am familiar with the Contributing Guidelines.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[ft-lab]

Other issues I found here are separated out below.

• Issue where diffuseColor/diffuseColorTexture is ignored when SpecularColor is set to (1, 1, 1) in the Specular Workflow (This is the specified behavior of USD's UsdPreviewSurface) -> Issue Handling the Specular Workflow #61
• Issues caused by default WrapS/WrapT settings (“black”) when assigning textures in materials -> Issue OBJ/DAE: Should wrapS/wrapT be set to "repeat" when using textures in materials? #62