Update: Update: This is now with SideFX as a bug

Hi there,

I have noticed that the Houdini Ocean procedural seems to dice the geometry based on Render-Camera. That despite my efforts to set a different camera as the "Dicing Camera" in karma render settings. Reason for doing this is because we are rendering an ocean with a camera lens set to "polar" Also unable to calculate proper dicing if set to the main render-cam. We simply want to set up a top view camera for our dicing.
This happens both in XPU and CPU.

My theory is that the Houdini Procedural generating the ocean displacement based on the spectra is simply looking at the render-camera and disregarding the Dicing Camera.

I can't see any primvars on the ocean procedural prim related to what dicing camera it is using/overriding either.

Ps. this happens when rendering to disk as well as in the viewport.

We have tried multiple solutions:
Overriding the camera in the USD render Rop will still only dice the final selected render cam.
The only current approach we have that works is to bake the dicing level as geometry. Obv a bit heavy and hopefully unnecessary.

Tried on Win 11, Amd ryzen 9 7900x with 4070 TI Super and Intel i9 14900kf, 4090. H20.5.278

Attached a simple pic explanation + a simple file.

Any suggestions/help is appreciated.

Cheers,
Huds

I've tried to render ocean in Karma XPU with a polar camera without success(
Did you found any solution?

Vladimir Shelest
I've tried to render ocean in Karma XPU with a polar camera without success(
Did you found any solution?

Hi Vladimir,

This current dicing issue stated above is with SideFX logged as a ticket already and correct a polar lens will not work accordingly.

What we ended up doing was to bake in the spectra as geometry and render that instead. You can then do your own distance based LOD.
It will the most reliable approach for a polar camera and keeping it light. This is also what sideFX recommended as a work-around.

It was a while ago we were trying this so if anyone else finds another work-around/solution for the time being it would be awesome

Hudson M

Vladimir Shelest
I've tried to render ocean in Karma XPU with a polar camera without success(
Did you found any solution?

Hi Vladimir,

This current dicing issue stated above is with SideFX logged as a ticket already and correct a polar lens will not work accordingly.

What we ended up doing was to bake in the spectra as geometry and render that instead. You can then do your own distance based LOD.
It will the most reliable approach for a polar camera and keeping it light. This is also what sideFX recommended as a work-around.

It was a while ago we were trying this so if anyone else finds another work-around/solution for the time being it would be awesome

Hi, Hudson!
How are you
(I just realized that this is you only when I read your answer Small Houdini world)

At the beginning I've tried to create several cameras, render them all together and stitch. I found that solution pretty weird but in general it is working.

Today I've tried your/SideFX solution and bake the geometry.
Did you try to bake displacement as a texture and apply it to geometry? I will try to do that and compare which way is faster
But I think the result will be the same

Vladimir Shelest
Did you try to bake displacement as a texture and apply it to geometry? I will try to do that and compare which way is faster
But I think the result will be the same

I am glad to hear you found a good workaround man!
We didn't go to that level. Raw geo was enough with a higher spectral value + foam + spray etc.

I didn't bake the geo as displacement mainly because we wanted a LOD approach. for a polar camera baking displacements into textures might be a waste of texture space(spherical coverage from camera centre, different resolutions in different textures) if that makes sense?

Hence we went for a high res Geo. Just a few million points that quickly became lower res depending on distance to camera.
PS. we had to render with XPU to make it in time. So keeping everything light was necessary.

With your approach however if you are using multiple cameras you could have separate Geo for each and bake the texture for each one. From personal testing I found that a 8k texture displacement is cheaper in Vram than a prebaked 8k Geometry resolution because of camera dicing(But this was working with mountains and heightfields. I could be wrong)

If you have multiple cameras the dicing shouldn't be an issue since it will dice based on your render camera anyways right? I imagine you have one render-rop for each of them, or did I misunderstand your workflow?

Hope it all goes well

Hudson M

Vladimir Shelest
Did you try to bake displacement as a texture and apply it to geometry? I will try to do that and compare which way is faster
But I think the result will be the same

I am glad to hear you found a good workaround man!
We didn't go to that level. Raw geo was enough with a higher spectral value + foam + spray etc.

I didn't bake the geo as displacement mainly because we wanted a LOD approach. for a polar camera baking displacements into textures might be a waste of texture space(spherical coverage from camera centre, different resolutions in different textures) if that makes sense?

Hence we went for a high res Geo. Just a few million points that quickly became lower res depending on distance to camera.
PS. we had to render with XPU to make it in time. So keeping everything light was necessary.

With your approach however if you are using multiple cameras you could have separate Geo for each and bake the texture for each one. From personal testing I found that a 8k texture displacement is cheaper in Vram than a prebaked 8k Geometry resolution because of camera dicing(But this was working with mountains and heightfields. I could be wrong)

If you have multiple cameras the dicing shouldn't be an issue since it will dice based on your render camera anyways right? I imagine you have one render-rop for each of them, or did I misunderstand your workflow?

Hope it all goes well

Hudson,
Yes, you are right. I had one render rop for each camera. Little bit weird but in general it is just more work in comp.
I've tried to bake texture and yes, you were right - no any advantages in render time, just a waste of texture space (I had a time to try all solutions to compare the results).
Finally I did the same like you and sideFX suggested to you. High resolution geo working well with polyreducing depended on distance from camera.
Hope SideFX will fix this bug sooner or later... or nobody will make an ocean with a polar camera again ever)

All the best, Hudson.