Found 631 posts.
Search results Show results as topic list.
Solaris and Karma » Mtlx Hda questions
-
- rafal
- 1452 posts
- Offline
This popped up again recently so I re-did the example using an HDA as jsmack suggested.
Solaris and Karma » MtlX Signature prefixes
-
- rafal
- 1452 posts
- Offline
It's probably because you used "-n switch_20" on the command line. I think the MaterialX shader name is derived from the HDA name.
You can change the shader name in the HDA Op Type Properties in Houdini (RMB > Edit Operator Type). In the inputs/outputs there is a shader name for each signature. You can change that to an arbitrary shader name.
You can change the shader name in the HDA Op Type Properties in Houdini (RMB > Edit Operator Type). In the inputs/outputs there is a shader name for each signature. You can change that to an arbitrary shader name.
Solaris and Karma » Vop2mtlx: UI with no input connections - Ordered Menu
-
- rafal
- 1452 posts
- Offline
MaterailX shader nodes have only inputs, thus only VOP node inputs get translated to materialx. However, your channel reference approach (to the 'blend_mode' top parameter) should work, since ultimately you are setting a value on a MaterialX shader input.
As for the color-space value, in MaterialX, they are authored as an attribute of the input element. But `vop2mtlx.py` might not be handling them properly. It, it may be a bug/limitation of that script.
As for the color-space value, in MaterialX, they are authored as an attribute of the input element. But `vop2mtlx.py` might not be handling them properly. It, it may be a bug/limitation of that script.
Solaris and Karma » Network Boxes not supported in USD and Edit Material Network
-
- rafal
- 1452 posts
- Offline
Eventually yes, Houdini will utilize the UsdUIBackdrop but there are higher priorities at the moment. Houdini will need to do it for Karma and MaterialX builders. The 3rd party renderers will need to author them in their custom shader translators. And Houdini's Edit Material Network will need to recognize them for all renderers.
Solaris and Karma » Mtlx Hda questions
-
- rafal
- 1452 posts
- Offline
MR SMITHYou're welcome. Happy to hear it worked.
Thanks Rafal! truly appreciate the effort creating those files. I managed to do some tests.
MR SMITHI think that's all fine. You can create HDAs in Indie, but they are saved in an indie format, so will downgrade the session if loaded into a fully commercial session.
*One thing that was a bit weird is that I was able to make an .hda file without issues even though i'm on Indie. Is this something temporary or did that limitation change?
MR SMITHYes, it's reliable, and will continue to be. That's pretty much how MaterialX standard nodes are processed for Houdini releases.
Is this roundtrip with mtlx / hda / json still reliable for future hou versions and mtlx standards?
Solaris and Karma » Mtlx Hda questions
-
- rafal
- 1452 posts
- Offline
Actually HoudiniGL seems to recognize the karmaNodeGraphs.json file, so it renders the new custom shader as long as it's implemented entirely with standard MaterialX nodes.
The rough steps are:
1) Build a subnet VOP containing the implementation of your custom shader. There are some annoyances with defining subnet inputs and naming them. Pretty much the input name is imposed by the Subnet VOP, and will need to be hand-edited in step 3.
2) RMB > Save > MaterialX... to a foo.mtlx file
3) Hand edit the foo.mtlx file to add the nodedef element for you shader. Also delete the shader nodes that are outside of the nodegraph but were saved nonetheless in step 1. Remember to remove references to them from the nodegraph's inputs and outputs.
4) run the `mtlx2hda.py` and the `mtlx2karma.py` scripts on the command line to create an .hda file for Houdini (to crate new VOP nodes) and .json for Karma to render them.
5) test out by restarting Houdini, loading .hda and creating a new node.
Here is an example .hip file with steps described in the sticky notes. This file works in my setup. The .hda and .json files should be put in Houdini search path, but they also work if you just start Houdini from the command line in the foo subdir.
The rough steps are:
1) Build a subnet VOP containing the implementation of your custom shader. There are some annoyances with defining subnet inputs and naming them. Pretty much the input name is imposed by the Subnet VOP, and will need to be hand-edited in step 3.
2) RMB > Save > MaterialX... to a foo.mtlx file
3) Hand edit the foo.mtlx file to add the nodedef element for you shader. Also delete the shader nodes that are outside of the nodegraph but were saved nonetheless in step 1. Remember to remove references to them from the nodegraph's inputs and outputs.
4) run the `mtlx2hda.py` and the `mtlx2karma.py` scripts on the command line to create an .hda file for Houdini (to crate new VOP nodes) and .json for Karma to render them.
5) test out by restarting Houdini, loading .hda and creating a new node.
Here is an example .hip file with steps described in the sticky notes. This file works in my setup. The .hda and .json files should be put in Houdini search path, but they also work if you just start Houdini from the command line in the foo subdir.
Solaris and Karma » Mtlx Hda questions
-
- rafal
- 1452 posts
- Offline
Native mtlx nodes should be faster than python shader translation scripts invoked during cooking.
To get .mtlx shader implementation you can use `vop2mtlx` or you may have some luck with RMB > Save > MaterialX. You may still need to manually adjust the .mtlx and create the nodedef for your shader.
Then you will need to run mtlx2karma to generate karma networks for your mtlx shader.
This probably means that HoudiniGL will not render your shader, though.
To get .mtlx shader implementation you can use `vop2mtlx` or you may have some luck with RMB > Save > MaterialX. You may still need to manually adjust the .mtlx and create the nodedef for your shader.
Then you will need to run mtlx2karma to generate karma networks for your mtlx shader.
This probably means that HoudiniGL will not render your shader, though.
Solaris and Karma » Mtlx Image string inputs connection return error
-
- rafal
- 1452 posts
- Offline
Indeed, MaterialX 1.38 does not have a geom prop value shader that would return a uniform string. There is one planned for 1.39.
p.s.
In MaterialX 1.38 is a little bit iffy when it comes to strings they can only be uniform, and yet geom prop value shader returns a varying string.
p.s.
In MaterialX 1.38 is a little bit iffy when it comes to strings they can only be uniform, and yet geom prop value shader returns a varying string.
Solaris and Karma » Network Boxes not supported in USD and Edit Material Network
-
- rafal
- 1452 posts
- Offline
Edit Material Network re-constructs the shader network from USD primitives. And the USD shader primitive network does not encode the network boxes.
P.s., There is a concept of UsdUIBackdrop, but the shader translators don't make use of it yet.
P.s., There is a concept of UsdUIBackdrop, but the shader translators don't make use of it yet.
Solaris and Karma » Issue with Edit Material Properties node
-
- rafal
- 1452 posts
- Offline
This is a bug in the Edit Material Properties LOP, which is being worked on.
It has trouble with hide-when and disable-when expressions, because that LOP deals with "inputs:diffuseDoubleSided" (incoded into alpha-numeric name to avoid a colon), but the hide-when expression still uses just "diffuseDoubleSided" from the shader's HDA node.
In the parameter pane toolbar, if you click (gear) > Edit Parameter Interface, you can manually clean it up. Eg, delete the hide-when expression, and accept. Then the parameters should show up.
It has trouble with hide-when and disable-when expressions, because that LOP deals with "inputs:diffuseDoubleSided" (incoded into alpha-numeric name to avoid a colon), but the hide-when expression still uses just "diffuseDoubleSided" from the shader's HDA node.
In the parameter pane toolbar, if you click (gear) > Edit Parameter Interface, you can manually clean it up. Eg, delete the hide-when expression, and accept. Then the parameters should show up.
Solaris and Karma » Solaris Material Networks hanging when in Manual mode
-
- rafal
- 1452 posts
- Offline
You can contact support@sidefx and ask to be added to that issue ticket to see the status.
Solaris and Karma » Karma Material Builder plugged into Collect node
-
- rafal
- 1452 posts
- Offline
Usually, you can just connect the shader outputs to the Collect inputs.
This should produce a USD Material primitive with several terminal outputs uniquely identifying shader type (surface vs. displacement) and shader context (karma vs mtlx).
This should produce a USD Material primitive with several terminal outputs uniquely identifying shader type (surface vs. displacement) and shader context (karma vs mtlx).
token outputs:kma:displacement.connect = </materials/collect1/karmamaterial.outputs:displacement>
token outputs:kma:surface.connect = </materials/collect1/karmamaterial.outputs:surface>
token outputs:mtlx:displacement.connect = </materials/collect1/mtlxmaterial.outputs:displacement>
token outputs:mtlx:surface.connect = </materials/collect1/mtlxmaterial.outputs:surface>
Solaris and Karma » Preview Material X textures in KarmaXPU for debugging.
-
- rafal
- 1452 posts
- Offline
It could be related to the issue that visualizing works only for shader nodes that are part of the material network (ie, part of the input chains of the terminal surface shader). That's reported as Bug 134212.
Solaris and Karma » Separate Materials for Separate Renderers in USD
-
- rafal
- 1452 posts
- Offline
Yes, indeed. Connecting terminal shader nodes to the collect node inside the material library LOP (or to the subnet output inside a subnet VOP) will create two terminal USD shaders inside one USD Material. You bind that one material to geometry. But then when rendering, the Hydra delegate (Karma or RMan) will pick the terminal shader that's appropriate for it.
Technical Discussion » Why MTLX "Add" node removed SurfaceShader signature in H20?
-
- rafal
- 1452 posts
- Offline
That signature was removed from the MaterialX standard in 1.38.6 [github.com]:
- commit: https://github.com/AcademySoftwareFoundation/MaterialX/pull/1089 [github.com]
- meeting notes: https://academysoftwarefdn.slack.com/archives/C0230LWBE2X/p1664303114494509 [academysoftwarefdn.slack.com]
- original discussion: https://academysoftwarefdn.slack.com/archives/C0230LWBE2X/p1663675573355349 [academysoftwarefdn.slack.com]
- commit: https://github.com/AcademySoftwareFoundation/MaterialX/pull/1089 [github.com]
- meeting notes: https://academysoftwarefdn.slack.com/archives/C0230LWBE2X/p1664303114494509 [academysoftwarefdn.slack.com]
- original discussion: https://academysoftwarefdn.slack.com/archives/C0230LWBE2X/p1663675573355349 [academysoftwarefdn.slack.com]
First question is if there is a need for these at all? And that goes for all the shader types (surfaceshader, displacementshader and volumeshader). The one operator among them that I can see some use for is the mix of surfaceshader type, mainly to be able to have materials that mask out different surface shaders on different parts of an object.
In our opinion, these nodes should not exist. The only thing you should be able to do on shader types is blending them with a mix node, all other operations should be forbidden.
Edited by rafal - 2023年12月20日 15:26:37
Solaris and Karma » Visualizing MaterialX VOP's
-
- rafal
- 1452 posts
- Offline
jsmackThat's essentially what the shader translator authors when it sees the Visualize VOP. It's just does it in the Viewport Override layer, so there are less chances of the debugging making its way to the final rendering by mistake.
My workflow is to use the Surface Unlit shader
(In H20 it actually uses EDF+Surface shader, but in the next version it's simplified to use the Unlit surface shader).
Houdini Lounge » MaterialX node documentation?
-
- rafal
- 1452 posts
- Offline
The signature parameter switches the types of the node's inputs and outputs. It's a Houdini way of dealing with the same operation that has several variants, each differing only in the types it takes.
A MaterialX shader node can have several definitions that differ only in type it takes, and therefore such definitions fit well with Houdini's concept of a signature.
The signature name in Houdini comes form MaterialX name of the given definition (eg, "ND_multiply_vector2" and "ND_multiply_vector3FA"). We try to keep close to the original name, while making it a little bit more human-readable.
A MaterialX shader node can have several definitions that differ only in type it takes, and therefore such definitions fit well with Houdini's concept of a signature.
The signature name in Houdini comes form MaterialX name of the given definition (eg, "ND_multiply_vector2" and "ND_multiply_vector3FA"). We try to keep close to the original name, while making it a little bit more human-readable.
Edited by rafal - 2023年11月6日 17:02:00
Solaris and Karma » houdini 19.5 issue - stacking Set Variant nodes
-
- rafal
- 1452 posts
- Offline
Technical Discussion » Grooming in orthographic viewport
-
- rafal
- 1452 posts
- Offline
Technical Discussion » hou.ui.display , ask me again please !!!!
-
- rafal
- 1452 posts
- Offline
The `displayCustomConfirmation()` function has a `suppress` parameter, which is set to `hou.confirmType.OverwriteFile` by default.
So try toggling "Warn Before Owerwriting Files" in Edit > Preferences > Warning Dialogs.
To avoid the toggle, instead of `displayCustomConfirmation()`, try `displayMessage()` with the same arguments.
So try toggling "Warn Before Owerwriting Files" in Edit > Preferences > Warning Dialogs.
To avoid the toggle, instead of `displayCustomConfirmation()`, try `displayMessage()` with the same arguments.
-
- Quick Links