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.

There’s a thread with instructions on blenderartists.org, and the goodies themselves here:

• Demo movie
• Demo .blend file
• The script itself

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!

As part of the project, alongside the many hours of artistic work, we’ve also done some development work. A few of the shots required an ocean environment, and since the existing methods of displacing clouds textures weren’t really adequate, we contracted Hamed Zaghaghi to develop ocean simulation tools in Blender. He’s done an excellent job, integrating a new ‘ocean’ procedural texture, which can be used not only as a displacement height map, but also with various shading modes for layers such as foam masks. We plan to get a patch out early net week.

Another sequence of shots involved an old, thick lighthouse lens. In many of the reference photos we looked at, they showed quite strong chromatic dispersion, so as a side project I started to work on raytraced dispersion rendering in Blender’s internal renderer. After getting a bit stuck mid-way, I had a look through yafray’s source code, and found some spectrum code that was just what I needed, and it integrated nicely. Thankyou yafray, and thankyou open source! I’ll try and get a patch for this together soon enough, too.

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.

At the studio we might possibly be doing a project that would involve vfx/image based lighting. It’s Christmas soon and there are plenty of shiny balls around, so I got a nice one and we’ve started making some HDRI light probes. Blender’s brute force method of doing image based lighting by evenly sampling the hemisphere in AO gives reasonable results, but it’s too slow for animation.

I’ve been looking into a technique originally devised for realtime graphics, based on the paper An Efficient Representation for Irradiance Environment Maps. It works by storing the irradiance in the map in spherical harmonics coefficients and only supports lambert diffuse shading, but it’s extremely fast, and can give quite nice results especially combined with it in an AO source, or even just humble buffer shadows. I’ve done some tests so far with Paul Debevec’s free light probes

• Beach
• Campus
• Grace Cathedral
• and the stairwell at work ;)

Rather than shoehorning it into AO, I’ve so far got a separate Image Based Lighting panel with this in it, and perhaps some other kinds of importance sampling methods later on.

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.

Blender’s linked library / group / scene / action system has been great, and much easier than they were doing previously for similar projects in Max. I’m keeping a master scene file that contains everything, however most of the models/rigs in there are coming in from linked groups in external files, that any of the others can add to and update. Not only does this keep things easy to modify and ripple through, but it allows us to distribute the workload well between all of us by segmenting the files finely. I’m afraid I can’t give much more detailed info at this moment, perhaps some time in the future.

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!

This has been quite an interesting (though sometimes frustrating) learning experience for me, diving into a new area of Blender’s source code for me, and learning about many concepts I was previously unfamiliar with. What I’ve got so far probably isn’t perfect, but I’m very happy with the progress made so far. I’ll post again soon about some of the process and things I’ve learned so far, hopefully in a way that people not used to reading technical SIGGRAPH papers will get some value from. But for now, here are some pretty pictures, and a patch! There’s also a bit of discussion in this thread on blenderartists.org, too.

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.

Wavefront OBJ is supposed to support curves as part of the spec, but functionality is extremely limited, and it’s so rarely used that I can’t find any apps or plugins that actually bother to support this area of the spec. I read somewhere that Autodesk’s flagship format FBX is supposed to include curve data, but in my tests, neither Max or Maya would export curves to FBX anyway, so it looked like they just didn’t bother support it. This makes it a no-go regardless of whether the up-and-coming FBX exporter for Blender supports it or not.

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.

Basically, you need to create a dummy object that you will animate in a simple manner just so you have an editable Ipo animation curve. From there, use a scriptlink set to onFrameChange to read that Ipo and manually set the modifier paramater you’re interested in to the curve’s value at that point in time. You can download my demo .blend file to see how this works (remember to enable script links in the scripts button tab), or check the demo video below to see an animated Decimate modifier.

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.

The issue of being able to see and tweak the effects of what you’re doing is one of the things that frustrates me most in Blender and I had a bit of a rant about it at last year’s Blender Conference. The topic came up on the bf-funboard list today, so I might as well share it here too:

I’m only about a week late, but I might as well do the customary ‘New version released!’ post, so here we go: Blender 2.43 is released! There, that’s better.

A challenge leading up to this release was getting the new website together. I’d pretty much finished the design last year, but it took a while for the admins to get the new server hardware ready, and for Bart to do the work integrating the templates with the CMS, Typo3.

The release provided as good an incentive as any to get the site ready, and thankfully this time with the new hardware, the website was pretty solid, despite it being thoroughly barraged by visitors via various news outlets around the web. There’s still a fair bit to do though, there are plenty of stale old pages in need of a refresh, and the forums and wiki design still needs to be integrated.

A couple of days ago, I was experimenting with unsharp masks in Blender’s compositor when I came across an interesting paper by Thomas Luft, Carsten Colditz, and Oliver Deussen, Image Enhancement by Unsharp Masking the Depth Buffer. The paper describes a number of image manipulations that can be done by finding areas where there are sharp discontinuities in depth, one of which is quite useful as a way to fake an ambient occlusion effect in post.

Unsharp mask is a popular way of sharpening images, which generally gives much better results and flexibility than simple convolution filters. It may not be widely known, but it’s actually a wet darkroom technique, and is very easy to recreate with some simple blurring and blending. Unsharp mask finds areas of high local contrast by comparing the original image to a blurred version of itself, checks where it differs the most, then uses this mask to enhance constrast in those areas, usually in the luminance channel. The blur radius determines the size, or frequency of features that will be found.

Here’s another experiment with my game engine tablet support patch, now trying to do something a bit more practical with the virtual pen. I’m using the new rigid body constraints in the game engine to construct a brush tip out of ball joints - I have very little experience with them so it’s a bit rough. I wish I knew how to make the motion more damped and swing less loosely, but it works to an extent, and the main thing, it’s all good fun!

I actually find it interesting, since the swinging back and forth of the tip adds another dimension to it, you have to get the angle and timing just right, to get the mark where you want it on the canvas. Although it’s not anything that’s of immediate practical value, it does at least provide an additional level of depth of ‘analogue’ input that could potentially be exploited in fun ways.

Of course this isn’t anything too amazing, being just a poor remediation of ink painting, but it’s a small step along the way to something that I’m interested in investigating, developing more simple, yet flexible tools.

Yesterday I added a new node to Blender’s compositor: Displace. It works very similarly to Shake’s iDisplace node, pushing pixels around based on an input vector mask, and is useful for all sorts of things like doing hot air distortion, quick and dirty refraction effects in post, and so on. The full documentation is in the commit log, I guess I’ll have to tidy it up for the release notes.

One curiousity of this one is the technique used to code it. Most of the code logic was done using Blender’s Python Image API, as a means of quickly testing and prototyping. Python is a lot slower at the actual processing, but it’s a heck of a lot quicker to test than having to compile Blender each time. I recommend it!

You can download the prototype script/.blend file if you’re curious (just press Alt P). I then ported to C, which is relatively easy to do for simple image processing code like this, and changed a few things around. Previously in the Python version I had to try and come up with my own not-too-bad antialiasing code, though I’m sure what I came up with has been done before and has a nice technical name or something ;) In the C version I was able to use some nicer image sampling code that Ton used for the awesome Map UV node. Incidentally, I also used the same Python prototyping technique for the UV test grid option when creating new images in Blender (.blend file).

When I worked on adding tablet support to GHOST, Blender’s low-level input system (alongside Nicholas Bishop and Andrea Weikert who did the X11 and Windows versions), one thing I had in mind was the possibilities not only in the obvious painting and sculpting, but in other more experimental areas too. I’ve got a few ideas sketched down about potential uses in the interface, for example imagine sliders that changed in precision depending on tablet pressure, or a radial menu that uses the tablet tilt information to bias what option is selected.

A tablet, especially one that supports tilt sensitivity like the Wacom Intuos, is almost a poor man’s 3d input device. With X/Y location, pressure and tilt, you can derive a lot of information about the pen’s situation in 3D space. This is interesting to me, because unlike real 3D input devices like spaceballs (which I don’t own), many CG artists have tablets, so input methods involving a tablet can involve a much larger audience than the more obscure devices, and so investigating it doesn’t feel like such a waste of time :).