1. Only Visual Studio solution files are available so that rules out nmake.
2. DLL creation involves an custom build tailored for x86.
3. The Visual C++ Express editions are x86 only anyway, so you have to work around that as well.
4. And surprisingly, it seems that no-one has ever bothered so before because there’s hardly anything to be found on the web.

After several hours of hairpulling, I’ve finally managed to set up a working x64 build. To document it for future reference, and for other people on the same adventure, here are the magic build steps:

Setting up the build tree

The OpenEXR build is rather picky on the build tree layout. While the absolute location is free for choice, you need to add an extra layer for things to play out nicely. On my machine, I’ve put everything in C:\libs-x64\openexr-1.6.1, but that could be just any other location.

1. Download ilmbase-1.0.1.tar.gz and openexr-1.6.1.tar.gz.
2. Create C:\libs-x64\openexr-1.6.1\openexr.

   This extra layer is necessary to make sure the goodies are gathered in C:\libs-x64\openexr-1.6.1\Deploy. Otherwise, they would end up in C:\libs-x64\Deploy.

3. Extract ilmbase-1.0.1.tar.gz to
   C:\libs-x64\openexr-1.6.1\openexr\ilmbase-1.0.1
4. Extract openexr-1.6.1.tar.gz to
   C:\libs-x64\openexr-1.6.1\openexr\openexr-1.6.1

Using VC Express for x64 builds

For Windows, OpenEXR comes with Visual Studio project files only. So you must use Visual C++ for building. If you’re using the VC Express edition, that’s a problem because it only has a x86 compiler on board. And you can’t directly use the x64 compiler of the Windows SDK, as that requires nmake makefiles, which you don’t have. But you can do it indirectly …

1. Open a Windows SDK CMD shell. This sets all the required environment variables to use the x64 compiler.
2. "%VCINSTALLDIR%\..\Common7\IDE\VCExpress" /useenv or whatever the location to vcexpress.exe is.

   The /useenv switch is important to tell the IDE not to use the default compiler, but to assume the environment is already setup ready to go. This is exactly why we run this within the Windows SDK shell.

3. Open a solution and make sure you target the x64 platform.

   You won’t be able to setup a new x64 configuration, but you can just open the Win32 configuration, go to the advanced linker options and specify MachineX64 (/MACHINEX64) as target machine.

   

4. Build …

Building IlmBase

IlmBase contains the createDLL project that builds a tool for the custom build steps. You need to tweak its sources to correctly skip names starting with an underscore. Because createDLL assumes the x86 __cdecl calling convention which decorates names with an extra underscore, it actually only skips names that start with at least two underscores. But the x64 calling convention does not decorate them as such, so names starting with a single underscore slip through the net.

1. Start VC Express, open
   ilmbase-1.0.1\vc\vc8\IlmBase\IlmBase.sln and convert if necessary.
2. Set the target machine to MachineX64 (see above)
3. Open createDLL.cpp to make the following code changes:
   • Replace /MACHINE:X86 by /MACHINE:X64 (line 683)
   • Replace the following (three occurrences!)
     

     // symbol starts with two underbars, skip it
     else if (buf[0] == ‘_’ && buf[1] == ‘_’) {

     by

     // symbol starts with underbar, skip it
     else if (buf[0] == ‘_’) {

4. Build …

   If you get errors like fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64', you should have started VCExpress with the /useenv switch from the Windows SDK CMD shell, as described above.

Building zlib:

OpenEXR has a dependency on zlib. So if you don’t have done so yet, now is the time to build it …

1. Download zlib125.zip and extract to C:\libs-x64\zlib-1.2.5
2. Open a Windows SDK CMD shell
3. cd /D C:\libs-x64\zlib-1.2.5
4. set Include=C:\libs-x64\zlib-1.2.5;%Include%
5. nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF" OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"

Building OpenEXR

OpenEXR expects the zlib headers and libraries to be in the Deploy directory as well, so that’s where we’re going to put them.

1. Copy zlib.h and zconf.h from C:\libs-x64\zlib-1.2.5 to Deploy\include
2. Copy zdll.lib to both Deploy\lib\Debug and
   Deploy\lib\Release
3. Copy zlib1.dll to both Deploy\bin\Debug and
   Deploy\bin\Release
4. Start VCExpress and open
   openexr-1.6.1\vc\vc8\OpenEXR\OpenEXR.sln
5. Set the target machine to MachineX64 (see above)
6. Build …

That’s it. By now you should have a Deploy directory filled with OpenEXR headers and libraries, ready to be used in your x64 build of, for example, LiAR =)

Happy Towel Day!

Anyway, to cut things short, here’s the final render. It only took a ridiculous long time to compute (12 hours on a quadcore). Click on the image for full resolution. Tonemapping has been done in photoshop. Model & textures courtesy of Marko Dabrovic.

Adding single scattering was easy enough. Just ray march or sample some points along your camera rays and add light source contributions to each of them using a suitable phase function. Don’t forget to add some attenuation – Beer’s law comes to mind – to your camera rays, light rays and photon paths. Basically on anything that travels through your medium. As phase function, I’ve chosen to use the widely used Henyey-Greenstein model. It isn’t particularly the fastest one around, but as I don’t have a good profiler (yet ;), I don’t really know its impact on the render time anyway.

Multiple scattering is somewhat of a different beast, though it’s not too difficult either. In the photon mapping world, it means augmenting the renderer with a volumetric photon map that records all scatter events during the photon trace pass. For each photon that travels through a medium, you sample a possible scattering location. In case of a homogenous medium, this is as simple as feeding a uniform variate in the inverse cumulative of the exponential distribution, which can yield a travel distance from zero to infinity. If it is nearer than the first surface intersection, you store the photon and sample the phase function for a new direction. Some more details can be found in Lafortune and Willems (1996) and Raab, Seibert and Keller (2008).

In the rendering pass, I used the beam radiance estimate from Jarosz, Zwicker and Jensen (2008) to collect the in-scattered light from the volumetric map on the camera and final gather rays. This method represents the volumetric photons as spheres, and all photons intersected by a ray contribute to it. In case of camera rays, I ignore “single scattered” photons, as I account for single scattering seperately.

Because this operation weights very heavy on the final gather step, I stochastically skip the in-scattering estimate for a number of gather rays. For each ray, a uniform variate is compared to a quality factor. Only if it is lower, volumetric photons are collected. The result is divided by the quality factor to compensate. That way I can trade speed for accuracy.

• Added TriangleMeshComposite which merges the triangle meshes of different objects into one acceleration tree. This is especially important in the Sponza atrium, as the 34 different TriangleMesh objects in the sponza scene largely overlap. So ray traversals are going to hit the bounding boxes of most of them, most of the time, and as such the traversal degrades to a linear search of the scene objects. Using the TriangleMeshComposite, ray traversal visits only one triangle mesh.
• LightSky caches the radiances in a rasterized map, using the same resolution as the CDF map. This ensures better coherence with the PDFs of the drawn samples (using importance sampling)
• Using Multiple Importance Sampling for the direct lighting pass solves a lot of the noise issues in the shadows (otherwise, most of the shadow rays are aimed at the sun and thus blocked)
• Final Gather step uses the local effective estimation radius to decide if secondary gather rays are necessary. Before, it used the global maximum estimation radius, but that one needs to be quite large. So the secondary gather step was triggered a lot, causing either a huge performance hit, or a quality drop. In areas with high photon density, this threshold may be lower as the photon map is much more detailed and the need for second gather rays averted. The rule is now that secondary gathering is only used if the length of the first gather ray is smaller than the effective estimation radius of the photon lookup. Otherwise, it is assued that the first gather step is of sufficient quality.
• The samplers (Stratifier and LatinHypercube) take into account the pixel super sampling when generating samples for lights, BSDFs, gather rays, … For example, when using 3×3 super sampling with 8×8 gather rays each, the stratifier will generate the gather samples on a (3*8)x(3*8) grid.
• The shaders now return a BSDF instance, caching the texture lookups. Don’t know why I haven’t done this before, but it surely helps with complex textures …
• Added JPEG and OpenEXR image codecs
• Lots of improvements to the Blender exporter, though there’s still lots and lots missing

Here’s a render showing the current state of LiAR. Click on the image for full resolution. Tonemapping has been done in photoshop. Model & textures courtesy of Marko Dabrovic.

Work on a ray tracer is of course never done, and even for this Sponza atrium, there’s still room for improvement, both quality and performance wise. Here’s a bit of a TODO list for the near and far future:

• Improve final gathering quality, using importance sampling based on the directions of the local photons
• Use a profiler to investigate how much can be gained by improving the performance of the ray traversals and Kd-tree lookups
• Use caching and subsampling to improve the perfomance and smoothness of the indirect lighting
• Add volumetric stuff
• Spectral rendering. Now I’m using XYZ values everywhere, which is (a) physically wrong and (b) doesn’t allow dispersion
• Implement subtractive lighting to render objects with an existing backdrop in one pass.
• Implement the Metropolis Light Transport algorithm

Stay tuned, and happy Pi day!

Well, I started taking real pictures instead, that’s what happened … And I started doing it quite regularly as well, mostly concert photography. Started shooting befriended bands, then I joined Indiestyle and later I was the in-house photographer of Westtalent 2009.

But then, fellow indiestyler Jaan Meert posted on facebook a 3D render of a lego tractor he made for school. And that’s got it itching again … I wanted to do 3D renders myself, but it LiAR was severely out of shape. So shaping has to be done, and after all this time, coding on LiAR is fun again.

Currently, I’m working on the good old sponza atrium, to get things in good condition to tackle further challenges. I’m using Blender as a platform to set up the scene, and export it to a python script for LiAR. It’s working as a charm, and you may expect updates soon!

(via Pete Shirley’s Graphics Blog)

“LiAR is entirely Plücker free” ;)

PS: I know LiAR has been silent for the last couple of months. There was just too many other things to take care off. However, the last couple of weeks, I’ve resumed coding on LiAR, albeit slowly, so hopefully I will be able to add some new posts in the near future.

Share and Enjoy!

• Make sure you have at least three gigs of free space on your C: drive. To be on the safe side, make it four gigs.
• Windows Update tries to shove this up your arse as a security update, but don’t let it. Do a manual install instead.
• Log in as Administrator. I know you already have super monkey admin powers, but do it anyway.

The aftermath?

Well, it did solve the test errors we had in the win32_vc8 build of Lass, like the fld loading corrupt data on the FPU stack. It also solved the template class member function overload ambiguity we suffered in testUtilThreadFun.

It did cause some other troubles though. Apparently SP1 screws up on default arguments in function template declarations. In lass::prim, all intersection functions are implemented in *.inl files with the function declarations being listed in the accompanying *.h file. These functions have a parameter tMin that defaults to zero. This worked/works fine on VC6, 7, 7.1 and 8 sans SP1, all GCCs I could get my hands on, but not on VC8 SP1. It still compiles the code, but at runtime, tMin contains garbage when the default value is used. Unfortunately, I was unable to reproduce the problem on a smaller scale. Anyway, the solution to this problem was to move all intersection functions to the header files so that the separate function declarations no longer exist.

If I was going to debug it properly, I would have to get rid of that switch and use -O0 instead. But for some mysterious reason, distutils always used -DNDEBUG -g -O3 -Wall -Wstrict-prototypes, regardless of the --debug switch. It turns out distutils is getting these from the original Makefile used to build Python and stores them, together with the name gcc, in an attribute compiler_so of the CCompiler object. This attribute is later used to invoke the compiler.

Fortunately, in liar_build_shared_lib and liar_build_ext, we have access to the compiler object. All we have to do is, before building, to grab compiler_so, remove any -O switch and put an -O0 instead:

def force_no_optimisation(compiler):
    for i in range(4):
        try: compiler.compiler_so.remove("-O%s" % i)
        except: pass
    compiler.compiler_so.append("-O0")

class liar_build_shared_lib(build_clib):
    def build_library(self, lib_name, build_info):
        force_no_optimisation(self.compiler)
        ...

class liar_build_ext(build_ext):
    def build_extension(self, ext):
        force_no_optimisation(self.compiler)
        ...

What was causing the segmentation fault? The std::vector in kernel::Intersection was requesting memory for 0 elements. The lass::util::AllocatorBinned wasn’t really prepared for that. Once identified, it was easily fixed …

Before rendering is started, SceneLight instances are harvested from the scene graph by a visitor LightContextGatherer to collect all instances of SceneLight objects. It’s an acyclic visitor as described by Andrei Alexandrescu.

class LightContextGatherer:
    public util::VisitorBase,
    public util::Visitor<SceneObject>,
    public util::Visitor<SceneLight>
{
    void doVisit(SceneObject&);
    void doVisit(SceneLight&);
};

The way it works is that if a scene object, for example a LightArea, accepts a visitor, it tries to cast the visitor to util::Visitor<LightArea>. If it succeeds, it will call the appropriate doVisit function. Otherwise, it tries again using its parent type, in this case SceneLight. As a result, all lights instances end up in doVisit(SceneLight&), and all other objects in doVisit(SceneObject&).

But for some reason, neither doVisit was ever called. It turned out that the dynamic_cast, used to cast the visitor to the appropriate type, always returned null, even when trying to cast to util::Visitor<SceneObject>. Huh?

Some googling revealed that GCC 3.0 uses address comparisons to determine type equality. This obviously has a performance advantage over string comparisons, but doesn’t work quite well if left and right have a different set of typeinfo instances. This can when using dynamic linkage, and it certainly doesn’t help that Python uses dlopen to load extension modules.

Fortunately, the GCC FAQ also mentions a solution which is to link with the -E flag to add all symbols to the dynamic symbol table, and to use dlopen with the RTLD_GLOBAL flag set. For LiAR, the former means adding -Wl,-E to extra_link_args in setup.py. The latter can be done using sys.setdlopenflags. Proper try/except wrapping ensures that it is only called if appropriate. At least one linux system did not provide the dl module, but fortunately the same constants also live in DLFCN (also not always available), so that’s why the heavy nesting. The code is put at the beginning of __init__.py.

try:
    try:
        import dl
    except:
        try:
            import DLFCN as dl
        except:
            pass
    sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)
except:
    pass

The goal is to use Python’s distutils and write a single setup.py to build and install LiAR. So no make or autotools are allowed. The idea is that eventually, the setup.py can be used to build LiAR on Windows as well. I’ve decided against using setuptools (eggs) and SCons because distutils is already included in the standard libraries of Python. But first, I’ll be trying to get it working on linux alone, what is already good for quite some challenges.

First, a recap of how LiAR is built. It consists of different (extension) modules organized in a star topology. The center module is called the kernel and provides general definitions (Spectrum, Intersection, …) and abstract classes (SceneObject, Shader, Texture, …) that are used as vessels and ports by which the concrete modules (scenery, shaders, textures) must communicate. Each concrete module only depends on kernel (and of course 3rd party libraries if appropriate), and since LiAR is implemented in C++ this means including its headers and linking to it dynamically.

Unfortunately, distutils is not designed for architecture like that. It can build multiple extension modules in a single package, but they’re supposed to be independent of each other. They cannot be linked in a binary way, communication should be done through Python. Modules don’t have the usual libfoo.so name anyway. However, distutils does support the build of C libraries that the extension modules can link against, but only for static libraries and what we need is dynamic linkage.

This calls for a bit of hacking. Luckily, distutils has a mechanism that allows to add extra custom commands. This can be used to hijack the build_clib command (for static libraries) and use it to build shared libraries. A new command liar_build_shared_lib is derived from build_clib and the relevant methods are overridden. It’s a bit too long to post here (you can see for yourself in the code repository), but basically it’s a blend between build_clib and build_ext. The cmdclass argument in setup() is used to inject liar_build_shared_lib as the new build_clib.

The concrete modules need to be linked to kernel, but a Python extension module does not have the regular libfoo.so name, but simply foo.so instead. What I’ve done to solve this, is to create libkernel.so which is kernel sans kernel_init.cpp, and a shallow module kernel.so that consists only of kernel_init.cpp. This way, all modules can link to a regular library, and kernel.so exposes its content to Python.

By now, things pretty much compile. I can even import liar in Python, though I must use the LD_LIBRARY_PATH environment variable hack to tell the modules where they can find libkernel.so. And once I start running some scripts I quickly get segmentation faults. So there are still some things to solve =)

Also, I need to clean up setup.py a bit, because things were simply thrown together until it worked. Options are still pretty much hardcoded. And also, I would like to be install the kernel headers so that custom LiAR extensions can be build using the installed LiAR.

This is different from using a fully transparent BSDF because the latter will split ray paths by inserting a no-op scattering event. This is especially a major difference for shadow rays in a direct lighting pass: they block on the first scattering event causing the transparent parts to cast shadows. When using clip mapping, no scattering event will be inserted because the surface is not present, and thus shadows will be casted as expected.

It’s implemented as a special scene object ClipMap that takes a child object and a clip texture. When the object is tested for ray intersections, a candidate intersection with the child object is searched for, and if one is found the clip texture is evaluated using the local intersection context of the child object. If this yields a value above a threshold, the intersection is accepted. Otherwise, a new candidate intersection is searched for with an adjusted near limit of the bounded ray.

It was pretty easy to implement, however not without cost. The intersection context needs to be evaluated independently of the one used for shading. Worse, the used intersection context may be different depending on which level the shader is defined. Also, the function isIntersecting can no longer use any shortcuts, but must perform a full intersection test.

while (true)
{
    child_->intersect(sample, ray, intersection);
    if (!intersection)
    {
        result.swap(intersection);
        return;
    }
    child_->localContext(sample, ray, intersection,
        context);

    if (clipMap_->lookUp(sample, context).average()
        >= threshold_)
    {
        intersection.push(this);
        result.swap(intersection);
        return;
    }
    ray = bound(ray, intersection.t(), ray.farLimit());
}

You can try it out for yourself using the clip_map.py example in the examples/scenery directory.

(*) The term clip mapping is being used in LightWave 3D and some other renders, and also appears in the book Digital Lighting & Rendering by Jeremy Birn. However is also used for naming the act of loading small parts of huge mipmaps to reduce memory requirements.

So, I’ll have to search for something more clever. Probably something similar as for the vertex coordinates. However, I wonder what to do with seams in the texture mapping … To be continued …

The implementation also supports the concept of creases. If an edge of the mesh has a crease level different than zero, the subdivision must leave the edge sharp for a number of iterations equal to the crease level. For example, if an edge has crease level three, and a subdivision of five levels is applied, then the algorithm must leave the edge sharp for the first three iterations, and may only smooth it for the last two. This will give the edge a sharper appearance than the rest of the mesh. If the crease level is equal or greater than the subdivision level (for example both level five), then the edge will stay ultra sharp, since the algorithm will never be allowed to smooth it.

In the following image, the same cube is shown for different subdivision and crease levels. There are no vertex normals used, to clearly show the different faces of each resulting triangle mesh. So no sneaky normal interpolation to give the mesh a smooth appearance!

At three o’clock, there’s a perfect cube with subdivison level zero. Going in counterclockwise order, the subdivision is each time increased by one level. At nine o’clock, subdivision level six is reached, resulting in a very smooth object. Remember there are no vertex normals here!

Continuing in counterclockwise order, the subdivision level is now kept at constant of six, but the crease level of the cube’s edges is each time increased by one. The circle would be closed again at three o’clock with both the subdivision and creasing at level six, but this is virtually the same as the original cube (both at level zero), only with a much finer triangle mesh.

You can try all this for yourself using the example loop_subdivision.py in the examples/scenery subdirectory.

PS: you will have to update your Lass installation to use this, since the actual subdivision code is part of Lass.

with:

• and the resulting reflectance and transmittance
• is your usual fresnel reflectance
• is the transmittance of the medium using Beer’s law where is the transparency of the medium and is the cosine of the angle of the refracted rays inside the material

Model by Live for Speed, light probe by Paul Debevec, custom skin by PHD-Motorsports.

update: this render is also featured in the #flipcode gallery.

update: Nicholas “Ono-Sendai” Chapman of the Indigo Renderer has pointed out that Radiance is using a very similar BSDF for their glass material. This is not so surprising, since it’s a very simple extension of the Fresnel equations. The only difference is the distinction between TE and TM waves, which is more correct than what I’m currently doing.

update: Leonhard Gruenschloss noticed a few typos in my formulas (see comments). I’ve corrected them now Thanks Leonhard! (20 feb. 2007)

The former was – I believe – originally suggested by Per Christensen in Faster Photon Map Global Illumination. The idea comes from the observation that when using final gathering, a lot of time is consumed by the radiance estimates where final gather rays hit. When you cache these estimates at selected positions, You can gain a factor of 5 to 10 in speed, while the error you get by using this approximation will hardly be noticeable due to the nature of the final gathering.

For the caustics photon map, I’ve used the technique mentioned by Keller and Wald in Efficient Importance Sampling Techniques for the Photon Map. All photons that have gone through a specular event before hitting a diffuse surface, are stored in the caustics map. All other photons are stored in the global photon map after being selected with a probability of 1/Q, with Q the caustics quality factor. The Q factor is an easy way to set the resolution of the caustics map. If you set it higher, it will contain more photons and deliver crispier caustics. There’s still some issues with the caustics map though. I need to add some filtering, and use the convex hull as an area estimate to get crispier caustics and prevent leaking.

To experiment with the caustics, I’ve added a dielectric Fresnel shader with proper reflection and refraction (see my article Reflections and Refractions in Ray Tracing), which is of course used for the yellow sphere. I’ve deployed a simple medium material system (volumetric shaders), so that I could attenuate the light going through the sphere using Beer’s law. The yellow colour is entirely due to this Beer medium, as the Fresnel shader is … well … colourless (greyscale).

For the blue sphere in the back, I’ve implemented the famous Ashikhmin & Shirley BRDF (An Anisotropic Phong BRDF Model and An Anisotropic Phong Light Reflection Model). This of course has nothing to do with caustics, but it’s a very cool shader nevertheless. Notice the slightly glossy reflection and the Fresnel behaviour at grazing angles. I do have problems for keeping the photons at constant powers though, the specular lobe bumps power up, but I’m not really sure if it can be avoided.

Where’s the road going from here? One thing that I certainly want to add to the photon mapper is importance driven photon shooting, so that we can go crazy with sky lights and windows … The other is some priority stack for medium materials, to solve the water-in-a-glass problem (more about that later). And while we’re at it, we should add more in- and outscattering to the medium materials so we can have fog =) I’m also trying to put one of the PHD-Motorsports cars in the Cornell box, but I seem to have some problems to smooth the mesh properly.

PS: we have reached revision 42 in the subversion repository. w00t! ;)

I’ve been busy with a few things, the main one being the photon mapper. It’s not completed yet. Currently we only have a global photon map and a gather step with a full radiance estimate. On the agenda are precomputed radiance estimates, importance driven photon shooting, caustic photon maps, …

The photon mapper does not use the traditional diffuse/specular/absorption Russian roulette of Jensen, but rather a full BSDF approach as described by Pharr. This required a complete refactoring of the shaders, which was the other big thing I was working on.

As you could read in an earlier post, I was not so happy with my material implementation. The shaders didn’t match well with things like photon mapping, so I completely ditched the shader approach for a BSDF one. I was a bit worried about having to evaluate expensive textures for each BSDF call, so I had to find a way to buffer them. The solution I’ve choosen is to compute many values in one call by some kind of iterator approach.

I guess that’s it for today. But of course, there’s still some render to show. OK, it’s only a dull cornell box, but it allows me to check my results more easily because I know what to expect. Overall, it looks good, but you might notice some problems at the edges of the wall. Apparently, the final gather doesn’t work so well over there.

It’s been a while since the last update. We can assure you that LiAR isn’t dead, but unfortunately we have been through some busy months, and some more are coming up, which puts everything on a hold. So there probably won’t be many updates in the next couple of months either.

See you after the break =)

(Light probe: Grace Cathedral by Paul Debevec)

Basically, rendering goes like this: find intersection, find geometry of intersection, get shader at intersection, shade using the geometry. However, currently, if the object being intersected is a transformed one (by scenery::Transformation), all local geometry (3D point, normal, …) was transformed to global space, the top level of the transformations. So, all shading was done in global space. Is that bad? Yes. Imagine a sphere that uses a 3D texture like CheckerVolume, and this sphere moves from the left to the right. Because the value of the texture is looked up in global space, this means that the sphere will move while the checkerboard pattern is stuck to its global position. This is not what is wanted. The pattern should be fixed to the object!

OK, seems easy to solve that: don’t transform local geometry! Instead, when shading, transform all global information (eye rays, light rays, …) to local space. Well, not exactly … There’s a bit of a problem to this approach: suppose you create a complex object using CSG and some transformations, then every part of that object will have its own local space. If you apply one 3D texture to the complex object, you’ll notice that you won’t get a continuous texture: it will jump from one local space to another.

So, we need a combination of both. Basically, from the observation above, we want to do the shading in the coordinate space of the (compound) object the shader was attached to (let’s call it shader space). The untransformed sphere in the first case, the complete CSG object in the latter. When retrieving local geometry, transform it up (towards global space) until you get to the object with the shader attached. From there, keep track of a single transformation from shader to global space.

Using this approach, we get the following result. One sphere with radius 1 is instanced three times: once without transformation, and two times scaled up by a factor 2.

• The middle sphere is the untransformed sphere and a shader attached with a standard CheckerVolume texture. For this one, local space = global space = shader space.
• The left sphere is a second instance of the middle sphere, but scaled up by a factor of two. The shader space is still the local space of the untransformed sphere. As result the texture is scaled up together with the object.
• The right sphere is a third instance of the same sphere, however this time, the shader is attached to the transformed sphere. This means that the shader space = global space. As result, the pattern has the same size of the untransformed sphere.

script: examples/scenery/transformation.py

Add photon mapping to the mix (or another GI thingy like path tracing, radiosity, … though radiosity might still do with the shaders above?). Suddenly, those shaders aren’t so cute anymore. Since photon mapping basically shoots a photon at a surface, and wants to know in what direction that photon will be scattered. This is very BRDF oriented. We can’t really do that with shaders, or can we?

So here’s the dilemma … abandon shaders, or come up with a solution that fits both? What solution?

The scripts are available in the examples/cornell_box directory.

The first one is the good ol’ red sphere with a spherical area light. The entire scene is also illuminated by a blueish sky. 9 samples per pixel, 16 light samples for the sphere and 36 for the sky.

Happy Buddha under a bright white sky … 9 samples per pixel, 64 light samples

The sky surface is a bit troublesome because it LiAR isn’t exactly designed to cope with points at infinity. Currently, it’s just a giant normal sphere, but it should be examined how we can improve that.

We also need to be able to texture map the area lights so that we can use a nice HDR image as sky =)

You can grab the latest code from the repository by the following command:
svn co https://svn.sourceforge.net/svnroot/liar/trunk/liar/

The repository is also browsable. More info can be found on the project page

One lesson learned: you should never update a PixelToaster display in another thread than in the one you’ve opened it. Upon the first call of update(), somewhere deep inside the function, there’s a call to the Win32 ShowWindow function (the window still is hidden when you open it). However, that call will block when it’s called from a different thread than the one to create the window …

Things to do: currently, the window closes the moment the render is finished … We’ll need the “press any key” feature!

You can’t continue crafting your scenes in raw Python code forever. One day, you want to use a real modeling program. And what program better suits this need than Blender? First of all, it’s free and open source. But secondly (and perhaps more interesting for LiAR), it has an embedded Python environment. So, we can write our export script in pure Python, which is of course great.

It takes a while to get the hang of their Python API, but once you get the feeling, it’s fairly easy. And so here’s the first result. I’ve managed to export the default scene (the one you get when you start Blender) to a LiAR script, and to actually render it. It’s not exactly spectacular (it’s rather dull even), but it works. A lot of features are still missing, but that’s not so important. The important thing is that the export works. Here it is (model courtesy blender.org =) …

I can’t link to the code, because it’s not in the CVS yet, but when it is commited, you’ll find it in extras/blender_scripts/liar_export.py

The cars are rendered with depth of field for a more realistic image …

Model by Live for Speed, custom skin by PHD-Motorsports.

Adding depth of field to a ray tracer is rather easy once you’re familiar to the concepts of distributed ray tracing (which isn’t too hard either). First, you generate a primary ray as usual and you determine it’s intersection with the focal plane. This is a (virtual) plane orthogonal to the camera direction and al points on this plane will be in focus. Then you generate a new origin of the primary ray. This is done by picking a random point on the camera “lens”, which is a disk orthogonal to the camera direction and with the camera position as center. The best way to do this is by generating stratified samples in the range and to transform them to a disk (Peter Shirley has written a paper on how exactly to do this). Finally, you generate the new ray direction from the point on the lens to the intersection on the focal plane. This makes sure everything on the focal plane is indeed in focus. Voila, that’s it!

It’s been a while since my last update. I’ve been rendering cars for PHD-Motorsports. The setup is rather simple. The same triangle mesh is instantiated three times with a different skin. There are three point lights: a pure white key light in the front left corner, a blueish fill light in the front right corner, and as last a blueish back light.

Of course, we also had to render some “action”, so we added a bit of motion blur to the side view of the cars. A checker board is added a floor to have a fixed object as reference.

Model and skin by Live for Speed and PHD-Motorsports.

Last week, LiAR CEO Bram de Greve was contacted by De Muer in search of funds for his team. Both bosses agreed that LiAR will commit to a long-term financial backing of PHD-Motorsports. In return, the corporate logo will be prominently displayed on the team’s racing cars starting from the next championship race on December 4, 2005 in Blackwood.

“It’s a great opportunity for us”, de Greve said. “We’ll be able to showcase our technology that naturally fits the fast cars of PHD-Motorsports. And I also know team member Tom De Muer from his work on LASS, so I have great confidence in their performance.”

Stay tuned for renders of the team’s racing cars. Meanwhile, be sure to check out the team news on their homepage www.phd-motorsports.com.