Found 33 posts.
Search results Show results as topic list.
Solaris and Karma » Swapping payload in LOP without saving stage first
- pixelninja
- 33 posts
- Offline
You could try a switch pointing to a reference to the payload on disk. Then you can control the switch with a context option on the ROP.
Technical Discussion » Attribute wrangle in Solaris
- pixelninja
- 33 posts
- Offline
I know this is an old thread but I was having this issue myself so I wanted to share the solution.
Make sure to set frame sampling on the attribute wrangle as well.
In my case when I use an attribute wrangle over an array it will set the length of the array to be exactly same on every frame unless frame sampling is on. This caused so many crazy render issues until I figured it out.
I'm not sure if it's a bug or just another quirk of the whole Solaris/USD way of doing things.
Make sure to set frame sampling on the attribute wrangle as well.
In my case when I use an attribute wrangle over an array it will set the length of the array to be exactly same on every frame unless frame sampling is on. This caused so many crazy render issues until I figured it out.
I'm not sure if it's a bug or just another quirk of the whole Solaris/USD way of doing things.
Solaris and Karma » SOP Intrinsic: usdViewportPurpose
- pixelninja
- 33 posts
- Offline
Heileif
Im only on my phone.
But if I remember correctly you only need create a string attribute named purpose with purpose you want as value.
That's definitely the case for sending geo from sops to lops. I think cdordelly is asking about a clear attribute to show what the purpose was when getting geo into sops from lops.
I had a quick look and I ran into the same thing, an intrinsic array is created that ends up being the same across all geo so you need to rely on the path to determine the purpose.
Solaris and Karma » Karma PNG bit depth
- pixelninja
- 33 posts
- Offline
Yeah just trying to avoid any double handling of renders.
I agree it's not ideal, I'm just trying to meet the preference of the comper.
The project is EXTREMELY large scale and so it's an odd case in that filesize is more important than precision. I'm already having to normalise the data to fit the 0-1 range for the pngs anyway.
I might be able to convince them to go with compressed exr sequences if I can get the data into the colour channel to avoid them having to extract it for every pass.
I agree it's not ideal, I'm just trying to meet the preference of the comper.
The project is EXTREMELY large scale and so it's an odd case in that filesize is more important than precision. I'm already having to normalise the data to fit the 0-1 range for the pngs anyway.
I might be able to convince them to go with compressed exr sequences if I can get the data into the colour channel to avoid them having to extract it for every pass.
Solaris and Karma » Karma PNG bit depth
- pixelninja
- 33 posts
- Offline
I figured it might be unlikely but thought I'd ask just in case.
The comper is specifically requesting separate png sequences.
Bonus question for anyone out there:
Can you render AOVs as exrs but to the C(rgba) channel?
If I output an AOV as a separate sequence, depth for example, it will output an exr sequence with no colour data and depth in the depth channel, requiring compositors who use After Effects to make the extra step of extracting the AOV data out to be used. Effectively being forced to use the multichannel workflow on single channel sequences.
The comper is specifically requesting separate png sequences.
Bonus question for anyone out there:
Can you render AOVs as exrs but to the C(rgba) channel?
If I output an AOV as a separate sequence, depth for example, it will output an exr sequence with no colour data and depth in the depth channel, requiring compositors who use After Effects to make the extra step of extracting the AOV data out to be used. Effectively being forced to use the multichannel workflow on single channel sequences.
Solaris and Karma » Rendering Particles as Volumes / Disks in Arnold in Solaris
- pixelninja
- 33 posts
- Offline
With a Render Geometry Settings LOP under "Geometry" you can set "Render points as" to either Discs or Oriented Discs.
Not sure about rendering them as volumes though.
Not sure about rendering them as volumes though.
Solaris and Karma » Karma PNG bit depth
- pixelninja
- 33 posts
- Offline
Does anyone know of a way to set the bit depth of png renders from Karma?
They seem to always come out 8 bits per channel.
They seem to always come out 8 bits per channel.
Solaris and Karma » Correct way to get instancer using variants
- pixelninja
- 33 posts
- Offline
Ok I still get the "recomposing stage on stage" warning but I've figured out the workflow.
Key things I was missing:
1. Explore variands node needs to be set to mode "Explore Variants" with a spacing of 0
2. The instancer needs to have "Only copy specified prototype primitves" unchecked (this is noted in the docs).
The only downside is that with this method I lose texture display in the viewport.
Key things I was missing:
1. Explore variands node needs to be set to mode "Explore Variants" with a spacing of 0
2. The instancer needs to have "Only copy specified prototype primitves" unchecked (this is noted in the docs).
The only downside is that with this method I lose texture display in the viewport.
Solaris and Karma » Correct way to get instancer using variants
- pixelninja
- 33 posts
- Offline
Yeah I tried that but then it just throws a different warning.
Warning Unable to relocate reference: /pig
Warning In </instancer1/Prototypes/explorevariants1/pig/geo_easy_mtl_default>: Unresolved reference prim path @anon:0x2df147ae0:LOP:rootlayer@</pig> introduced by @anon:0x2df149680:LOP@</instancer1/Prototypes/explorevariants1/pig/geo_easy_mtl_default> (recomposing stage on stage @anon:0x2df147ae0:LOP:rootlayer@ <0x14aa17200>)
Warning Unable to relocate reference: /pig
Warning In </instancer1/Prototypes/explorevariants1/pig/geo_easy_mtl_default>: Unresolved reference prim path @anon:0x2df147ae0:LOP:rootlayer@</pig> introduced by @anon:0x2df149680:LOP@</instancer1/Prototypes/explorevariants1/pig/geo_easy_mtl_default> (recomposing stage on stage @anon:0x2df147ae0:LOP:rootlayer@ <0x14aa17200>)
Edited by pixelninja - March 25, 2024 21:53:52
Solaris and Karma » Correct way to get instancer using variants
- pixelninja
- 33 posts
- Offline
I'm having some troubles with this workflow too.
A simple Pig Head -> Explore Variants -> Instancer (2nd input) throws composition arc warnings.
Primitive is embedded in a composition arc: /explorevariants1/pig/geo_easy_mtl_default
It would be necessary to flatten the stage to access it.
Is there something I'm doing wrong?
Flattening the stage before connecting to the instancer second input works but that's not ideal.
Using a duplicate LOP with reference type set to copy then manually setting each variant seems to work, but that's basically the same manual workflow outlined by am_wilkins above.
A simple Pig Head -> Explore Variants -> Instancer (2nd input) throws composition arc warnings.
Primitive is embedded in a composition arc: /explorevariants1/pig/geo_easy_mtl_default
It would be necessary to flatten the stage to access it.
Is there something I'm doing wrong?
Flattening the stage before connecting to the instancer second input works but that's not ideal.
Using a duplicate LOP with reference type set to copy then manually setting each variant seems to work, but that's basically the same manual workflow outlined by am_wilkins above.
Solaris and Karma » Attributes losing data depending on usdprimtype
- pixelninja
- 33 posts
- Offline
Primary question:
Is there any way of setting the usdprimtype to something other than "Points" while still allowing the attributes to import as if it were set to "Points"?
Context:
I'm playing around with editing a SkelAnimation prim from SOPs and I'd like to be able to override the translations, rotations and scales attributes.
I can get the translations attribute to override correctly with the usdprimtype unset or set to "Points", however once I set the usdprimtype to "SkelAnimation" the translations attribute only contains the first element (i.e. it goes fromto ).
The alternative is to alter the attributes in python, which I've tested and works fine, however it would be such a convenient workflow to be able to simply tweak your SkelAnimation in a SOP Modify.
Is there any way of setting the usdprimtype to something other than "Points" while still allowing the attributes to import as if it were set to "Points"?
Context:
I'm playing around with editing a SkelAnimation prim from SOPs and I'd like to be able to override the translations, rotations and scales attributes.
I can get the translations attribute to override correctly with the usdprimtype unset or set to "Points", however once I set the usdprimtype to "SkelAnimation" the translations attribute only contains the first element (i.e. it goes from
float3[54]
float3[1]
The alternative is to alter the attributes in python, which I've tested and works fine, however it would be such a convenient workflow to be able to simply tweak your SkelAnimation in a SOP Modify.
Edited by pixelninja - Sept. 22, 2023 02:43:03
Solaris and Karma » Building Components in SOPs: Hierarchies and KineFX
- pixelninja
- 33 posts
- Offline
I managed to find some time to make this tutorial on building USD hierarchies in SOPs.
I couldn't find many resources on things like setting pivots and altering transforms so once I figured it all out I thought I'd share the approach.
Hope someone out there finds it useful.
Edited by pixelninja - Sept. 19, 2023 22:33:44
Solaris and Karma » Problem rendering a simple VDB sequence
- pixelninja
- 33 posts
- Offline
I've just run a quick test and can't replicate it again. Which leads me to thinking that in my case the problem was either Redshift or possibly forgetting to correctly cache the LOP network (or that it's a smaller test, or that I'm testing on my M1 mac, or some other thing I haven't thought of).
Assuming the time dependency thing is your issue:
If you have a time dependency then your vdb sequence won't render properly with "Render All Frames With a Single Process".
Setting the frame range on the volume LOP or putting down a cache LOP should do the job.
Assuming the time dependency thing is your issue:
If you have a time dependency then your vdb sequence won't render properly with "Render All Frames With a Single Process".
Setting the frame range on the volume LOP or putting down a cache LOP should do the job.
Solaris and Karma » Problem rendering a simple VDB sequence
- pixelninja
- 33 posts
- Offline
Same question here.
I had issues with doing this when rendering in Karma, and am currently testing with Redshift.
For me it will load and render the first vdb on every frame.
Does the fact that husk needs to load a new vdb on each frame mean that the single process option simply can't be used or is there a trick to it?
I had issues with doing this when rendering in Karma, and am currently testing with Redshift.
For me it will load and render the first vdb on every frame.
Does the fact that husk needs to load a new vdb on each frame mean that the single process option simply can't be used or is there a trick to it?
Solaris and Karma » Referencing primvars in output path
- pixelninja
- 33 posts
- Offline
tamte
I'm also curious how the proposed stage variables [openusd.org] will come into play if implemented
That looks incredibly useful. I love the expression functionality proposed too.
Solaris and Karma » Referencing primvars in output path
- pixelninja
- 33 posts
- Offline
Thanks, that sounds like a great solution. I'll give that a go!
Sorry for not being more specific earlier.
I found that for simple seqeuences with little variation between shots it was easier to have a single rop (or multiples if I need separate passes) which I could point a topnet at to batch out all of the shots. The switch being necessary to add any required variation.
I was using pdg_variables initially but I like to avoid them where possible to keep my networks pdg agnostic as it simplifies thing when you want to rerender specific shots manually.
Sorry for not being more specific earlier.
I found that for simple seqeuences with little variation between shots it was easier to have a single rop (or multiples if I need separate passes) which I could point a topnet at to batch out all of the shots. The switch being necessary to add any required variation.
I was using pdg_variables initially but I like to avoid them where possible to keep my networks pdg agnostic as it simplifies thing when you want to rerender specific shots manually.
Solaris and Karma » Referencing primvars in output path
- pixelninja
- 33 posts
- Offline
The whole impetus behind the question was that I had a network with a bunch of branches at the top leading down (through a switch) to a single render settings lop and usd render rop, and I was looking for a simple way of sticking an attribute on each branch and then referencing that with an @ variable into the output image on the render settings.
What we've discussed here has shown that the built in system for setting and @ referencing variables (context options) works upwards. Therefore in order for this to work in my case, where the branches are a the top of the node tree, I would need to rearrange things such that the shared render setting node is at the top of the tree, this would then branch out to each branch (which will set a convext option) then down through the switch and finally the rop. The render setting now being at the top of the tree enables it to pick up the branch specific context option via the selection on the downstream switch node.
Thanks for enumerating all of those methods, but specifically I was looking for one that works with @ referencing (rather than needing to read back the value with python) which I don't think any of those allow right? I did suspect that maybe custom data on the /HoudiniLayerInfo prim might work though... I can also use a python expression to grab data from wherever, however that's less clear than being able to simply say "$HIP/render/`@shot`.$F4.exr" or whatever.
It's all good, thanks so much for your help. It's clear that my current approach is working against the tools and not with them.
What we've discussed here has shown that the built in system for setting and @ referencing variables (context options) works upwards. Therefore in order for this to work in my case, where the branches are a the top of the node tree, I would need to rearrange things such that the shared render setting node is at the top of the tree, this would then branch out to each branch (which will set a convext option) then down through the switch and finally the rop. The render setting now being at the top of the tree enables it to pick up the branch specific context option via the selection on the downstream switch node.
Thanks for enumerating all of those methods, but specifically I was looking for one that works with @ referencing (rather than needing to read back the value with python) which I don't think any of those allow right? I did suspect that maybe custom data on the /HoudiniLayerInfo prim might work though... I can also use a python expression to grab data from wherever, however that's less clear than being able to simply say "$HIP/render/`@shot`.$F4.exr" or whatever.
It's all good, thanks so much for your help. It's clear that my current approach is working against the tools and not with them.
Solaris and Karma » Referencing primvars in output path
- pixelninja
- 33 posts
- Offline
You're right. I hadn't noticed it doing that, possibly as I'm not manually rendering. Thanks for the warning.
I'll switch back to pdg variables just to be safe, as that's what I've been using up until now.
Does this mean that the only way to pass a string variable down the node tree is by using primvars and then reading them back with a python expression? Is there no way of @ referencing some kind of data point passed down the tree?
In my case this could all be solved by simply putting the render settings at the top of the node tree, but it feels wrong not to have it next to the render rop for some reason haha.
I'll switch back to pdg variables just to be safe, as that's what I've been using up until now.
Does this mean that the only way to pass a string variable down the node tree is by using primvars and then reading them back with a python expression? Is there no way of @ referencing some kind of data point passed down the tree?
In my case this could all be solved by simply putting the render settings at the top of the node tree, but it feels wrong not to have it next to the render rop for some reason haha.
Solaris and Karma » Referencing primvars in output path
- pixelninja
- 33 posts
- Offline
Here's my findings on this in case it helps anyone.
Context options are the way to go. They set variables that can be referenced with the @ syntax.
They can be set manually in the Context Options editor but can also be changed in your node tree.
There are two approaches I've found, each with their own pros and cons.
Edit Context Options LOP
This has a nice interface that allows you to set context options.
Confusingly (at least for me) this will set the context values up the node tree rather than down.
So this node needs to be placed after any node that needs to reference the variables it sets.
Python Script LOP
This lets you set values that can be referenced globally, so both up and down the node tree (and even in separate disconnected node trees, so be careful).
Important to note that context options set with the python script are persistent, so if you bypass or even delete the python script LOP the context option will still be set. I'm not sure if this is a bug or intended but it's something to be aware of.
For my purposes this time I went with the Python Script LOP as I have structured my network such that the shot variables are set at the top of the netork and need to flow down. I don't really recommend this approach though.
In future I will try reorganising my networks to make them work with the Edit Context Options LOP as that is much more controlled (i.e. the context options are only set for specific nodes in the network and this can even be limited with context options blocks).
Context options are the way to go. They set variables that can be referenced with the @ syntax.
They can be set manually in the Context Options editor but can also be changed in your node tree.
There are two approaches I've found, each with their own pros and cons.
Edit Context Options LOP
This has a nice interface that allows you to set context options.
Confusingly (at least for me) this will set the context values up the node tree rather than down.
So this node needs to be placed after any node that needs to reference the variables it sets.
Python Script LOP
hou.setContextOption('name', 'value')
Important to note that context options set with the python script are persistent, so if you bypass or even delete the python script LOP the context option will still be set. I'm not sure if this is a bug or intended but it's something to be aware of.
For my purposes this time I went with the Python Script LOP as I have structured my network such that the shot variables are set at the top of the netork and need to flow down. I don't really recommend this approach though.
In future I will try reorganising my networks to make them work with the Edit Context Options LOP as that is much more controlled (i.e. the context options are only set for specific nodes in the network and this can even be limited with context options blocks).
Edited by pixelninja - March 30, 2023 19:59:50
Solaris and Karma » Retime USD
- pixelninja
- 33 posts
- Offline
Definitely. Though in this case I was attempting to bring in mixed geometry, so some packed geo actually were instances.
Probably better to just split them out into separate imports in this case.
Probably better to just split them out into separate imports in this case.
-
- Quick Links