Arnold doesn't really distinguish between surface and volume shaders, so having distinct relationships doesn't seem to make a lot of sense (especially since we're translating both as the "surface" shader in Katana).

Add support for progressive rendering and let the user switch between progressive/blocking rendering.

The changes in PixarAnimationStudios/OpenUSD@a627abb introduced some additional logic to the naming handle generation logic for shading nodes that are not immediate children of the material that is being built. This is to avoid collisions when shading nodes are nested in sub-graphs, but it also affects shaders that are shared between multiple material networks.

The new logic for making the shading node handles unique is not part of PxrUsdKatanaUtils::GenerateShadingNodeHandle, so our location decorator did not pick up the new behavior automatically. Thus, reading materials with shared shaders is currently broken when using USD 20.02+.

I'm going to ask Pixar about making the unique handle generation logic part of the public API.

As the title says. There are a few linking issues and warnings on Mojave. Mainly usdAi does not link against all the required libraries (which is handled at runtime on Linux but not on MacOS), and the newer compiler on MacOS has a few extra warnings turned on.

We also need to investigate the current state of UsdSkel support in HdSt and what's the best ways to tackle this in the HdAi render delegate.

Register all the available nodes/shaders in the (s|n)dr registry, set default values and read metadata.

This way we can decrease maintenance complexity and avoid writing our camera node.

Implement a working render delegate to render via Hydra.

A (non-complete) list of subtasks for the initial implementation.

• Camera that generates rays from the projection passed to the renderer.
• Driver to pass render data and buffers to Hydra.
• Polymesh support.
• Implement HdAiRenderPass.
• Blocking rendering.

Support materials in the render delegate, meaning converting HdMaterialNetworkMaps to Arnold shader networks. We can use the SdrRegistry to read default values.

Currently, it's not easily possible to build both the schemas and the plugins at the same time. While this is a good fit for rez based / multiple packages approaches, it's not a universal fit for everyone.

Add support for reading primvars.

For the default shader, would be nice to support primvars:displayColor, like GL stream renderer, and make the shader a lambert
for usdview support, this would require handling the usdview default light in some manner

Pretty much as the title says:

• start maya, make sure mtoa is not loaded / not set to auto-load
• start maya-to-hydra, set it as the viewport renderer, set it's renderer plugin to arnold
• load mtoa
• crash!

Modules
Current
We support MtoA-1.2 and MtoA-1.4.
Does this mean that code support only MtoA-1.2 and MtoA-1.4.Because Maya comes with 3.2 now. is the code old or has been updated now?
Can you please help me to understand?

Add support for MtoA-2.x.

Including transformation and deformation blur.

As the title says.

We fallen behind on MtoA support as we still rely on headers and functions that are not exposed in MtoA 3 anymore.

We need to expose a few controls for the render delegate, like switching between progressive rendering/blocking renders, sampling settings, material overrides, etc.

We should store all AOV data in a data bucket coming from the driver; this would also allow us to handle depth more gracefully. (see #19, and the problems explained there)

We should also look into better ways to calculate NDC depth.

Later on, this would be an excellent opportunity to support multiple AOVs as well.

Use Arnold's instancing to efficiently render instanced data.

if you're in maya, and using the arnold render delegate, then changing the light falloff property of a light does nothing - it always renders as quadratic

As the title says. Rendering should be done outside the main thread.

• Load the attached usda
• Turn on materials
• Should show up fine in HdStream
• Switch to arnold render delegate
• No materials

cube_texture.usda.zip

Currently, the build process only supports Linux, this needs to be fixed.

Some fixes has been made to core USD to correct Maya plugin bugs, like pixar/pxr python module confusion : PixarAnimationStudios/OpenUSD#596

These changes are not applied to LumaPictures, preventing a correct use of the Maya plugin.

Any plan to update the LM repository ?

See :

• PixarAnimationStudios/OpenUSD#596
• PixarAnimationStudios/OpenUSD@02aeeea#diff-d2ef6106703526e29728717a66c06a42

Regards

Support all the compatible HdLight types.

not sure if this is the right project for this report, but:

if you're in maya, with mtoh turned on, and the arnold render delegate, then:

1. select a light
2. tumble the viewport
3. no refresh
4. click in the viewport
5. arnold renderer refreshes

As the title says. Add support for subdivision settings (coming from the HdMeshTopology), setting up the subdiv crease weights for edges and vertices and using the display style to set subdivision levels.

Not only we have to handle syncing of all the parameters, but we need to dirty and restart renders if anything has changed.

We have the following changes pending and awaiting to be merged back. This will helps us to build with a stock version of USD.

• 228
• 226
• 232
• 231
• readMaterial.cpp customizations in usdKatana.

This would be great for cases where we are drawing over the results of HdAi, like Maya to Hydra.

USD supports the option to compile all of its modules into a single monolithic shared library or archive, rather than individual libraries for each module (Tf, Sdf, Usd, etc).

Thus, we should eventually add support for linking against monolithic libraries as well.

Support the new volume schemas submitted by SideFx.

This should be in a separate shader module, not in the render delegate plugin.

• Preview Surface
• Texture Reader
• Primvar Readers