Experiment: Houdini 19.5 Karma XPU (Beta) and the Remastered Tsunami Scene
It’s been more than a year since I made my tsunami personal work scene and wrote a blog post about it. After learning new things and working for some companies I again found the time to revisit this same scene and try to make it better while checking out Houdini 19.5 and Karma XPU Beta.
Beginning
Contrary to my previous tsunami scene this time the goal was to push the limits of my PC and my skills. I wanted to make everything as detailed and high poly as possible so Karma XPU or any other GPU renderer was out of the question, therefore initially Mantra was going to be my go to renderer this time.
What Changed
Firstly, I spent a lot of time on fixing the collision issues with the bridge, on my previous scene the bridge was not simulating good enough. This bridge model is not modeled for destruction purposes (there are pieces that go inside each other and it is nearly impossible to separate them with procedural means) so I tried a lot of different methods and tricks for the RBD solver to like this geo. Also compared to my previous render the bridge is now rotated 180 degrees on Y because wanted its top part to fill the screen right a bit more.
The house models are completely changed. Previously the houses on the left were simple models with a super simple RBD sim. Now I brought in two destruction ready models from 3dreamlibrary.com and made a detailed RBD sim.
To match the movie reference better (Reference video) I added the ground on the screen left and populated it with detailed objects. And this time these objects also have interaction with the wave so they are not static.
Completely renewed the wave, with a lot more polygons and a new material. Previously it was a relatively low poly geo with noises on top but this time the geo is high poly and has two different ocean spectrum nodes attached to it. Noises with a Mountain SOP or Point VOPs were also working nice but I needed the Ocean Spectrum’s cusp attribute for shading.
Now there are running people on the bridge which is not a crowd sim but a simple instanced pop sim with Houdini’s mocapbidep models. Also added more and different cars.
Completely changed the foam sims which I will write more details about in the next section.
New lighting and compositing for the background. In my previous tsunami scene I used the same HDRI of my Houdini light as my visible background. This time I found a method to bring in any picture into Black Magic Design Fusion and the 3d camera from Houdini, manipulate it; like giving it some curved feel, mirroring it, color correction and placing it according to camera view and used it as the background clouds. Because the 3d camera is there with the cam movement the picture is also seen moving. By using this method, the picture behind is different than the HDRI light that I used in Houdini for lighting because I feel this combination gave me a better result.
About lighting, this time I got rid of the distant light that I used before and just went with the HDRI, that’s all. Also for only the wave I used a different HDRI because it gave a much deeper feeling for it and got significantly better reflections.
Why Karma Again?
Once I got some decent results I decided to do some render tests. My way of working is to render a low resolution (960x540), low sample render overnight and see issues/pitfalls in the morning. However things were not going so good because even the test render was taking more than 10 hours with Mantra. So I decided to go with Karma CPU, not XPU because I wanted to get that beautiful ocean shader Houdini created by default which can only be rendered with Mantra or Karma CPU, in addition utilize the render layers which Karma XPU lacked in Houdini 19. However Karma CPU also didn’t save any time. (Keep in mind that like the previous time I am not using Solaris, just putting down a Karma node in ROP context) Then I exported everything as alembic and imported them into Blender to try to render with Octane which is free. Failure again! Either it was super slow and sometimes it froze or I ran out of VRAM or Blender just crashed.
PC Specs:
i7 9700F 3.0GHz
32GB RAM
RTX 2060
At this point I had to go to Karma XPU again. While I was working for some studios I never had the chance to go into the changes in Houdini 19.5 so wasn’t sure what changed with Karma XPU. Luckily, Karma XPU Beta now supports holdout mattes which allowed me to create render layers (a total of 12 render layers for this shot) and to be able to composite everything easily while having full control.
Losing the awesome ocean material had to be accepted and I tried my best to make a good material X shader for the wave. Using Ocean Spectrum here helped a lot since it gave me the cusp attribute which I used in shading. It was also pretty fast and reliable for a Beta software. Test renders were taking 6–7 hours with 1280x720 resolution and I got to see and identify problems easily with the overnight renders. So again last decision was to go with Karma XPU and push it to its limits.
Simulations
The main actor in this shot is the foam in my opinion. Last time I used pop simulations for foam which is ok but it lacks some of the naturalistic and realistic look/movement of foam. Therefore this time I did a pop sim, then used it in a FLIP sim and then emitted white water (foam). After that rasterized them and turned it into volumes. I wrote on my previous blog post that I had approximately 10 million foam particles on the previous scene, this time I had a total of 46.6 million particles. Turning all those particles into high resolution volumes pushed the limits of my hard disk space and RAM even though they were compressed and optimized. For the main (most visible) foam layer I also rendered the white water particles and mixed them inside Fusion which gave me a more detailed and lively look.
This time there are 6 different foam layers instead of 1. (4 white water vdb layers, 1 particle layer and 1 mist layer) Also for the main foam layer my PC ran out of RAM while simulating, to overcome the low particle counts I separated the sim into two so could use my 32GB of RAM on both sides individually. Yes there is a seam where the simulations are cut but it is so hard to notice and blends with the whole shot when I added all the layers together.
Completely changed the destruction and constraint setup of the bridge. Tried to make it bend and get swallowed by the wave and also collide with it. Of course when it collided the bridge pieces were all stuck on the wave. My first idea was to slowly transform the pieces manually and push them inside the wave. However, even though I tried so many versions the manual transform way gave me unrealistic results. Then I had the idea to scatter some spheres on to the wave and let them collide with the bridge. This way some pieces felt like they collided and were being carried by the wave while others that didn’t get hit by those spheres were left inside the wave. Plus this time the cars are much more visible and their movements are more natural. I used the same scattered sphere collision trick for the cars which worked flawlessly.
For the buildings on screen left, detailed fracture and constraints were used again. I wanted to make the buildings feel heavy and violent while collapsing but also getting pushed and carried with the wave. That took a lot of iterations and time but in my opinion it was worth the struggle. In addition to make some pieces get carried with the wave and some going inside it, I again used the scattered spheres collision method.
Karma and GPU
This time as I said I went with a much more detailed look. All the geos have more points and primitives with the wave being the highest poly one which has 1,382,000 points and 2,761,300 primitives. The wave was a separate layer with mattes and it took 7 min to render per frame on average. Obviously the beginning frames took less time since the wave is smaller and further away and the later frames took longer.
Since the poly counts and volume voxels were a lot higher, at my initial tests I constantly ran out of VRAM. Even though I divided the scene into 12 layers while rendering still the poly counts were high. I did some research and found out that Karma was not happy with all the NVIDIA drivers. Looking into forums I downloaded the version suitable for my RTX 2060 which would make Karma happy. At first I didn’t get any VRAM errors but after a few times of render testing the errors came back which means it was not about the driver but the heavy scene. Therefore I had to go for some more concrete solution which was to delete the points outside of the camera frustum. That helped a lot and I got rid of all VRAM errors. Keep in mind that there is a risk here, sometimes deleting things outside the camera view can introduce unwanted, sudden lighting or reflection changes on the objects. (Imagine the buildings on the left getting deleted suddenly and light rays that come from the left start to affect the objects in a different way.) So if you do that definitely keep an eye on that possibility. To fix it either extend the boundaries of the camera frustum or add/keep some proxy geos where big chunks are deleted.
About the render settings, there is nothing new or different than before. However, the only major thing I noticed this time is increasing Russian Roulette inside the Karma ROP. Especially the regions where foam and the wave met or the shadowy part where both buildings on screen left meet were very grainy and had fireflies when Russian Roulette was set to 1. Setting it to 2 cleared a lot of and 3 or 4 was adding more time to renders but were significantly cleaning those issues. On my first tsunami scene I wrote something similar for this value but in this scene it was way more apparent and helpful. Also the added time was nothing compared to how much it cleaned the graininess where on my previous tsunami work it was adding a lot more time with much less visible cleaning.
Lastly on the previous scene’s blog post I wrote that the render starts nearly immediately with Karma XPU. This time this wasn’t the case because the poly counts were much higher and it took a bit for Karma to load them. However, comparing that initialization time with the time it took for Blender Octane to show the first pixels showed Karma to be again significantly faster. And I am not sure because I haven’t tested it but apparently if you work on the Solaris context that initial loading won’t be so long. I will be testing this on another scene soon and will write the details as a new blog post.
Final Thoughts
I got impressed with Karma XPU once again. Speed wise it is very successful and for a Beta software performs pretty amazing. With the holdouts added it gives a lot more flexibility in compositing. Staying inside Houdini for renders and not having to export everything to another software for rendering is very convenient. After this render, Karma XPU became my go to renderer even in the Beta stage. Can’t wait to see what SideFX will give us once it is ready and fully released.
And here is the final result:
