One of my design goals for gangsta is to have dynamic subdivision surface and microtriangle displacement support, which will mean building trees to hold many microtriangles on the fly, so a fast-to-build structure is essential.

The image above shows gs::rt rendering the 100,000 triangle buddha model in real-time. There are a few bugs to fix as there are holes in the model, but it’s very pleasing to have got half-decent performance from a naïve implementation

Another huge chunk of development, most of it on support code, but it now allows me to create much more interesting images than yet-another-cornell-box.

Rather than just write a scene description format, I took inspiration from some of the stuff we’ve been doing at work and wrote a fairly hefty class library I’ve christened ‘atomic’ (I have to thank John Haddon and Dave Griffiths for the ‘inspiration’ for the design). It basically contains code for storing and manipulating the sorts of data types we care about when describing 3D scenes: point arrays, triangle meshes etc.

The library is bound to python using the excellent boost.python library. Instead of having a scene description I define an abstract RenderInterface, which gangsta (and potentially other renderers such as a preview OpenGL renderer) can implement. The GangstaRenderInterface is bound to python too, so the scene description is really just a python script. Not only does that mean I don’t have to worry about lexing and parsing (eugh!), it also means I can procedurally define geometry etc at render startup time.

The image above was rendered using a script very similar to the one below

But the best thing about having atomic to play with is that it makes writing exporters for your favourite 3d apps ridiculously easy.

Well it’s taken a long time to get to this stage! That’s not a vaseline lens shader, it’s testing the filtering system with a 3-pixel radius box filter. Although the picture looks not a lot different, a huge amount has changed under the surface. It’s now multi-threaded, and renders in buckets which can be freed dynamically as soon as they’re finished, so in theory I can now render an arbitrarily large image.

The biggest challenge in getting to this stage was managing the synchronization issues caused by multithreading. Initially I just had each thread render a bucket, which was then passed off to the display. This was fine as long as all buckets were kept in memory, but if you want to delete buckets when they’re no longer needed you run into trouble because the multipixel filter requires samples from neighbouring buckets. If each thread renders a bucket, how do you know when a bucket’s really finished with and it’s safe to delete the samples it contains?

The solution was to divide and conquer! “One class, one responsibility” is the order of the day. I moved all the rendering code to a functor that is called by the threads. The buckets now simply define regions in the image plane, and the order in which they’re sampled. The actual samples are stored in a SampleCache object which is responsible for managing the memory and can allocate samples in blocks as required. Since the renderer functors just ask the bucket queue for the next pixel’s worth of samples, I have only one point of write access to lock for multithreading (which cuts down the overhead from fiddling with mutexes), and it’ll be trivial to implement adaptive sampling by having the buckets monitor the variance and add samples as required.

There won’t be another update for a fair while as I have to implement some form of scene description as I’m pretty fed up of rendering a hard-coded cornell box all the time

Well after a little bit of laborious typing I got a slightly more intersting scene to work with. Here’s a cornell box, hard-coded into the renderer. The colours here are (s,t)-coordinates assigned to the geometry, to test that the interpolation of variables across the triangle is working

The colours here are the barycentric coordinates of the intersection point on the triangle. I’m using Wald’s precomputed intersection method.