Hydra GL renderer ignores GeomSubset material bindings #542
Comments
|
Hi @jufrantz , CHeers, |
|
Filed as internal issue #162212. |
|
Hello @spiffmon , |
|
Question, are Also, is that supported by AR kit? |
|
Yes, that’s the idea. ArKit does support this, and we expect hydra gl to
support it soon, also.
On Mon, Jun 3, 2019 at 12:19 PM Jack Caron ***@***.***> wrote:
Question, are GeomSubset can be used as the equivalent to
multi-materials? If you know which faces use which material you can create
a subset with the list of faces and bind them?
Also, is that supported by AR kit?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#542>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABPOU2CP5VHJVJVA27DL2F3PYVVEPANCNFSM4FGZV7LQ>
.
--
--spiffiPhone
|
fsiddi
pushed a commit
to blender/blender
that referenced
this issue
Nov 22, 2019
This commit introduces an exporter to Pixar's Universal Scene Description (USD) format. - The USD libraries are expected to be in /opt/usd/, not yet built by install_deps.sh. I'll work on that while this patch is under review. - Only experimental support for instancing; by default all duplicated objects are made real in the USD file. This is fine for exporting a linked-in posed character, not so much for thousands of pebbles etc. - This patch contains LazyDodo's fixes for building on Windows in D5359. == Meshes == USD seems to support neither per-material nor per-face-group double-sidedness, so we just use the flag from the first non-empty material slot. If there is no material we default to double-sidedness. Each UV map is stored on the mesh in a separate primvar. Materials can refer to these UV maps, but this is not yet exported by Blender. The primvar name is the same as the UV Map name. This is to allow the standard name "st" for texture coordinates by naming the UV Map as such, without having to guess which UV Map is the "standard" one. Face-varying mesh normals are written to USD. When the mesh has custom loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is inspected to determine the normals. The UV maps and mesh normals take up a significant amount of space, so exporting them is optional. They're still enabled by default, though. For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported with UVs and normals, and 262 MiB without. We probably have room for optimisation of written UVs and normals. The mesh subdivision scheme isn't using the default value 'Catmull Clark', but uses 'None', indicating we're exporting a polygonal mesh. This is necessary for USD to understand our normals; otherwise the mesh is always rendered smooth. In the future we may want to expose this choice of subdivision scheme to the user, or auto-detect it when we actually support exporting pre-subdivision meshes. A possible optimisation could be to inspect whether all polygons are smooth or flat, and mark the USD mesh as such. This can be added when needed. == Animation == Mesh and transform animation are now written when passing `animation=True` to the export operator. There is no inspection of whether an object is actually animated or not; USD can handle deduplication of static values for us. The administration of which timecode to use for the export is left to the file-format-specific concrete subclasses of `AbstractHierarchyIterator`; the abstract iterator itself doesn't know anything about the passage of time. This will allow subclasses for the frame-based USD format and time-based Alembic format. == support for simple preview materials == Very simple versions of the materials are now exported, using only the viewport diffuse RGB, metallic, and roughness. When there are multiple materials, the mesh faces are stored as geometry subset and each material is assigned to the appropriate subset. If there is only one material this is skipped. The first material if any) is always applied to the mesh itself (regardless of the existence of geometry subsets), because the Hydra viewport doesn't support materials on subsets. See PixarAnimationStudios/OpenUSD#542 for more info. Note that the geometry subsets are not yet time-sampled, so it may break when an animated mesh changes topology. == Hair == Only the parent strands are exported, and only with a constant colour. No UV coordinates, no information about the normals. == Camera == Only perspective cameras are supported for now. == Particles == Particles are only written when they are alive, which means that they are always visible (there is currently no code that deals with marking them as invisible outside their lifespan). Particle-system-instanced objects are exported by suffixing the object name with the particle's persistent ID, giving each particle XForm a unique name. == Instancing/referencing == This exporter has experimental support for instancing/referencing. Dupli-object meshes are now written to USD as references to the original mesh. This is still very limited in correctness, as there are issues referencing to materials from a referenced mesh. I am still committing this, as it gives us a place to start when continuing the quest for proper instancing in USD. == Lights == USD does not directly support spot lights, so those aren't exported yet. It's possible to add this in the future via the UsdLuxShapingAPI. The units used for the light intensity are also still a bit of a mystery. == Fluid vertex velocities == Currently only fluid simulations (not meshes in general) have explicit vertex velocities. This is the most important case for exporting velocities, though, as the baked mesh changes topology all the time, and thus computing the velocities at import time in a post-processing step is hard.
fsiddi
pushed a commit
to blender/blender
that referenced
this issue
Nov 26, 2019
This commit introduces an exporter to Pixar's Universal Scene Description (USD) format. - The USD libraries are expected to be in /opt/usd/, not yet built by install_deps.sh. I'll work on that while this patch is under review. - Only experimental support for instancing; by default all duplicated objects are made real in the USD file. This is fine for exporting a linked-in posed character, not so much for thousands of pebbles etc. - This patch contains LazyDodo's fixes for building on Windows in D5359. == Meshes == USD seems to support neither per-material nor per-face-group double-sidedness, so we just use the flag from the first non-empty material slot. If there is no material we default to double-sidedness. Each UV map is stored on the mesh in a separate primvar. Materials can refer to these UV maps, but this is not yet exported by Blender. The primvar name is the same as the UV Map name. This is to allow the standard name "st" for texture coordinates by naming the UV Map as such, without having to guess which UV Map is the "standard" one. Face-varying mesh normals are written to USD. When the mesh has custom loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is inspected to determine the normals. The UV maps and mesh normals take up a significant amount of space, so exporting them is optional. They're still enabled by default, though. For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported with UVs and normals, and 262 MiB without. We probably have room for optimisation of written UVs and normals. The mesh subdivision scheme isn't using the default value 'Catmull Clark', but uses 'None', indicating we're exporting a polygonal mesh. This is necessary for USD to understand our normals; otherwise the mesh is always rendered smooth. In the future we may want to expose this choice of subdivision scheme to the user, or auto-detect it when we actually support exporting pre-subdivision meshes. A possible optimisation could be to inspect whether all polygons are smooth or flat, and mark the USD mesh as such. This can be added when needed. == Animation == Mesh and transform animation are now written when passing `animation=True` to the export operator. There is no inspection of whether an object is actually animated or not; USD can handle deduplication of static values for us. The administration of which timecode to use for the export is left to the file-format-specific concrete subclasses of `AbstractHierarchyIterator`; the abstract iterator itself doesn't know anything about the passage of time. This will allow subclasses for the frame-based USD format and time-based Alembic format. == support for simple preview materials == Very simple versions of the materials are now exported, using only the viewport diffuse RGB, metallic, and roughness. When there are multiple materials, the mesh faces are stored as geometry subset and each material is assigned to the appropriate subset. If there is only one material this is skipped. The first material if any) is always applied to the mesh itself (regardless of the existence of geometry subsets), because the Hydra viewport doesn't support materials on subsets. See PixarAnimationStudios/OpenUSD#542 for more info. Note that the geometry subsets are not yet time-sampled, so it may break when an animated mesh changes topology. == Hair == Only the parent strands are exported, and only with a constant colour. No UV coordinates, no information about the normals. == Camera == Only perspective cameras are supported for now. == Particles == Particles are only written when they are alive, which means that they are always visible (there is currently no code that deals with marking them as invisible outside their lifespan). Particle-system-instanced objects are exported by suffixing the object name with the particle's persistent ID, giving each particle XForm a unique name. == Instancing/referencing == This exporter has experimental support for instancing/referencing. Dupli-object meshes are now written to USD as references to the original mesh. This is still very limited in correctness, as there are issues referencing to materials from a referenced mesh. I am still committing this, as it gives us a place to start when continuing the quest for proper instancing in USD. == Lights == USD does not directly support spot lights, so those aren't exported yet. It's possible to add this in the future via the UsdLuxShapingAPI. The units used for the light intensity are also still a bit of a mystery. == Fluid vertex velocities == Currently only fluid simulations (not meshes in general) have explicit vertex velocities. This is the most important case for exporting velocities, though, as the baked mesh changes topology all the time, and thus computing the velocities at import time in a post-processing step is hard.
fsiddi
pushed a commit
to blender/blender
that referenced
this issue
Nov 28, 2019
This commit introduces an exporter to Pixar's Universal Scene Description (USD) format. - The USD libraries are expected to be in /opt/usd/, not yet built by install_deps.sh. I'll work on that while this patch is under review. - Only experimental support for instancing; by default all duplicated objects are made real in the USD file. This is fine for exporting a linked-in posed character, not so much for thousands of pebbles etc. - This patch contains LazyDodo's fixes for building on Windows in D5359. == Meshes == USD seems to support neither per-material nor per-face-group double-sidedness, so we just use the flag from the first non-empty material slot. If there is no material we default to double-sidedness. Each UV map is stored on the mesh in a separate primvar. Materials can refer to these UV maps, but this is not yet exported by Blender. The primvar name is the same as the UV Map name. This is to allow the standard name "st" for texture coordinates by naming the UV Map as such, without having to guess which UV Map is the "standard" one. Face-varying mesh normals are written to USD. When the mesh has custom loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is inspected to determine the normals. The UV maps and mesh normals take up a significant amount of space, so exporting them is optional. They're still enabled by default, though. For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported with UVs and normals, and 262 MiB without. We probably have room for optimisation of written UVs and normals. The mesh subdivision scheme isn't using the default value 'Catmull Clark', but uses 'None', indicating we're exporting a polygonal mesh. This is necessary for USD to understand our normals; otherwise the mesh is always rendered smooth. In the future we may want to expose this choice of subdivision scheme to the user, or auto-detect it when we actually support exporting pre-subdivision meshes. A possible optimisation could be to inspect whether all polygons are smooth or flat, and mark the USD mesh as such. This can be added when needed. == Animation == Mesh and transform animation are now written when passing `animation=True` to the export operator. There is no inspection of whether an object is actually animated or not; USD can handle deduplication of static values for us. The administration of which timecode to use for the export is left to the file-format-specific concrete subclasses of `AbstractHierarchyIterator`; the abstract iterator itself doesn't know anything about the passage of time. This will allow subclasses for the frame-based USD format and time-based Alembic format. == support for simple preview materials == Very simple versions of the materials are now exported, using only the viewport diffuse RGB, metallic, and roughness. When there are multiple materials, the mesh faces are stored as geometry subset and each material is assigned to the appropriate subset. If there is only one material this is skipped. The first material if any) is always applied to the mesh itself (regardless of the existence of geometry subsets), because the Hydra viewport doesn't support materials on subsets. See PixarAnimationStudios/OpenUSD#542 for more info. Note that the geometry subsets are not yet time-sampled, so it may break when an animated mesh changes topology. == Hair == Only the parent strands are exported, and only with a constant colour. No UV coordinates, no information about the normals. == Camera == Only perspective cameras are supported for now. == Particles == Particles are only written when they are alive, which means that they are always visible (there is currently no code that deals with marking them as invisible outside their lifespan). Particle-system-instanced objects are exported by suffixing the object name with the particle's persistent ID, giving each particle XForm a unique name. == Instancing/referencing == This exporter has experimental support for instancing/referencing. Dupli-object meshes are now written to USD as references to the original mesh. This is still very limited in correctness, as there are issues referencing to materials from a referenced mesh. I am still committing this, as it gives us a place to start when continuing the quest for proper instancing in USD. == Lights == USD does not directly support spot lights, so those aren't exported yet. It's possible to add this in the future via the UsdLuxShapingAPI. The units used for the light intensity are also still a bit of a mystery. == Fluid vertex velocities == Currently only fluid simulations (not meshes in general) have explicit vertex velocities. This is the most important case for exporting velocities, though, as the baked mesh changes topology all the time, and thus computing the velocities at import time in a post-processing step is hard.
fsiddi
pushed a commit
to blender/blender
that referenced
this issue
Dec 13, 2019
This commit introduces an exporter to Pixar's Universal Scene Description (USD) format. - The USD libraries are expected to be in /opt/usd/, not yet built by install_deps.sh. I'll work on that while this patch is under review. - Only experimental support for instancing; by default all duplicated objects are made real in the USD file. This is fine for exporting a linked-in posed character, not so much for thousands of pebbles etc. - This patch contains LazyDodo's fixes for building on Windows in D5359. == Meshes == USD seems to support neither per-material nor per-face-group double-sidedness, so we just use the flag from the first non-empty material slot. If there is no material we default to double-sidedness. Each UV map is stored on the mesh in a separate primvar. Materials can refer to these UV maps, but this is not yet exported by Blender. The primvar name is the same as the UV Map name. This is to allow the standard name "st" for texture coordinates by naming the UV Map as such, without having to guess which UV Map is the "standard" one. Face-varying mesh normals are written to USD. When the mesh has custom loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is inspected to determine the normals. The UV maps and mesh normals take up a significant amount of space, so exporting them is optional. They're still enabled by default, though. For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported with UVs and normals, and 262 MiB without. We probably have room for optimisation of written UVs and normals. The mesh subdivision scheme isn't using the default value 'Catmull Clark', but uses 'None', indicating we're exporting a polygonal mesh. This is necessary for USD to understand our normals; otherwise the mesh is always rendered smooth. In the future we may want to expose this choice of subdivision scheme to the user, or auto-detect it when we actually support exporting pre-subdivision meshes. A possible optimisation could be to inspect whether all polygons are smooth or flat, and mark the USD mesh as such. This can be added when needed. == Animation == Mesh and transform animation are now written when passing `animation=True` to the export operator. There is no inspection of whether an object is actually animated or not; USD can handle deduplication of static values for us. The administration of which timecode to use for the export is left to the file-format-specific concrete subclasses of `AbstractHierarchyIterator`; the abstract iterator itself doesn't know anything about the passage of time. This will allow subclasses for the frame-based USD format and time-based Alembic format. == support for simple preview materials == Very simple versions of the materials are now exported, using only the viewport diffuse RGB, metallic, and roughness. When there are multiple materials, the mesh faces are stored as geometry subset and each material is assigned to the appropriate subset. If there is only one material this is skipped. The first material if any) is always applied to the mesh itself (regardless of the existence of geometry subsets), because the Hydra viewport doesn't support materials on subsets. See PixarAnimationStudios/OpenUSD#542 for more info. Note that the geometry subsets are not yet time-sampled, so it may break when an animated mesh changes topology. == Hair == Only the parent strands are exported, and only with a constant colour. No UV coordinates, no information about the normals. == Camera == Only perspective cameras are supported for now. == Particles == Particles are only written when they are alive, which means that they are always visible (there is currently no code that deals with marking them as invisible outside their lifespan). Particle-system-instanced objects are exported by suffixing the object name with the particle's persistent ID, giving each particle XForm a unique name. == Instancing/referencing == This exporter has experimental support for instancing/referencing. Dupli-object meshes are now written to USD as references to the original mesh. This is still very limited in correctness, as there are issues referencing to materials from a referenced mesh. I am still committing this, as it gives us a place to start when continuing the quest for proper instancing in USD. == Lights == USD does not directly support spot lights, so those aren't exported yet. It's possible to add this in the future via the UsdLuxShapingAPI. The units used for the light intensity are also still a bit of a mystery. == Fluid vertex velocities == Currently only fluid simulations (not meshes in general) have explicit vertex velocities. This is the most important case for exporting velocities, though, as the baked mesh changes topology all the time, and thus computing the velocities at import time in a post-processing step is hard.
fsiddi
pushed a commit
to blender/blender
that referenced
this issue
Dec 13, 2019
This commit introduces the first version of an exporter to Pixar's Universal Scene Description (USD) format. Reviewed By: sergey, LazyDodo Differential Revision: https://developer.blender.org/D6287 - The USD libraries are built by `make deps`, but not yet built by install_deps.sh. - Only experimental support for instancing; by default all duplicated objects are made real in the USD file. This is fine for exporting a linked-in posed character, not so much for thousands of pebbles etc. - The way materials and UV coordinates and Normals are exported is going to change soon. - This patch contains LazyDodo's fixes for building on Windows in D5359. == Meshes == USD seems to support neither per-material nor per-face-group double-sidedness, so we just use the flag from the first non-empty material slot. If there is no material we default to double-sidedness. Each UV map is stored on the mesh in a separate primvar. Materials can refer to these UV maps, but this is not yet exported by Blender. The primvar name is the same as the UV Map name. This is to allow the standard name "st" for texture coordinates by naming the UV Map as such, without having to guess which UV Map is the "standard" one. Face-varying mesh normals are written to USD. When the mesh has custom loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is inspected to determine the normals. The UV maps and mesh normals take up a significant amount of space, so exporting them is optional. They're still enabled by default, though. For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported with UVs and normals, and 262 MiB without. We probably have room for optimisation of written UVs and normals. The mesh subdivision scheme isn't using the default value 'Catmull Clark', but uses 'None', indicating we're exporting a polygonal mesh. This is necessary for USD to understand our normals; otherwise the mesh is always rendered smooth. In the future we may want to expose this choice of subdivision scheme to the user, or auto-detect it when we actually support exporting pre-subdivision meshes. A possible optimisation could be to inspect whether all polygons are smooth or flat, and mark the USD mesh as such. This can be added when needed. == Animation == Mesh and transform animation are now written when passing `animation=True` to the export operator. There is no inspection of whether an object is actually animated or not; USD can handle deduplication of static values for us. The administration of which timecode to use for the export is left to the file-format-specific concrete subclasses of `AbstractHierarchyIterator`; the abstract iterator itself doesn't know anything about the passage of time. This will allow subclasses for the frame-based USD format and time-based Alembic format. == Support for simple preview materials == Very simple versions of the materials are now exported, using only the viewport diffuse RGB, metallic, and roughness. When there are multiple materials, the mesh faces are stored as geometry subset and each material is assigned to the appropriate subset. If there is only one material this is skipped. The first material if any) is always applied to the mesh itself (regardless of the existence of geometry subsets), because the Hydra viewport doesn't support materials on subsets. See PixarAnimationStudios/OpenUSD#542 for more info. Note that the geometry subsets are not yet time-sampled, so it may break when an animated mesh changes topology. Materials are exported as a flat list under a top-level '/_materials' namespace. This inhibits instancing of the objects using those materials, so this is subject to change. == Hair == Only the parent strands are exported, and only with a constant colour. No UV coordinates, no information about the normals. == Camera == Only perspective cameras are supported for now. == Particles == Particles are only written when they are alive, which means that they are always visible (there is currently no code that deals with marking them as invisible outside their lifespan). Particle-system-instanced objects are exported by suffixing the object name with the particle's persistent ID, giving each particle XForm a unique name. == Instancing/referencing == This exporter has experimental support for instancing/referencing. Dupli-object meshes are now written to USD as references to the original mesh. This is still very limited in correctness, as there are issues referencing to materials from a referenced mesh. I am still committing this, as it gives us a place to start when continuing the quest for proper instancing in USD. == Lights == USD does not directly support spot lights, so those aren't exported yet. It's possible to add this in the future via the UsdLuxShapingAPI. The units used for the light intensity are also still a bit of a mystery. == Fluid vertex velocities == Currently only fluid simulations (not meshes in general) have explicit vertex velocities. This is the most important case for exporting velocities, though, as the baked mesh changes topology all the time, and thus computing the velocities at import time in a post-processing step is hard. == The Building Process == - USD is built as monolithic library, instead of 25 smaller libraries. We were linking all of them as 'whole archive' anyway, so this doesn't affect the final file size. It does, however, make life easier with respect to linking order, and handling upstream changes. - The JSON files required by USD are installed into datafiles/usd; they are required on every platform. Set the `PXR_PATH_DEBUG` to any value to have the USD library print the paths it uses to find those files. - USD is patched so that it finds the aforementioned JSON files in a path that we pass to it from Blender. - USD is patched to have a `PXR_BUILD_USD_TOOLS` CMake option to disable building the tools in its `bin` directory. This is sent as a pull request at PixarAnimationStudios/OpenUSD#1048
|
Just ran into this as well and noticed that while a number of viewers (including QuickLook) support this, usdview notably doesn't, making it harder to use it as "reference viewer" of sorts. |
|
What version of USD are you using? Hydra has supported this for at least a
couple of years, now!
On Fri, Jun 3, 2022 at 3:36 AM hybridherbst ***@***.***> wrote:
Just ran into this as well and noticed that while a number of viewers
(including QuickLook) support this, usdview notably doesn't, making it
harder to use it as "reference viewer" of sorts.
—
Reply to this email directly, view it on GitHub
<#542 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPOU2DR6KRVMLNV556NAVDVNHN27ANCNFSM4FGZV7LQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
--spiffiPhone
|
|
Specifically, usdview does support material bindings to geom subsets now, I
believe as of USD v21.11 -
https://github.com/PixarAnimationStudios/USD/blob/release/CHANGELOG.md#storm-2
You can verify this via the test asset at
https://github.com/PixarAnimationStudios/USD/tree/v22.05a/pxr/usdImaging/usdImagingGL/testenv/testUsdImagingGLGeomSubsets
which produces images such as the ones in
https://github.com/PixarAnimationStudios/USD/tree/v22.05a/pxr/usdImaging/usdImagingGL/testenv/testUsdImagingGLGeomSubsets/baseline
.
The original geomSubsetMaterialBindings.tar.gz
<https://github.com/PixarAnimationStudios/USD/files/2133786/geomSubsetMaterialBindings.tar.gz>
doesn't
work for me, but I think it's an issue with the shader setup--
Warning: in UsdImagingBuildHdMaterialNetworkFromTerminal at line 485 of
C:\Users\aluk\git\omniverse\usd-build\USD\pxr\usdImaging\usdImaging\materialParamUtils.cpp
-- Invalid info:id node: /all/Looks/constant_red/shader
Warning: in UsdImagingBuildHdMaterialNetworkFromTerminal at line 485 of
C:\Users\aluk\git\omniverse\usd-build\USD\pxr\usdImaging\usdImaging\materialParamUtils.cpp
-- Invalid info:id node: /all/Looks/constant_blue/shader
Warning: in UsdImagingBuildHdMaterialNetworkFromTerminal at line 485 of
C:\Users\aluk\git\omniverse\usd-build\USD\pxr\usdImaging\usdImaging\materialParamUtils.cpp
-- Invalid info:id node: /all/Looks/constant_red/shader
Best,
-a.
On Fri, Jun 3, 2022 at 3:09 PM F. Sebastian (spiff) Grassia <
***@***.***> wrote:
… What version of USD are you using? Hydra has supported this for at least a
couple of years, now!
On Fri, Jun 3, 2022 at 3:36 AM hybridherbst ***@***.***>
wrote:
> Just ran into this as well and noticed that while a number of viewers
> (including QuickLook) support this, usdview notably doesn't, making it
> harder to use it as "reference viewer" of sorts.
>
> —
> Reply to this email directly, view it on GitHub
> <
#542 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ABPOU2DR6KRVMLNV556NAVDVNHN27ANCNFSM4FGZV7LQ
>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
--spiffiPhone
—
Reply to this email directly, view it on GitHub
<#542 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAP7WZU4S4TFNEIIV75VBYLVNH7YVANCNFSM4FGZV7LQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Interesting, good to know – I guess this issue can be closed then – |
I've provided @hybridherbst with v22.05 and v22.05a Windows builds for now while we at NVIDIA rework our packaging pipeline over the summer 🙏 |
francis-wangfr
pushed a commit
to autodesk-forks/USD
that referenced
this issue
Feb 8, 2024
…Studios#542) - Add public function to query the Viewport Y up axis - Handle writing test image to for different orientations of the Y axis - Expose `Tf_GetEnvSettingByName` function to avoid issue when querying the HGI backend in engine.cpp - Add debug functionality to disable tint symbol renaming
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of Issue
Attached usd file in geomSubsetMaterialBindings.tar.gz defines mesh
/all/cube_redAndBluewith two face subsetsred_setandblue_set.Each subset has a material bound to it using attached constant.glslfx shader.
When rendered with hydra GL, subsets shaders are not taken into account.
Steps to Reproduce
System Information (OS, Hardware)
Linux
Package Versions
USD 0.8.5a
Build Flags
The text was updated successfully, but these errors were encountered: