Found 628 posts.
Search results Show results as topic list.
Solaris and Karma » Network Boxes not supported in USD and Edit Material Network
- rafal
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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
- 1448 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 - Dec. 20, 2023 15:26:37
Solaris and Karma » Visualizing MaterialX VOP's
- rafal
- 1448 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
- 1448 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 - Nov. 6, 2023 17:02:00
Solaris and Karma » houdini 19.5 issue - stacking Set Variant nodes
- rafal
- 1448 posts
- Offline
Technical Discussion » Grooming in orthographic viewport
- rafal
- 1448 posts
- Offline
Technical Discussion » hou.ui.display , ask me again please !!!!
- rafal
- 1448 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.
Technical Discussion » shelf tools
- rafal
- 1448 posts
- Offline
Perhaps the startup scripts have set the Houdini search path (or shelt/toolbar search path) incorrectly.
Technical Discussion » Pre-Compile Custom VOP Function
- rafal
- 1448 posts
- Offline
In general, Approach 1 is preferable because it keeps the original network with the VEX source code.
Ie, in the Approach 2, when you do Save > Save VEX Code, you detach VEX source code, and you need to keep track of the original .hip file that generated it.
Also, Mantra does look-aside byte-code caching (see `vexcache --help`). It it looks up the compiled byte-code based on the source code hash. When you use snippet and you "tweak" it, Mantra will include the large chunk, but the tweak will alter the hash, Mantra won't reuse bytecode and will need to re-compile the snippet, including the included large chunk of code.
With Material Builder approach, the large chunk is isolated from the main network (and if you make an HDA out of it and toggle on "save cached code" checkbox that VEX source code will be save to the HDA's section, like Principled Shader, for even more speed), which Mantra will cache to the look-aside table when it compiles it for the first time. So, when you use Material Builder in your new VOP network, the VOPs will generate a shader function call for it, so the tweaked VEX is very small: it has a function call (but no function body). The function body does not need to be re-compiled since the source code has not changed, so Mantra can reuse the look-aside VEX bytecodes.
As to your problem with bad normals, it almost sounds like Mantra bug? If it works for the displacement amount, then it should work for the normals too.
I'm looking at the VEX source code (RMB > VEX/VOP Options > View VEX Code...) for the principledshader_approach1 and 2 and I cannot see why the final `N` variable would be different between them. It's just the output (value of the export variable) of the of the final principled shader call.
One trick you can try is to select both the materialbuilder1 and principledshader_approach1 VOPs and then from the network pane menu do Edit > Collapse Selected into Material to see what the actual final shader looks like in terms of VOPs, and then see if you can tweak the wiring in that top-level network to get the correct normal.
Ie, in the Approach 2, when you do Save > Save VEX Code, you detach VEX source code, and you need to keep track of the original .hip file that generated it.
Also, Mantra does look-aside byte-code caching (see `vexcache --help`). It it looks up the compiled byte-code based on the source code hash. When you use snippet and you "tweak" it, Mantra will include the large chunk, but the tweak will alter the hash, Mantra won't reuse bytecode and will need to re-compile the snippet, including the included large chunk of code.
With Material Builder approach, the large chunk is isolated from the main network (and if you make an HDA out of it and toggle on "save cached code" checkbox that VEX source code will be save to the HDA's section, like Principled Shader, for even more speed), which Mantra will cache to the look-aside table when it compiles it for the first time. So, when you use Material Builder in your new VOP network, the VOPs will generate a shader function call for it, so the tweaked VEX is very small: it has a function call (but no function body). The function body does not need to be re-compiled since the source code has not changed, so Mantra can reuse the look-aside VEX bytecodes.
As to your problem with bad normals, it almost sounds like Mantra bug? If it works for the displacement amount, then it should work for the normals too.
I'm looking at the VEX source code (RMB > VEX/VOP Options > View VEX Code...) for the principledshader_approach1 and 2 and I cannot see why the final `N` variable would be different between them. It's just the output (value of the export variable) of the of the final principled shader call.
One trick you can try is to select both the materialbuilder1 and principledshader_approach1 VOPs and then from the network pane menu do Edit > Collapse Selected into Material to see what the actual final shader looks like in terms of VOPs, and then see if you can tweak the wiring in that top-level network to get the correct normal.
Solaris and Karma » Material instance like UE?
- rafal
- 1448 posts
- Offline
You can try Edit Material Properties LOP with the "Reference Type" set to 'reference' or 'specialize'.
-
- Quick Links