Hey,
After doing some digging, I'm trying to narrow down the current "deal breaker" limitations with: Solaris + HtoA
If there is a list somewhere, please let me know!
Currently it seems we're missing:
These are pretty massive limitations and I'd say that Solaris + HtoA isn't production ready.
Is there anything else I'm missing / list is accurate?
Additionally, I'd also like to confirm:
Still investigating but any info would be great!
Trying to determine if Solaris would be considered production ready to use in conjunction with Arnold but it doesn't seem to be the case.
Houdini: 18.5.462
HtoA: 5.6.0.0
Arnold: 6.2.0.0
All the best,
Andrew
Solved! Go to Solution.
Solved by pal.mezei. Go to Solution.
2. There's no auto tx feature right now, so you have to generate the tx files and then use the tx as the image filename. You'd have to use the right color spaces too, normally the auto tx would read the color space from the image node and pass the right colorconvert flag to maketx
I would look at using path mapping to replace png/exr/tif whatever with tx
https://arnoldsupport.com/2020/08/06/remapping-paths-at-render-time/
Hi,
Thank you, glad to hear it should work!
Yes, we've been using "Use Existing TX" feature for years but I noticed that it doesn't exist on the rendersettings node in Solaris, so wanted to confirm that's is working as intended.
Hey!
Adding a few more bits on top of Stephen's excellent answers:
3, This is not yet available in a released HtoA, but we have recently added ways to render custom Arnold schemas directly in Solaris. (see https://github.com/Autodesk/arnold-usd/issues/185) This allows you to render in Solaris using Arnold procedurals. This can potentially improve performance, but you can't use USD native tools directly to edit primitives in the procedural. We are looking into exposing operators to Solaris, which would circumvent this limitation.
4, When rendering through Solaris and Husk, HtoA and our render delegate are not responsible for writing out the rendered images to the disk, so you need to look for these controls on the Render Product and the Render Var LOP.
Render Product writes all the associated Render Vars into a single EXR file, so "Merge AOVs" is not something you need to enable.
The same goes for using half-precision, if you look at the Render Var LOP, you can either set the "Data Type" to half3 or half4 (so all the information is stored in a half-precision Hydra render buffer), or set the Format to color3h or color4h, so husk writes the render buffer into a half-precision EXR layer.
5, We don't expose any motion blur settings on the render settings node. There are two ways of setting up the motion blur settings (but this is mostly WIP, so the last released HtoA might not have everything).
- Use the motion blur tab on the Render Geometry Settings LOP to control the Transform Type and the number of Deform Keys. Thought Deform Keys only affect the scene if we have to use the velocity attribute to extrapolate position.
- Set shutter range, shutter filter, rolling shutter, and rolling shutter duration on the Camera LOP.
Note: the render delegate receives point positions from Hydra, but we can't explicitly request a given number of motion keys. Generally, Hydra will give us as many motion keys as available in the given shutter range (set on the Camera LOP).
Hey Klaus!
Yes, we finished adding support for deep rendering (https://github.com/Autodesk/arnold-usd/issues/650) after we finished preparing the release, so the feature didn't make it.
first of all Solaris itself is not production ready, not even simple stuff like render region exits in solaris. the image viewer itself its joke, its crashes or handing in zoom level.... sidefx needs a least 2 more years to produce something meaning full working as lighting/render tool. even solaris with karma it crashes every 10 minutes of you actually try use it with production scenes.
second USD is not production ready it moving target. its changing standards all the time. its only useful with use custom pipeline from pixar or animal logic. everybody else try aviod USD because of it constant changes and extensions.
Hi,
Looks like arnold for Solaris now supports shader aovs. Checked this test https://github.com/Autodesk/arnold-usd/blob/6acd17123341c108f86b6bd4731dc04d9ee2a417/testsuite/test_... Atmosphere shader works fine.
But we want to get Cryptomatte in the same way. Is this possible at the moment?
@it8GY2P wrote:
Hi,
Looks like arnold for Solaris now supports shader aovs. Checked this test https://github.com/Autodesk/arnold-usd/blob/6acd17123341c108f86b6bd4731dc04d9ee2a417/testsuite/test_... Atmosphere shader works fine.
But we want to get Cryptomatte in the same way. Is this possible at the moment?
That's arnold-usd, not Solaris.
After something is added in arnold-usd, there's another step: exposing it in Solaris. That's still in the works...
Hi Stephen,
Thanks for answer. I meant that if there is support in the delegate itself now, can we implement Cryptomate via ArnoldNodeGraph and inline usd node or not?
Been using it for month now. Crashing very often. Thinking of migrating whole project to Karma.
Another limitation that I don't seem to be able to get away from is that we are only able to render square pixel aspect ratio no matter what the options in Solaris with Arnold. I believe there are some tickets but nothing has been implemented yet, which for me it is a deal breaker for sure.