Hey All,

I was very easily able to get the Solaris 20.0.688 ocean procedural node and workflow working with Renderman 26.1 with the help of some great people in the technical forum. See this thread https://www.sidefx.com/forum/topic/95413/ [www.sidefx.com]

Things that work:
1) Renderman renders with the native mtlxoceansurface shader.
2) Renderman renders with a custom Renderman PxrSurface shader.

Things that don't work:
1) Renderman can't render with the default mtlxoceaninterior shader. I think it is because there is an kma_volume node in the shader... that is a hybrid node (Karma/MaterialX).
2) I can't render a foam bgeo.sc sequence.. foam doesn't work with RenderMan <-- This is the big reason I am here.

Is there a workaround for these limitations?

Bump... Do any of you at SideFX have any suggestions? You mention that the Ocean tools in Solaris are supported by 3rd party hydra delegates. How do you tap into that information... specifically the foam data.

Todd

Regarding the interior do you need it? In Redshift at least you can get something similar just tweaking the shader on the ocean surface.

I have not tried to get foam working in Redshift only cusp, but a quick look inside the mtlxoceansurface shader it just looks for the foam primvar same as cusp.

Does Renderman read the cusp primvar?

Hey Heileif,

You are correct in that I don't need the volume shader... I just assume that it is critical to getting foam working... The ocean tool is so integrated with Karma... When SideFx mentions that the tool works with 3rd party hydra-delegates, I was hoping that it would have been more plug-and-play. Naive, I know :-). It looks like Renderman can read the cusp attribute/primvar. I just had to boost the intensity to see the effects... I am still lost in how to use that data, and foam is still an issue. Again, if there is anyone at SideFx that would like to join the discussion? The end goal is to get parity between how Karma uses the tool vs how 3rd party hydra-delegates are expected to use the tool.
Heileif, I think the kma_volume shader node plays an important role in the foam stuff. So even though we don't need it in our renderers to get good results, I think it really is needed for foam. SideFx please help :-).

BTW... all screenshots, I am using the native materialx shader... I am not using any pixar shaders.

From the tests I did with Karma I only needed to write the foam out from "houdinioceanprocedural1/ocean_geometry/ocean_surface/bake_foam" and activate "Foam Particles" on the "houdinioceanprocedural1" node.

Looking at the result in Karma, it only seems to be a point cloud transfer onto the displacement ocean mesh.

Are you 100% sure you don't get the foam primvar read into the shader using the same workflow as cusp?

Hey Heileif,

Thank you for pushing me to make sure that I was 100% sure if the foam primvar is read by Renderman... it is being read. :-)
The issue was a two part problem:
1) I should have been on a frame further in the sequence, so it was given time to actually see the "foam"/points to show up on the surface. Even then, it wasn't correct.
2) I had to add the edit material network node for the mtlxoceansurface and change the foam color, foam transmission color, and transmission intensity to get the right look. Not sure why I had to do that. Do you think it is some weird translation issue with how Renderman read transmission info on the materialx network? The attachment isn't anything great.. but I have it working. Not sure why I have to change those colors in Renderman and not in Karma. Isn't materialx, just materialx?

Update: The fact that the renders don't look the same or close to the same between Karma and Renderman is bigger deal than I first thought. Lookdeving the foam color and wave color are a mess in materialx with Renderman. I'll keep trying to figure more of this out. I have attached the scene for anyone to look at. You will have to make the spectrum geo for the ocean and foam.. i didn't include to save on space.

Thanks again.

Could be that Renderman interprets the scene scale differently. Try scaling your ocean surface up or down by 100 and see what results Renderman gives you with the default settings.

Ok.. folk, I figured out the issue :-).. really really simple.
There is a mtlximage node inside the materialx network that creates the ocean surface shader... Karma reads the node with no issue because it is an *.exr file (oceanramp.exr)... Renderman can't use that oceanramp.exr file natively... it needs to convert it to a *.tex file with the colorspace of your choice... in my case (ACES).. so I had to edit the materialx ocean surface shader to fix that.