As of last week, I’ve decided it’s time to finish up with my full time Blender development contract and move on to new things. It’s been 8 months now since I started with this, pretty close to the first 9 month target/budget, so it’s not too unexpected. I’m happy to have done my part in bringing Blender 2.5 closer up to production ready status over the last several months, and this decision doesn’t necessarily mean I’ll cease contributing, but it will be the end of it for now in this professional capacity. It’s been an interesting time, I’ve had some new experiences, but it’s not what I really want to be doing with myself in the long term – I’m itching to get back into more regular creative production work!

I think what I’ve learned from this is that while some people are happy programming for programming’s sake, It’s really most interesting for me when it’s directly in service of some artistic goal or creative problem to solve. While I’ve done the work to the best of my professional ability, the last several months of report management and bug fixing (I estimate about ~350 fixed since the start) has been a bit motivationally draining, so it’s a good time for change.

So, what next? I’m looking forward to getting stuck into more freelance work again
(hire me! ;) as well as developing some new skills in other areas and working on some personal projects. Hopefully more interesting times ahead!

For a little while now I’ve been working in my own time on a renderman connection for Blender 2.5. The new render API, while not fully complete and stable, makes it much easier to connect Blender’s scene data to external renderers, via python.

I’m aware that other people are interested in this topic too, but so far I’ve been doing this for my own use – to get more familiar and experienced with renderman in practice (by diving deeper in head first), and to develop something I’d like to use myself as a lighting/shading artist. I’m also concentrating on the 3Delight renderer at the moment, since it interests me most and provides a free single license.

It’s still quite a work-in-progress, and by no means provides exhaustive support at this point. I’m tackling this from a pragmatic angle, with the priority of implementing things I want to use myself first and making that easy to use rather than trying to supporting the entire rispec from the start. I’ll probably release the code very soon, but I would like to clean it up a little bit first.

Here’s a test I rendered out last night, with a model by my mate Tristan Lock:

Anyway, currently it supports: polygon mesh, subdivision surfaces, uv coordinates, depth of field blur, motion blur, surface/displacement/lightsource shaders with parameters available in blender material properties, simple conversion from blender’s lamps to renderman lightsources, shadow maps, raytraced shadows, built-in indirect lighting and environment lighting using 3Delight’s ‘indirectlight’ and ‘envlight2′ shaders, and shader editing and compilation from the blender text editor.

It’s been a little while since I merged the volume rendering work into Blender 2.5 but I’ve been steadily poking away at it since. Today I committed some lighting features, support for volumes receiving external shadows (raytraced, and quick but more limited shadow mapped) and a new shadow only mode that’s a bit faster than self-shading, good for less dense volumes like fog or wispy smoke:

I’ve also had some behind-the-scenes help in the form of code review and some new features from Alfredo de Greef, which has been great, and last week I bit the bullet and redid part of the shading code. It was previously using a custom method left over from initial experiments that wasn’t entirely physically correct – the shader didn’t conserve energy. In the real world, if more light is scattered out of the volume, towards your eye, there will be less left to keep penetrating through the remainder of the volume, but the previous method didn’t account for this.

In reality this also applies on a wavelength-dependent basis too, if the media is such that the red light is scattered out of the volume (from an initial white light shining on it), all that’s left to continue through the rest of the volume is the inverse of that (roughly cyan). I got to work changing this in the code, but after a long time testing realised it was getting very difficult to control. Most of the time, if you’re making a coloured volume (like the excellent coloured smoke in the Cloudy trailer), you want to be able to just set a colour and be done with it. Doing it by tweaking wavelength dependent absorption and scattering was getting to be a real pain, so I ended up chopping and changing things around.

Now there’s a single physically based ‘scattering’ parameter, controlling the amount of light that’s scattered out of the volume (leaving less to continue through), as well as a ‘transmission colour’ that defines the result colour in the rest of the volume, after out-scattering and absorption. With these settings, by default, the shader works physically correctly. For ease of control though, I also added a ‘reflection’ colour and strength which basically acts as an RGB gain, tinting the out-scattered light. It’s more of a non-physical tweak, but it does make life a fair bit easier. I’ve documented these settings with example renders on the blender wiki.

I’m pretty happy with how it’s working now: physically correct by default, but with the option of changing it for artistic control, and philosophically I think that’s how it should be. One of the many things I dislike about Blender’s current shading system is that it generally starts out incorrect, and you have to really understand what’s going on, and work quite hard in order to make it do the right thing (energy conservation, obeying physical laws, etc.). Not only is this a real pain since you have to go through the same chores every time just to get a decent looking material, but for many people who don’t have a good understanding of how rendering/shading works (or should work!) they’re left with sub-par results since they don’t know what magic buttons to press. You should have to work to break it, not to get just a base level of correctness. In further work I do on shading/rendering, that’s going to be a large motivation, to get things working physically plausible by default, but with the ability to break the rules if the situation requires it.

Here’s a quick screencast showing how to use the voxel data texture to load and render image slices as 3D volumes. It may be a little unclear in this small window, but you can click through to Vimeo to see the HD/fullscreen version. This is using the sim_physics branch in blender SVN, you may be able to find builds for your system on graphicall.org.

Today I committed some new additions to the blender sim_physics branch, making it easier to load up different types of voxel data sets for volume rendering within Blender. The most significant addition is a new ‘Image Sequence’ file format choice in the voxel data texture, which makes it easy to load up image slice sequences as the Z axis of a 3d voxel grid.

There are some other new features and optimisations mentioned in the commit log too. I really hope this helps people involved in medical visualisation/research, if only by providing them a free method for making animations with case data. If you are in the field, I’d love to hear from you.

Some test renders:

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

The work I was doing on glossy reflections/refractions was finished a while ago, the end product being much more robust and advanced than in that last post, and also including all sorts of extra nice things like using QMC sampling for ray shadows and ambient occlusion. These changes are now officially in Blender’s SVN repository and will be in the next major release, however I’ve already been making use of it extensively. This not overly interesting illustration I did for a magazine cover made it into the Australian Creative magazine gallery and uses a lot of anisotropic blurry reflection.

I made some nice docs online here: Glossy Reflection/Refraction / Raytraced Soft Shadows / QMC Sampling. Thanks again to Brecht van Lommel and Alfredo de Greef who both gave me some great guidance and help along the way, and I look forward to doing more work in this area in the future. A few other changes I’ve made recently have been extra lamp falloff options, including custom curve, enabling different curve tilt interpolation types, and I’ve also committed a bunch of ex-tuhopuu UI related work to the ‘imagebrowser’ branch, to work on separately in there until I can find the time to finish it up and bring to the main Blender SVN trunk.

But life goes on…

So with no ready made options, I tried an idea – I read up on MaxScript and made a Python script for Blender that takes the curve data and and uses it to generate a MaxScript, that when run inside 3DS Max will generate the same curve using the MaxScript API. There are a few advantages to this, there’s a very fine level of control and you can easily export every feature that’s supported by both Blender and Max, without worrying if an intermediary format supports those specific features too. However there are drawbacks – it’s a pain to use since you have to open up and run a MaxScript each time, rather than just importing a file. I’d rather support an existing standard format, so it’s more widely useful for other people than just me.

I’d been using the ColladaMax plugin (based on the open source FCollada library) previously to transfer meshes and cameras between Max and Blender, and after doing some more research it turns out that the COLLADA format supports 3D béziers, as does ColladaMax. Neither of Blender’s two COLLADA exporters do though, and they seemed too complex for me to add curve support to them, so I grabbed the spec and threw together my own simple exporter for curves only. One very annoying issue is that the ColladaMax plugin (and I presume the FCollada library) expects the data formatted in a way that’s incompatible with the spec. Since my goal here is practicality rather than technical purity, this means that rather than it being a generalised COLLADA format exporter, I have to tailor it to FCollada’s non-standard idiosyncracies. I hope the library is updated to conform to the standard in the future, but going by the devs’ response on their forum it doesn’t look like that will happen any time soon. On the positive side, there’s a good chance that my exported COLLADA curves will work with the ColladaMaya plugin as well, opening up another application to work with. If anyone can test this and confirm or deny, that would be very interesting information.

Anyway, the script is available here: export_curves_fcollada-1.1.py. It’s my first exporter and I didn’t use any fancy XML libraries, so it may be rough (although it gets the job done fine). If any Python gurus have ideas on how to improve it, I’d appreciate some hints! I hope this post might help anyone in the same situation as me, in the ever-perilous business of interoperability.

It’s basically using a modifier at the bottom of the stack to create geometry, which you could then just apply to edit the mesh directly, though that’s not always necessary. This is a bit similar to how Max and Cinema 4D work. When you add an object, you can still manipulate dimensions, resolution, other parameters as a whole. Then if you want to edit it manually, you convert it to an editable mesh with a click.

Above are some screencasts of what I did in Blender. Obviously it’s simple and rough, and if developed further, one could do things to clean it up like disable those generator modifiers from appearing in the menu, change the add object code to apply the generator modifiers automatically, prevent them from being moved up and down the stack, and perhaps add some code that upon pressing Tab, would give you the option to apply that modifier and just convert it to a mesh so you can edit it. In any case, this could serve as some kind of inspiration for something nice in the future…

As far as the release itself goes, here’s another little list of my favourite contributions this time around.

• Tapering 3D curves with radius per CV, with shrink/fatten tool
• Tablet pressure and tilt support in Mac OS X, and tilt support in Windows and X11
• New UV test grid generated image, designed to be easier on the eye and to show distortion clearly
• Proportional edit mode random falloff option
• Object level view/select/render restrictions in the outliner
• Upgraded the User Prefs OpenGL lights section to use nice modern vector and colour picker UI controls
• Dynamic icon fie loading and themability
• Compositor Displace node, Combine RGBA node

There’s one bit of disappointing news though. The next release was planned for a while to be a UI-centred Blender 2.5 release, for which Ton would do the huge and time consuming necessary internal upgrades that would allow features that I’ve been working on such as drag and drop in the outliner, a customisable toolbar, and radial menus to be implemented.

It seems now that once again, it has been decided for this work to be postponed in favour of a version 2.44 with smaller projects, meaning that it’s going to be at least May or June before any of these UI projects can be integrated. It’s a lot of difficult work for Ton to do, and it’s up to him to decide what he wants to work on, but it’s also frustrating and demotivating for me, because I’ve been waiting so long, being prevented from working on these sorts of improvements release after release. I offer my apologies to any of you who are waiting too.