Hi,
I've stumbled upon this thread and looked into the example. There's an issue with the geo path in the swirl_mesh_topology usd in that it is a full path. In the swirl_mesh.usda they are relative. Is this by design? I have to manually/post process this usda to have a relative path to work cross platform at the moment. Well, when I say 'work', it works OK but there will be problems if the metadata is required.
Cheers,
J
Found 66 posts.
Search results Show results as topic list.
Solaris and Karma » Writing USD to disk that references a geometry sequence
- protean
- 72 posts
- Offline
Solaris and Karma » Material Library Best Practice
- protean
- 72 posts
- Offline
Hi,
I notice that the material library becomes sluggish very quickly when one is left to noodle. In this example I've created 64 Principled shaders and connected a singular UV Triplanar Project to illustrate the issue. If I now try and edit the network, I can be waiting 10s of seconds for an update.
This example is a bit silly and one could be using 'material builders' to segregate the shaders and prevent the whole library compiling when adding nodes etc. Even so, some single shaders can become quite complex during developments so I suppose we'd need to find other ways to approach look development to mitigate this slowness.
J
I notice that the material library becomes sluggish very quickly when one is left to noodle. In this example I've created 64 Principled shaders and connected a singular UV Triplanar Project to illustrate the issue. If I now try and edit the network, I can be waiting 10s of seconds for an update.
This example is a bit silly and one could be using 'material builders' to segregate the shaders and prevent the whole library compiling when adding nodes etc. Even so, some single shaders can become quite complex during developments so I suppose we'd need to find other ways to approach look development to mitigate this slowness.
J
Solaris and Karma » Geo/Mesh Light AOVs in Karma
- protean
- 72 posts
- Offline
Oh, maybe it's not that practical to have it as an option by default. I just recreated the same workflow from the Karma standard vars and filtered by name *LGT_GEO* so as not to go crazy. Would there be a way to filter the for loop by the existance of a primvar?
Solaris and Karma » Geo/Mesh Light AOVs in Karma
- protean
- 72 posts
- Offline
Hi,
If I have the workflow for geo lights in Karma correct, one uses Render Geometry Settings to set the 'treat as light' attribute, then I can also set up the LPE for it at the same time.
However we don't get a per-light AOV for geo lights with the regular Karma Render Settings LOP as it only cycles through light primitive types. In the attached example I just manually set the light path from one light source as a test so it would just be a matter of cycling trough mesh types as well as lights. Perhaps this could be an RFE for the karma Render Settings HDA, or is there another way to get light AOVs from geo lights?
If I have the workflow for geo lights in Karma correct, one uses Render Geometry Settings to set the 'treat as light' attribute, then I can also set up the LPE for it at the same time.
However we don't get a per-light AOV for geo lights with the regular Karma Render Settings LOP as it only cycles through light primitive types. In the attached example I just manually set the light path from one light source as a test so it would just be a matter of cycling trough mesh types as well as lights. Perhaps this could be an RFE for the karma Render Settings HDA, or is there another way to get light AOVs from geo lights?
Edited by protean - 2023年6月30日 11:59:31
Solaris and Karma » Custom AOVs with Principled Shader Workflow
- protean
- 72 posts
- Offline
Hello,
I was wondering what an appropriate shader workflow would be for custom AOVs (from shader not primvars) when not using MaterialX.
I can use a bind VOP to export any shader derived data when I build inside a Material Builder but is it possible to have a similar workflow as with the MaterialX dot node when making MatX shader networks outside of a builder? This isn't possible with 'bind' at that level as multiple binds with the same name have the usual issues, also it doesn't work when using the complied Principle Shader.
Cheers,
j
I was wondering what an appropriate shader workflow would be for custom AOVs (from shader not primvars) when not using MaterialX.
I can use a bind VOP to export any shader derived data when I build inside a Material Builder but is it possible to have a similar workflow as with the MaterialX dot node when making MatX shader networks outside of a builder? This isn't possible with 'bind' at that level as multiple binds with the same name have the usual issues, also it doesn't work when using the complied Principle Shader.
Cheers,
j
Edited by protean - 2023年6月29日 06:55:41
Solaris and Karma » Align Transform LOP's pivot to existing primitive
- protean
- 72 posts
- Offline
NP!
I forgot to add the useful info about how transforms are local but the default in the Transform LOP is to force it to world https://www.sidefx.com/docs/houdini/nodes/lop/xform.html [www.sidefx.com]
I forgot to add the useful info about how transforms are local but the default in the Transform LOP is to force it to world https://www.sidefx.com/docs/houdini/nodes/lop/xform.html [www.sidefx.com]
Apply Transform in World Space
(Default on) Apply the given transform as if it was in world space. When this is off, the transform is local. Technically, transform operations are always local, but this can be confusing (For example, a parent prim may have a rotation around Z, which will make a local move along X axis actually move the primitive along world Y). So this option exists to let you specify the transform more intuitively in world space, and have the node create a local transform that achieves the same effect.
Solaris and Karma » Align Transform LOP's pivot to existing primitive
- protean
- 72 posts
- Offline
You could try turning off 'Apply Transform in World Space' on the transform LOP. It's not what you asked for but it will maybe work for your intended purpose?
Edited by protean - 2023年6月27日 18:02:05
Solaris and Karma » How to change solaris pop-up menu parameters with Python
- protean
- 72 posts
- Offline
mtucker
That menu is just a parameter on the node, like any other. Therefore changing the menu just requires setting the corresponding parameter value. What is it that you find weird about this?
I guess because if one would think the parm name is "karma:global:engine_control-xn__karmaglobalengine_control_rhbg" as it appears in the edit parameter interface window?
However it's set referenced in two different ways as far as I can see. No big deal.
parm("xn__karmaglobalengine_control_rhbg").set('set')
or
parm(hou.text.encode('karma:global:engine_control')).set('set')
Edited by protean - 2023年6月27日 17:38:44
Solaris and Karma » How to change solaris pop-up menu parameters with Python
- protean
- 72 posts
- Offline
It seems a bit fluffy right?
I'm not sure I do it in any fantastic way but this works
https://www.sidefx.com/forum/topic/86533/?page=1#post-374166 [www.sidefx.com]
I'm not sure I do it in any fantastic way but this works
import hou sel = hou.selectedNodes()[0] sel.parm(hou.text.encode('karma:global:engine_control')).set('set')
https://www.sidefx.com/forum/topic/86533/?page=1#post-374166 [www.sidefx.com]
Solaris and Karma » Karma - Turn Off Self Shadowing On Particular Objects
- protean
- 72 posts
- Offline
Or -shadow also works if you want it visible in indirect See render visibility here: https://www.sidefx.com/docs/houdini/props/karma.html [www.sidefx.com]
Edited by protean - 2023年6月21日 07:55:15
Solaris and Karma » SDF_FORMAT_ARGS for binary vs. ascii usds
- protean
- 72 posts
- Offline
Thank Bryan
I think I didn't explain it well enough though. I understand the idea you describe well enough, what is a bit perplexing is that; even if I manually save that sublayer as a binary file at some later date, nothing breaks even though the sublayer reference has the ascii format argument. So it seems a little defunct.
I'm just wondering if it matters at all or if I'm going to regret ignoring the format as specified by the argument at some point in the future.
I think I didn't explain it well enough though. I understand the idea you describe well enough, what is a bit perplexing is that; even if I manually save that sublayer as a binary file at some later date, nothing breaks even though the sublayer reference has the ascii format argument. So it seems a little defunct.
I'm just wondering if it matters at all or if I'm going to regret ignoring the format as specified by the argument at some point in the future.
Edited by protean - 2023年6月20日 12:27:45
Solaris and Karma » SDF_FORMAT_ARGS for binary vs. ascii usds
- protean
- 72 posts
- Offline
Hi,
What is the significance of the format args written after the usd reference?
As far as I can tell, if the alayer.usd is either binary or ascii it works in the example above. Similarly if the the sdf format option isn't there it doesn't matter the format of the the .usd. I'm just wondering whether to use extensions or these format arguments as the identifier for binary vs. ascii. These args are introduced when the config layer LOPs have this specified or an output processor on the 'master' USD ROP forces the formatting.
Cheers,
J
What is the significance of the format args written after the usd reference?
subLayers = [ @./alayer.usd:SDF_FORMAT_ARGS:format=usda@ ]
As far as I can tell, if the alayer.usd is either binary or ascii it works in the example above. Similarly if the the sdf format option isn't there it doesn't matter the format of the the .usd. I'm just wondering whether to use extensions or these format arguments as the identifier for binary vs. ascii. These args are introduced when the config layer LOPs have this specified or an output processor on the 'master' USD ROP forces the formatting.
Cheers,
J
Edited by protean - 2023年6月20日 11:50:19
Solaris and Karma » Efficient animation caching from SOPs
- protean
- 72 posts
- Offline
After all that I discovered that while removing unnecessary time sampling (by setting default attribs) when saving usda files naturally saves a lot of storage, when saving binary it makes little/no difference. At least in my current asset test.
Solaris and Karma » Efficient animation caching from SOPs
- protean
- 72 posts
- Offline
Cool.
I also discovered a difference if I set the path attrib after packing vs. before the pack. This gives me something to noodle with for a while, thank you!
J
I also discovered a difference if I set the path attrib after packing vs. before the pack. This gives me something to noodle with for a while, thank you!
J
Solaris and Karma » Efficient animation caching from SOPs
- protean
- 72 posts
- Offline
Hi! Yeah in my haste to make the simplest file possible I forgot to se the 'topology attributes' to static. Nevertheless I still get time sampled point positions of the static mesh.. where it's defined in the usda.
I was thinking I only need to author the transforms... a bit like how its described here: https://openusd.org/release/tut_xforms.html [openusd.org]
.. but I'm obviously trying to do it and understand it with vanilla Houdini tools
Surely all I would need authored is the xform
I was thinking I only need to author the transforms... a bit like how its described here: https://openusd.org/release/tut_xforms.html [openusd.org]
.. but I'm obviously trying to do it and understand it with vanilla Houdini tools
Surely all I would need authored is the xform
def Xform "myasset" ( kind = "component" ) { def Xform "sphere" { token visibility.timeSamples = { 1: "inherited", 2: "inherited", 3: "inherited", 4: "inherited", } matrix4d xformOp:transform.timeSamples = { 1: ( (1, 0, 0, 0), (0, 0.9848077297210693, 0.1736481785774231, 0), (0, -0.1736481785774231, 0.9848077297210693, 0), (-1, 0.06979899335956041, 0, 1) ), 2: ( (1, 0, 0, 0), (0, 0.9396926164627075, 0.3420201539993286, 0), (0, -0.3420201539993286, 0.9396926164627075, 0), (-1, 0.13951294594943064, 0, 1) ), 3: ( (1, 0, 0, 0), (0, 0.8660253882408142, 0.5, 0), (0, -0.5, 0.8660253882408142, 0), (-1, 0.20905692875385284, 0, 1) ), 4: ( (1, 0, 0, 0), (0, 0.7660444378852844, 0.6427876353263855, 0), (0, -0.6427876353263855, 0.7660444378852844, 0), (-1, 0.27834622136391296, 0, 1) ), } uniform token[] xformOpOrder = ["xformOp:transform"] } }
Edited by protean - 2023年4月17日 14:08:59
Solaris and Karma » Efficient animation caching from SOPs
- protean
- 72 posts
- Offline
Hi,
We've been using alembic animation referenced into LOPs up to now but having tested a bit with USD caches there are some interactivity improvements. However I've run into some fundamental problems even in the simplest of scenes. Perhaps my understanding of the possibilities is flawed here.
When I export a USD from SOPs (which appears to just be a wrapper for a LOPs SOP import anyway) with packed prims I seem to get the static mesh with time sampled position and vertex attribs and then a transform primitive with the animation of the packed prim. The whole point of this exercise is to avoid caching anything other than the transform. I'm also not sure what the use case for such output would be. I can obviously post fix this by deleting the mesh prim and exporting again but that can't be a good workflow.
Related to this; I know I can reference the xform over the mesh directly without too much issue but I'm guessing any transforming geo/mesh really should have an appropriate hierarchy with a parent xform.
We've been using alembic animation referenced into LOPs up to now but having tested a bit with USD caches there are some interactivity improvements. However I've run into some fundamental problems even in the simplest of scenes. Perhaps my understanding of the possibilities is flawed here.
When I export a USD from SOPs (which appears to just be a wrapper for a LOPs SOP import anyway) with packed prims I seem to get the static mesh with time sampled position and vertex attribs and then a transform primitive with the animation of the packed prim. The whole point of this exercise is to avoid caching anything other than the transform. I'm also not sure what the use case for such output would be. I can obviously post fix this by deleting the mesh prim and exporting again but that can't be a good workflow.
Related to this; I know I can reference the xform over the mesh directly without too much issue but I'm guessing any transforming geo/mesh really should have an appropriate hierarchy with a parent xform.
Image Not Found
Edited by protean - 2023年4月17日 13:30:29
Solaris and Karma » Mute Layer and Payloads
- protean
- 72 posts
- Offline
It seems 'muting' isn't a state that persists if the stage is edited so the alternative is indeed to 'not load' the sublayer(s) one doesn't want. Not very USD but I suspect it's quite a common strategy
J
J
Solaris and Karma » Querying sublayers with GetCompositionAssetDependencies()
- protean
- 72 posts
- Offline
Hi,
So I can get a list of sublayers in a usd with GetCompositionAssetDependencies() [graphics.pixar.com] but is there any way to preserve the ordering? This returns an alphabetical list of sublayers.
Cheers,
J
So I can get a list of sublayers in a usd with GetCompositionAssetDependencies() [graphics.pixar.com] but is there any way to preserve the ordering? This returns an alphabetical list of sublayers.
Cheers,
J
Solaris and Karma » Mute Layer and Payloads
- protean
- 72 posts
- Offline
If I drop a configure layer LOP (with no changes) before referencing the cube then it works as expected
Solaris and Karma » Mute Layer and Payloads
- protean
- 72 posts
- Offline
Hi,
I have some odd issue with layer muting and payloads.
In this very basic example I have a shot USD with an animation layer which consists of a payload to to the cube and a reference to the animation of it.
When I load the shot.uds and mute the animation layer everything looks normal (the cube no longer 'exists' ). However, when I load the reference to the static cube again as a payload the animation is still occurring. If I load the cube as a regular reference the cube is static, as I would expect.
The idea here being I want to mute the layer and rebuild it rather than retain what was there before.
I have some odd issue with layer muting and payloads.
In this very basic example I have a shot USD with an animation layer which consists of a payload to to the cube and a reference to the animation of it.
When I load the shot.uds and mute the animation layer everything looks normal (the cube no longer 'exists' ). However, when I load the reference to the static cube again as a payload the animation is still occurring. If I load the cube as a regular reference the cube is static, as I would expect.
The idea here being I want to mute the layer and rebuild it rather than retain what was there before.
Edited by protean - 2023年2月27日 05:14:02
-
- Quick Links