Hi
Im trying Renderman 23.2 with Houdini 18.0.391
The Renderman Solaris limitations for renderman are slightly confusing for Batch render. I think what they are trying to say is you cannot batch render AOV’s. I have tried with the renderman demo scene for solaris and had no luck at all.
https://rmanwiki.pixar.com/download/attachments/47977077/RenderMan_Solaris_Demo.zip?version=1&modificationDate=1575375024204&api=v2 [rmanwiki.pixar.com]
So after a bit of hunting on Renderman discord. Pixar are implying that it is down to side FX to support AOV’s for third part renderers. Is this correct. And if so is there an eta on this? Best Mark
Interactive Rendering
• AOVs and LPEs are not supported
• CropWindows are not available
• Bucket Order and Bucket Origin options do not work as expected
• Interactive de-noising is not available
• PxrMaterial Builder nodes to not work as expected
• Lighting issues listed above apply in interactive rendering
• The RenderSettings node does not apply to interactive renders
Batch Rendering
• RenderMan Display drivers are not supported
• Lighting issues listed above apply in batch rendering

The USD/Hydra spec already supports AOVs, there's nothing additional that needs to be done from a DCC standpoint. For example, Redshift3D (a 3rd party engine) already supports AOVs in the Hydra viewport.

It would be great to get some clarification on this.

Daryl does Redshift support writing out AOVs in batch render or just interactive in the Hydra viewport?

tnorth
Daryl does Redshift support writing out AOVs in batch render or just interactive in the Hydra viewport?

Yes of course, as its a render output that's simply made available to the viewport, and that's what I was highlighting there with that statement, was that you dont have to use another tool to inspect the AOVs, as they are fully viewable directly in the Hydra viewport - which is a great time saver.

Hi

The plot thickens! I am hoping by 18.5 all this backwards and forwards between 3rd part render apps and sidefx will be ironed out.

Best

Mark

Karma will render AOVs from the USD file. The AOV definitions are just passed through to the render delegate.

`husk -p1 -o test.exr test.usd`

generates a bunch of different AOVs for me. Some of the AOVs are Karma specific, but `diffuse` and `indirectDiffuse` are defined by LPE, so should be valid in any delegate which supports LPE.

mark
…but `diffuse` and `indirectDiffuse` are defined by LPE, so should be valid in any delegate which supports LPE.

does that mean that LPEs are now unified and Karma will support pixar LPE tokens? or will there be some unified LPE syntax in USD?
Because as far as I know every renderer has it's own flavor of LPE's and they are not compatible except for a very basic set that overlaps (if any)
so the fact that some AOV is defined using LPE doesn't automatically mean that other renderer will be able to resolve that particular LPE

There are some common LPE features that many renderers support. Then again, every renderer has its own flavor of LPE. USD allows AOVs to be specified by an LPE, but I think the expression you enter can be customized for a particular delegate.

Hi. So am i correct in saying the only render thst supports aov in solaris right now is karma? I have tried renderman 3delght and arnold. They all seem to have partial support for solaris but either no render settings or no aov. Do chip in if i am wrong. Best mark

Hi Mark, I haven't played with AOVs in LOPs, but this is from the release notes of the most recent Redshift Solaris plugin:

Solaris build 06 (16 Mar. 2020)———————————————————————————————————-
Added support for light groups in the rendervars. The “Remainder” type global AOV can be configured with the “<other>” tag as light group.
Added full support of custom AOVs using the “rs:custom” rendervar. The custom AOV name must match the rendervar node name. The global AOVs materials must be assigned to anything in the scene to use them.
Added support for lights/shadows linking.
Added support for up to 5 downsampling rate levels in the viewport rendering options.
New Redeshit tab in the Solaris Camera LOP. (avaiable in RS 2.6.54 / 3.0.17)
Added support for the Redshift camera options, including all the Redshift camera types, DOF, Photographic Exposure and Lens Shader.
Added support for PostFX (only for batch or finished renderings in the viewports)
Fixed a problem with the integer user data in the mesh and curves objects.
Fixed some issues and crashes related to the shader nodes with multiple outputs.
Fixed a crash while switching renderers or reloading the scene.
Fixed several issues in the Light and DomeLight LOPs GUIs (avaiable in RS 2.6.54 / 3.0.17)
Fixed several threading issues that could be related to rare crashes/freezes at the scene extraction time.
Fixed the batch rendering mode, that was working using the viewports IPR rendering mode.
Added new build for Houdini 18.0.391

Also of note, I think this is the first Hydra delegate to have its own camera options in LOPs (Fish Eye, Photographic Exposure, PostFX etc).

Hi. Thanks for that. For education redshift costs money and they would not give individual licences to my students. The other renderers i mentioned are free for both the university and the student. I guess it is a waiting game. Thanks for the info though best mark

Sure thing, and I'm not suggesting you purchase RS licenses btw. Just pointing out that AOVs already appear to be implemented in at least one 3rd party delegate.

Any update on Solaris + Renderman AOVs? I'm wondering if a suitable workaround would be to define the AOVs in a separate .rib and somehow merge them in? Obviously ideal if they were just supported w/in Solaris. Losing AOVs is kind of a non-starter for us moving over to LOPs :\

Hi Grant.

I know it is not Renderman but 3Delight should be under a month away from supporting Solaris. It might be worth popping over to their discord channel and having a read. Im currently on the Houdini Beta version.

https://discord.gg/MGtJx4q [discord.gg]

Best

Mark