I’ve made a patch to allow specifying a sensor size, along with a handful of common presets – easy to add some more. This first version isn’t 100% correct in that it doesn’t modify the FOV due to focus (in reality, the extension of the lens elements due to focusing slightly alters the FOV), but this can be added pretty easily as an option later. It’s also deriving the apparent FOV purely based on the horizontal aperture width, options for vertical/diagonal may be possible to add later, but would need to check how the renderer works with varying frame resolution aspect ratios.

I thought it would be fun to do some real-world tests, so I quickly set up a very rough set in my backyard to see if a virtual set in Blender would match up. The setup and measurements were very very dodgy and I didn’t expect it to match perfectly. I shot with two cameras – first was Kat’s 5D Mk II with a 12-24mm on 24mm and a 24-70mm on 70mm. To compound the un-scientific sketchiness of the test even further I tried again with my 6×6 Mamiya C330f TLR with 65mm and 80mm lenses, using a compact digital camera shooting the ground glass focusing screen (yes, too cheap to spend film on this). Given all this, I was pretty surprised to see that with a bit of tweaking it looks like it’s doing the right thing.

Anyway, the patch is up on the blender patch tracker, would be good to get some testing first before trying to commit, especially since I’m not sure how it should interact with the game engine either.

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!

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.

As some of you may have seen, yesterday during the 2009 Blender conference keynote, Ton Roosendaal announced the addition of another full time blender developer: me! Thanks to the support of a very generous anonymous sponsor, I should be able to survive working from home on Blender development for the next few months.

This came about over the last week or two, so it’s still new for me as well. As far as I’m currently aware, the brief for this project is ‘Get Blender 2.5 ready’. So rather than some of the other things I’ve been working on in my own time such as volume rendering, at least in the near term, this project will involve a fair bit of ui work, fixes, tweaks, cleaning up, attacking the 2.5 todo list, documentation – attacking the main things needed to get the 2.5/2.6 work polished to a professional level.

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.

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:

Made a simple little script last night for testing voxel data loading – it creates vertices of a mesh based on voxel data, if the voxel’s value is above a threshold. The file’s here if you’re interested. The datasets this works with are available here.

I’d heard before about Radiohead’s House of Cards video, made entirely from 3D laser scan data. Yesterday I found out that some of the point cloud data files were made available to download from Google under a creative commons license.

Luckily, I’ve been able to work full time for a while on the volume rendering code, as part of budgeted R&D time at work. Since Monday I’ve made a lot of progress, and have been committing code to the ‘sim_physics‘ SVN branch, maintained by Daniel Genrich.

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

Some of you may be aware of the great work done so far by Raúl Fernández Hernández (“farsthary“) concerning volume rendering in Blender. For those not in the know, rendering volumes of participating media as opposed to solid surfaces, has many uses such as realistically rendering smoke, fire, clouds or fog, or even with more complicated techniques, rendering volume density data such as MRI scans for medical visualisation.

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!

I recently posted on blenderartists.org in response to some questions and misunderstanding about gamma correction and ‘linear workflow’ in 3D rendering.

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

Since there’s no analogue built in to Blender at the present, during our last animation project, I knocked together a very simple PyConstraint: Noise. It’s made to fulfill similar tasks as the Noise controller in 3DS Max, giving random (yet deterministic) animation to an object. We used it for things like like applying it to a lamp for randomised shadow flicker from a candle flame, or on a large scale, subtle swaying movements of a ship on the ocean.

Things have been busy lately. There have been plenty of ‘real life’ things to take my attention from this site – some of them fun, like moving into a new place with Kat, some of them not very fun at all like having the place broken into and robbed a month later.

Work’s been spread on thick. Last weekend, we reached the finish line of a project we’ve had on over the last 2-3 months, a 2 1/2 minute short film that we’ve been creating for a production studio in the US. The work has been very fun and artistically interesting, the clients have been great, and we’ve all learnt a lot in the process. The only down side for me personally has been the amount of overtime I’ve put in to try to keep it looking nice, after shouldering most of the responsibility for the texturing, shading, lighting, comping, some of which has been kinda complicated. I really can’t complain at all though, it’s definitely my favourite kind of work. The public release should be quite soon, so keep an eye out!

Had some r&d time lately, at work and at home. Here’s what I’m up to:

I’d like to get the node system hooked up to raytracing, allowing one to do advanced shading techniques but without being forced to do it with the dodgy ‘mixing materials’ method. As a starting point, I’ve made a reflection node – the bonus is that the node system makes it a lot easier to texturise inputs. Thanks to some hints from Alfredo de Greef, I’ve added an additional input to rotate the anisotropic direction (with black being 0° and white being 360°). This can give some nice effects:

• Radial blend texture (node setup)
• Spun-brushed steel (node setup same as above but using this texture instead)
• Carbon fibre (node setup)
• Weird sphere (using a clouds texture for aniso rotation)

I’d also like to include a refract node, an AO node, and/or also a general purpose raytrace node that takes a •vector and •solid angle as input, and gives as output: •whether it intersected something (average of samples in solid angle) •distance to intersection, •shaded colour of intersected face, etc.

Three months since the last post here, I think that deserves either an award or a slap on the wrist. Things have been busy, and I’m sorry to say I’ve been much more inclined to spend my free time in other ways than writing here.

Work has been through alternating bursts of slow r&d time and busy projects, the latter being where I find myself at the moment. We’re using Blender more and more, currently we’re doing an immensely complex animation of around 12,000 frames, without much time to do it in. It’s the first project of this scale that we’ve done in Blender as a team, and although it’s a lot to manage and keep track of, it’s been pretty good.

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…

Previously, I’ve grumpily complained that there aren’t enough people interested in working on Blender’s internal renderer, and so it was only fair that I put my money where my mouth is. I mentioned I’d been doing some coding recently, and this is one of the products of that time: blurry/glossy reflections and refractions in Blender’s internal raytracer. It works similarly in concept to yafray’s ‘conetrace’, sampling a cone of rays around the current pixel to get an averaged, blurry result. The sampling is using a quasi-monte carlo Halton sequence, which Brecht van Lommel previously converted into C code in an old experiment of his, and which he gave me a lot of valuable help with – thanks a bunch, Brecht!

Over the last few weeks at the studio I’ve been working in Blender alongside 3DS Max and I’ve needed to export 3D bézier curve (spline) data between the two apps. There were a few occasions, such as exporting a logo that I’d cleaned up in Blender from a 2D SVG, and also some 3D animation paths that I’d been working on. While there are a lot of options for exporting other data such as meshes, there’s very little around to facilitate transferring 3D curves between packages.

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.

Unfortunately, ever since their inception, modifiers in Blender haven’t let you animate their settings. This is a real pain, and a motivational hurdle against people making lots of nice new modifiers like ‘bend’, ‘twist’, ‘taper’, etc. I really hope this gets addressed soon, but until then, here’s an ugly workaround which will let you animate modifiers using the bPython API.

A while ago, I did some experiments that I didn’t really show anyone, a proof of concept for generating non-destructive primitive objects through the modifier stack. One of the things I liked in recent dabblings with 3DS Max is having flexibility and realtime feedback when editing primitive objects, and I thought I’d see if I could make it work in some way in Blender.

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…