Recent jobs – quick lighting/setup on a couple more Bridgestone Gecko TVCs in blender 2.5:

Last night I finished my first artwork project in Blender 2.5 start to finish, though of course it’s a lot smaller than most other things I’ve done lately :) Went surprisingly smoothly in this case, only discovered one new bug, which I’ve subsequently fixed. Slowly but steadily, we get more and more ready for production!

The result itself was a christmas card illustration for Kat to send to her clients and contacts.

Just came across a ‘quick take’ article about our Bridgestone Gecko work on fxguide: Bridgestone by RedCartel.

We recently finished a cg sequence for ‘Klaas Vaak’, a European children’s TV show. The show’s about the Sand Man (Klaas Vaak), who tells stories and illustrates them with sand drawings, and it looks really fun. We did a 30 second intro sequence and 10 second end credits sequence. The character’s owned by a large theme park, Efteling, and as I understand, some of this stuff will be constructed in real life at the theme park – very cool.

As usual, I did lighting/shading/comp, and some modelling and fur work too. Jeremy Davidson did most of everything else – animation, rigging, particles, etc. In general it went pretty smoothly, although some of the bigger shots full of trees and houses caused some headaches with the amount of geometry. Especially since at the start of the project we were using 32bit systems to render, though we ended up moving to 64bit midway. Only the first few visible ‘layers’ of trees are geometry (well even still, geometry with branch alpha mapped image textures), but after that, much of them are either image planes with baked colour/normal/alpha maps. All in all though, I’m pretty happy with how it turned out.

I’ve updated my demo reel with some lighting/shading/comp work from the past couple of years.

Please have a look below, or on Vimeo. Details on the reel page. Thanks!

Some recent Bridgestone Gecko TVCs @ ProMotion. I did shading/lighting/comp.

Last week I went to see a few sessions of the 2009 Sydney festival called films afloat, a free outdoor film screening on a massive screen floating out in the middle of Darling Harbour. Before the main feature (each night a different movie, with a soundtrack played by an improvising live band!) they showed the finalists of the animation competition, which our short ‘Lighthouse’ was included in. We ended up coming second in the competition, which was nice, but even better just to have it shown outdoors in front of a few thousand people in such a great atmosphere.

At work we also published a project we finished late last year, which was our first production use of the volume rendering tools I’ve been working on. It’s just a couple of shots, produced for an internal corporate video involving a hallucination sequence where a worker gets ripped out of his cubicle by a tornado. It’s a bit silly, and may not be the greatest vfx shot known to man, but it was fun to do, and good to give the rendering tools a good hammering in a practical context. There’s a bit more info about the process in this blenderartists thread.

It’s getting to the end of the year and things are getting busy. There’s been plenty on at work – quite a few projects have been running concurrent for a while, including a new Bridgestone gecko spot that’s out now, and the still in-progress project I’ve been working on the volume rendering for.

We’ve been getting around a bit too, four of us headed down to Melbourne in October to attend the first ‘Melbourne Blender Society‘ meeting. We gave an informal presentation about some of our work, much of it involving character setups, and then headed out for some ‘beer r&d’, meeting some fun and interesting people (Hi Glenn, this only took a month ;).

Jez, James and I also gave a presentation at the Digital Media Festival in Sydney , on the topic of ‘an open source pipeline’, talking about our use of Blender in production. Some of the parts that interested the audience of mostly 3d/vfx/design people most were existing features like the library linking system, but also the ability for us to do custom development, such as contracting the ocean sim tools for the Lighthouse project. I also showed off some work on the volume rendering too ;)

The volume rendering tools are at the point now where it’s going to give acceptable results given the timeframe. Although it’s still lacking a bit in some areas right now that aren’t a priority for this job, for my purpose it’s going pretty well. Raul has now picked up this code to work with too, and I’m looking forward to seeing his implementation of voxel data sets. A couple of the improvements I’ve made since last time posting include:

• Particle rendering
  There’s now a new 3d texture called ‘point density’ that retrieves density and colour information from point clouds (either particle systems or object vertices). It uses a BVH tree to store the points, and looks up what points are within a given radius of the shaded point, with various falloffs. It also has a few methods for simple turbulence, adding directed noise to give the impression of more detail. It’s also possible to use this texture on solid surfaces too.
• Light Cache
  In order to speed up rendering of self-shaded volumes, there’s a new option to precalculate the shading at the start of the render into a voxel grid, which gets interpolated later to generate lighting information, rather than shading the lamps directly. You could make the analogy to raytraced occlusion vs approximate occlusion in Blender – it often gives around a 3x speed up with similar quality.
• A few other small things such as internal and external shadows, anisotropic scattering with various phase functions, integration with the sun/sky system, and various fixes.

Kajimba‘s also rolling along nicely. We’ve released several more animation tests with audio (and plenty more sill in the pipe), the voices for the first episode have been recorded, and the animator dudes have started working on lipsync tests to begin some animation on ep 1 soon.

And on it goes…

Some of the changes so far include:

• Fixed the shading bug I mentioned earlier, due to a limitation in the raytrace engine (before, after). Now shading works quite nicely.
• Added colour emission – as well as the overall ‘Emit:’ slider to control
  overall emission strength, there’s also a colour swatch for the volume to emit
  that colour. This can also be textured, using ‘Emit Col’ in the map to panel.
• Cleaned up and clarified volume texture mapping, fixing the offsets and scaling, and adding ‘Local’ (similar to Orco) mapping, alongside Object and Global coordinates
• Added colour absorption – rather than a single absorption value to control how much light is absorbed as it travels through a volume, there’s now an additional absorption colour. This is used to absorb different R/G/B components of light at different amounts. For example, if a white light shines on a volume which absorbs green and blue
  components, the volume will appear red. This colour can also be textured.
• Refactored the previous volume texturing code to be more efficient
• Worked on integrating volume materials into the rest of the renderer. Now other objects (and sky) correctly render if they’re partially inside or behind a volume. Previously all other objects were ignored, and volumes just rendered on black. The colour of surfaces inside or behind the volume gets correctly attenuated by the density of the volume in between – i.e. thicker volumes will block the light coming from behind.
• Enabled rendering with the camera inside the volume.

Correct shading and absorption	Shading with two lamps	Shading within clouds density texture
Textured (with colour ramp) emission colour	Example of various absorption colours	Textured absorption colour
Objects and sky inside and behind volume	Shaded concave volume	Camera passing through a volume

In some spare time, I had a go at taking apart his patch. Unfortunately, it became clear that it wasn’t suitable for immediate inclusion. It was Raúl’s first time coding in Blender (or perhaps in 3D) and due to this, wasn’t aware of some of the techniques available to make his life easier, or of how to integrate the code as cleanly as it could or should be. On top of this, working alone without being able to easily communicate with other developers, he’d been working hard on adding more and more features and options on top of a structure which I think could be done differently and a lot cleaner at a fundamental level. This led to some quite complicated code, and a tricky UI for artists to interact with.

I proposed to Raúl that I start again from scratch, simpler and more cleanly integrated and then merge in what I could later down the track, step by step, to which he was very enthusiastic. He excitedly agreed with my invitation to work closely on integrating things like the simulation work he’s been doing, once a new structure is well defined. Recently in a few days off from work I sat down and started fresh, based on the approach in Physically Based Rendering.

Spot light in constant density volume

3 point lights in constant density volume

Textured spot light in constant density volume

So far I’ve got it working reasonably well with about 90% new code. Unlike before, it’s following a physically based approach, with a region of constant or variable density, calculating light emission, absorption, and single scattering from lamps. My aim is to get a simple, easier to use version ready, optimised for practical rendering tasks like smoke, fire or clouds. Once this is working perfectly, integrated cleanly and completely, and working in Blender SVN, further down the track we can think about adding some of the less common capabilities like isosurfaces or volume data sets.

Cloud texture controlling density, lighting from volume emission only

Cloud texture controlling density, 3 lights with single scattering

Spherical blend textures controlling density, directional light with single scattering

There’s still a lot to do – there’s one remaining bug with single scattering I must try and track down, and then there’s a lot of integration work to do, calculating alpha, rendering volumes in front of solid surfaces etc. Before too long I’ll commit this to the newly created ‘sim/physics’ SVN branch and work on it in there. I don’t know how long it will be before Raúl is able to start working on this again too, since he’s under some horrible circumstances after hurricane Gustav ravaged Cuba. At least in the near term, I’ll be able to continue poking away at this in SVN.

Some things on my want-to-do list include:

• Plenty of optimisations
• Adaptive sampling – step size and/or early termination
• Alternative anisotropic phase (scattering) functions such as Mie or Henyey-Greenstein
• Wavelength (R/G/B) dependent absorption, so light gets tinted as it travels through a medium
• An optimised bounding box or sphere ‘volume region’ primitive, which could be much faster than raytracing meshes as is done now
• Multiple layers deep ray intersections, to enable concave meshes or volume meshes in front of volume meshes
• Rendering Blender’s particle systems, either by creating spherical ‘puffs’ at each particle as Afterburner or PyroCluster do, or perhaps by estimating particle density with a kd-tree or such

I hope to be able to provide some more updates on this before too long!

Much of the value of a linear workflow comes with rendering colour textures. But as the name suggests, it’s a workflow, that has to be kept in mind throughout the entire process.

The issue is that when you make a texture, either painting it in Photoshop to look good on your screen, or as a JPEG from a camera, that image is made to look good under gamma corrected conditions, usually gamma 2.2. So as you paint that texture, you’re looking at it on a monitor that’s already gamma 2.2, which is not linear. This is all well and good, displays are already gamma corrected to better fit the range of human vision.

The problem starts though, when you use those colour maps as textures in a renderer. When you’re doing lighting calculations in a renderer, those take place in a linear colour space. i.e – add 2x as much light, and it gets 2x brighter. The problem is that your colour textures aren’t like that if they’re at gamma 2.2. What’s double in numerical pixel values in gamma 2.2 is not necessarily twice brighter perceptually. So this breaks the idea of taking brightness information from a colour texture and using it in lighting/shading calculations, especially if you’re doing multiple light bounces off textured surfaces.

So what a linear workflow means, is that you take those colour textures, and convert them back to linear space before rendering, then you gamma correct/tonemap the final result back to gamma space (for viewing on a monitor). Now the lighting calculations work accurately, however it does change things – because the textures get darkened in the midtones the image can look darker, so you need to change the lighting setup, etc. etc. Hence, workflow – it’s something you need to have on all throughout the process, not just applying gamma at the end.

I wrote some code a little while ago that did it all automatically in the shading process, applying inverse gamma correction for colour textures before rendering, then corrected back to gamma 2.2 afterwards. After adjusting lights from old scenes to have the same appearance, it gave some nice results. It seemed to bring out a lot more detail in the textures, which got washed out before (left is normal, right is with linear workflow). It’s not finished though, it also needs to adjust the lights in the preview render, and inverse gamma correct colour swatches too so the flat colours you pick in the UI are also linear.

Further references:

• http://www.gijsdezwart.nl/tutorials.php
• http://www.xsi-blog.com/archives/133