iAurora

After coming back from another Siggraph I have realized that I've missed updating this blog. I haven't touched Aurora much the least year, so it didn't occur to me to post anything, but I've been tinkering with other cool stuff in the meantime, so watch this space for non-Aurora updates in the near future.

In an effort to make Aurora more interesting than just adding features to the existing engine I've decided to move it in a slightly different direction - to iOS. There are a million different path tracers out there and they're pretty much all doing a better job than Aurora anyway, but I haven't seen a decent lighting/material editing sandbox on the ipad yet. There are a couple of fractal renderers but I'd love to see one where you can bring in object files from apps like treesketch, one of the scuplting apps or simply a desktop modeler, and tweak materials, add textures and make it look nice.

Anyway, for now it's just an experiment for me to tinker with and see if I can make something like that happen, and it remains to be seen whether I can cook up something useful before getting bored and moving on to other things again.

After a couple of nights of coding, here's a bare bones version running on an early generation iPad:

The entire engine is still c++, with objective c being used only for the UI (which right now is as simple as it can possibly be). I've stripped out the tbb threading and embree bvh, so it's increadibly, unbelievably and unbearably slow.

-Espen

Normal maps

I'm still on the road, but had some time to tinker with Aurora while traveling to and from Siggraph. I've added some more stats tracking to the back end, and implemented normal mapping as the final feature needed to wrap up the kitchen scene.

Here's a quick test. For normal map extraction I used CrazyBump.

-Espen

Kitchen scene update

I'll be traveling for the next month or two, so since there will probably be a lack of updates for a while I figured I'd share my progress on the kitchen scene. There's a little bit of comp work on this one - mostly just some lense glow and a simple film-esque LUT. The texturing is all bombing for now, and only the metals have any meaningful lookdev. Left to do is getting textures on the remaining materials and then a round of refinement as it's a bit all over the place right now.

-Espen

Triplanar Texturing

I love texture bombing. Anything that lets me blast a decent manifold onto a huge set of geometry usually means saving hours of painful unwrapping and days of painting on geometry. We used this stuff all the time at Weta, and it always amazed me what you can get away with. Combine it with a shader graph of some carefully painted details where they're important, and you got yourself a decent environment lookdev pipeline.

Starting off with an easy one I added a Triplanar shader to Aurora. It's the most naive way of bombing a manifold onto arbitrary geometry: All it does is put a mix of three perpendicular ortographic projections based on the surface normal and some parameter that describes how soft/hard you want the transition to be.

Bias

Some things are not worth waiting for. Particularly if you need to wait a really, really long time. So in the spirit of being practical I've added two careful (and optional) cheats into Aurora to make the kitchen scene perform better. The first one is a "caustic blur", essentially taking all C-[...]-D-S-[...]-L and similarly C-[...]-D-T-[...]-L paths and increasing the roughness at the specular vertices after a diffuse. The second one is a "firefly killer" to catch those few absurdly bright paths that pop up every once in a while. At the moment it's very naive in that it's looking at absolute brightness, but the plan is to update it to look for values N standard deviations outside of the mean pixel value at some point. This takes some more fiddling/trial and error though, so I'll stick with the simple version for now.

Here's what the caustic blur looks like for a mirror-like Cook/Torrance specular next to a diffuse plane, after 1 minute of rendering:
Blur 0 (no cheating):

Blur 0.1:

Blur 0.2:

While doing some more lighting work to the kitchen scene I noticed the performance goes down very fast as I add more light sources, so I improved the logic for picking which light to sample at each path vertex from being random to only considering lights within the domain of the bxdf for the given point and normal. I'm sure there are way better metrics out there but for now it improves the variance a lot, giving me slightly slower render times per progression but a lot less noise per progression with fewer paths wasted.

Here's the kitchen scene before/after the caustic, firefly and light sampling updates:
Rendered at 1920x800.
This one was stopped after 8+ hours with somewhere between 10k and 12k samples per pixel:

While this took 3h21min at 4k samples per pixel:

And here's what it looks like after the first 16 samples, at 51 seconds:

 

-Espen

Brainmelt

I managed to sort out properly interpolated prim vars for Loop subdivison surfaces. My brain hurts now.

Edit: Added the metal material to the python layer so I can hook up textures etc in Maya. Not my finest piece of lookdev ever but I had a lot of fun, with the speed of interactive renders being pretty decent now.

-Espen

Shiny things 2

A few updates on the shading side this week. I've re implemented the Kelemen material (fixing a couple of embarrassing bugs along the way), and also added a basic metal material. It's using an old trick of doing per-rgb-component fresnel as a cheap approximation of a wavelength varying specular response for now. I'll go back in there and update to a better implementation later, but right now I want to move forward so I can get cracking on doing some texture work on this kitchen scene.

I still need to get UVs sorted for sub-d surfaces, and then look at using OpenImageIO for texture caching, as I'll be likely to run out of memory if I use my current naive way of keeping everything in memory.

Here are renders with a matte, kelemen and metal material, using the new sub-d code:

-Espen