=============================
Supported USD Primitive Types
=============================

USD is an extensive library, and below we have provided a table of the default USD primitive types and whether we support reading them into a Katana project. This does not describe what kind of support renderers or the viewport have in relation to these, just whether we support reading them from USD files into scene graph locations. It is worth noting that we import more types than those listed here, as there is generic type importing where we read any attribute set on a USD node. However, this is a list of the types we handle with specific definitions or attributes, especially those types which correspond to Katana attribute conventions.


Cameras
-------
.. csv-table::
    :header: "PrimName", "Supported", "Detail"
    :widths: 30, 10, 70

    UsdGeomCamera, Yes,

Curves
------
.. csv-table::
    :header: "PrimName", "Supported", "Detail"
    :widths: 30, 10, 70

    UsdGeomBasisCurves, Yes, "Supported basis' bezier, (b-spline, catmull-rom, hermite, power), if default renderer is RenderMan, we set basis under prmanStatements.basis.u and prmanStatements.basis.v (as per USD 19.05 original KatanaUsdPlugins), otherwise we set the correct integer value on geometry.basis"
    UsdGeomNurbsCurves, Yes,
    UsdGeomCurves, Yes, This is the base class for UsdGeomBasisCurves and UsdGeomNurbsCurves.

Geometry
--------
.. csv-table::
    :header: "PrimName", "Supported", "Detail"
    :widths: 30, 10, 70

    UsdGeomCapsule, Yes,
    UsdGeomCone, Yes,
    UsdGeomCube, Yes,
    UsdGeomCylinder, Yes,
    UsdGeomGprim, Yes,
    UsdGeomMesh, Yes,
    UsdGeomNurbsPatch, Yes,
    UsdGeomPointInstancer, Yes,
    UsdGeomScope, Yes,
    UsdGeomSphere, Yes,
    UsdGeomXForm, Yes,


Lights
------

Katana will import prims which have the LightAPI applied as lights provided
that the prim type is: 

1. A concrete IsA schema
2. Not registered against another import OP

Geometry lights are not currently supported. The geometry data will be imported
but the light data will not.

We can only read light data if the values of the LightAPI shaderId attributes
are registered into the SdrRegistry with all of their respective parameters
included to allow us to ensure the types of parameters are correctly defined.
Sometimes, a type in the USD Document is different to the one that Hydra
expects (e.g. enableColorTemperature has an inputType of int but some render
delegates expect it to be passed as a bool). In this case, the shader's
sdrUsdDefinitionType Hint should be set to the type required by the delegate
and the data will be cast to that type before it is passed.

Lights - UsdRi
--------------
.. csv-table::
    :header: "PrimName", "Supported", "Detail"
    :widths: 30, 10, 70

    UsdRiPxrEnvDayLight, Yes,
    UsdRiPxrAovLight, Yes,

Light Filters
-------------
.. csv-table::
    :header: "PrimName", "Supported", "Detail"
    :widths: 30, 10, 70

    UsdLuxLightFilter, Yes,  "Base class for the UsdRi light filters, not read by itself currently"
    UsdRiPxrBarnLightFilter, Yes,
    UsdRiPxrCookieLightFilter, Yes,
    UsdRiPxrIntMultLightFilter, Yes,
    UsdRiPxrRampLightFilter, Yes,
    UsdRiPxrRodLightFilter, Yes,