Shelest Gigamonster

Vladimir Shelest

About Me

Digital artist and the last hope of universe
EXPERTISE
VFX Artist
INDUSTRY
Film/TV

Connect

LOCATION
Bangkok, Thailand

Houdini Skills

ADVANCED
Procedural Modeling  | Environments  | Digital Assets  | Solaris  | Mantra  | Pyro FX  | Fluids  | Destruction FX  | Realtime FX
INTERMEDIATE
Motion Editing  | Animation  | Hair & Fur  | Cloth  | Crowds  | Karma  | Lighting  | PDG  | VEX
BEGINNER
Character Rigging  | Python

Availability

I am available for Full Time Work

Recent Forum Posts

Karma Ocean Proc disregards Dicing camera and uses RenderCam Oct. 7, 2024, 3:37 p.m.

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.

Karma Ocean Proc disregards Dicing camera and uses RenderCam Oct. 7, 2024, 10:39 a.m.

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

Karma Ocean Proc disregards Dicing camera and uses RenderCam Oct. 6, 2024, 2:30 p.m.

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