NOTEBOOK

On my current project, we have a sequence which requires a ton of lava. The talented Kenzie von Pingel spent some time building a procedural animated texture in RenderMan to avoid the need to simulate an entire roomful of relatively static lava.

Unfortunately, we also need fluid-based simulations for a set of 'lavafalls' that start spewing out into the room halfway into the sequence. Getting the texture to play nice with a proper simulation has been a bit of a head-scratcher.

Current working solution: manifold advection.

By sampling the gradient of the fluid SDF, we can get vectors that point in the direction that the lava texture *should have* been moving. If we deform the texture like so, the movement is much more convincing than the alternative.

This version was before I culled out droplets, which we can safely ignore as far as manifold advection goes.

We can then transfer color from the sim to the grid where they're close and normals from the grid to the fluid, like they do in some video game environments.

Every December, Matt Estela's wonderful cgwiki community holds a set of VEX challenges. This year, instead of doing a challenge a day, the community opted to do a small number of trickier challenges. Here are some of my results from this year:

The riser uses a sop solver, some fun noises, and feeds the color attribute into the shader. Fun little exercise.

This one has no sim. All of the bricks are animated in a single primitive wrangle. I construct curves that blend between the original and final positions and blend quaternion rotations to get them to flip nicely into their final orientations.

I've been working on a high fantasy short film recently, and a lot of the design work included various kinds of Celtic knots in the environment and costumes. I made a tool to proceduralize knots, based on this paper:
http://www.matt-kaplan.com/npr/knots/Knot_elec.pdf

I'm aware that EverythingCG did something similar, but I'm both too cheap and too stubborn to look at the setup, though their summary of the algorithm here is pretty solid.

It takes in a flat mesh, and the edges of the mesh become pairs of arcs on the resulting knot:

My implementation is a Houdini Digital Asset that's about 99% VEX. I exposed a number of parameters to the user to control the shape. The default output is a bunch of curve primitives with normals, but the tool includes an option to sweep the curve with ribbons, tubes or a custom cross-section. The demo above shows some of the variations you can get with just the exposed parameters on the ribbon output.

At some point I plan to drive a fairy dust-type effect with the curves from this tool. In the meantime though, we needed the ability to project the knots into textures for painting stone engraving, leather styling, and other fine details, so I built a second tool to take the flat geometry and export depth and normal map textures from the curves.

In a lava room sequence, the lighting team asked me for large steam volumes to get atmospheric depth cues in the cavern. The sequence is 46 shots long. As I saw it, I had a few options:

1. Make the FX team kick out a different steam simulation for every shot.
   This option runs the risk of a different fog appearance in each shot.

2. Use one static volume for the steam.
   While this was somewhat viable, if we were just going to use a single uniform volume, I didn't see much of an advantage over just using a depth pass in comp to make the appearance of steam in 2D.

3. Create one long steam simulation to use throughout the entire sequence.
   The disadvantage of this is that the simulation would have the same moment in each shot, and the room is large enough that the VDB could get quite heavy, which would be unnecessary for closeups of the characters.

Director: "Can we make this more cinematic?"

Animated films don't need lens flares, necessarily, but my capstone film's style seems to be "cinematic." 2.35 aspect ratio, high-contrast lighting, high-detail, hyper-realist textures, etc. Since I'll be busy keeping our FX department floating most of next semester, I'm spending some time now automating as much compositing as I can so that our two lighters have to do as little troubleshooting as possible.

One part of that preparation has been auto-comp templates. Maybe I'll write that up here another day.

The other is a node to add lens characteristics. I'd like to strike a nice balance between art-directability, physical plausibility, and consistency. So, I'm rolling a poor man's version of Alex Fry's setup for Batman 2.

Lens flaws we chose to include: Procedural flares (convolution-based), glow, grain, distortion, vignetting, halation, chromatic abberation, etc. Chromatic abberation is often overdone by my fellow students, so I was careful to limit the artists' ability to make a shot look like a kaleidoscope. Also, halation should really be a thing of the past with the better film technology we have today, but many films are adding it back, and a little warmth around highlights isn't the worst thing.

Most of the components come from Nukepedia, though I went in and made some changes to a few of them for cleaner results and more optimized performance.

Nice and simple.

.hipnc file

Someone recently asked this question in a discord server--

The eventual solution ended up being much more finnicky than I had expected. The way I went about it was to create a sort of ST lookup that could take certain horizontal stretches of the input and convert them into polar coordinates--the x coordinate of a pixel of the original image would become the angle of the point for a semicircle on the right.

Like so.

The code itself involves some tricky remainder calculations. If we want five squiggles running across our image, then we need to split the left images into five horizontal strips to be bunched up. We can then chop each strip up into segments. Some segments will bend left, some will bend right, and some will stay straight.