Hudson Martins

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

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

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