LiAR isn’t a raytracer

LiAR supports the OpenEXR file format for several months now, but I only had it working on 32-bit windows. I was still missing the binaries for the 64-bit build, as you need to build the library yourself. For 64-bit Windows that turns out to be one tricky affair:

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!

… are really good fun. And a huge performance killer too. Especially if you enable in-scattering on your final gather rays. Oh boy, that really hurts! Still playing around with the Sponza atrium, I wanted to do a render of sunlight being casted through the arches on the first floor.

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.

“you may expect updates soon” means “Look, I’m working on it, but I can’t pull all-nighters anymore. So, it’s going to take a while, OK?” =) So, a mere three weeks after that previous statement, here’s my first real update on the LiAR ray tracer. What have I been doing? Well, I concentrated my efforts on the Sponza atrium, to get this one rendered correctly and fast enough. Although it’s an old challenge, I figured that if I wouldn’t be able to tackle this one, there’s no point in trying more up to date ones. So here’s a list of things improved over the last couple of weeks:

• 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!

OK, it has been more than two years since my last update on liar.bramz.net. Back then, we moved from liar.sf.net to liar.bramz.org to liar.bramz.net, the subversion repository got a new URL, and everything went silent. What happened?

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!

Christer Ericson, author of Real-Time Collision Detection has written a little article on Plücker coordinates and why they are considered harmful. It’s great. I never really understood what all the fuss was about, as I could do the Plücker coord tricks as easily with basic 3D linear algebra and its triple product. So, I’m glad to see some of the big guys agree!

(via Pete Shirley’s Graphics Blog)

“LiAR is entirely Plücker free” ;)

As of 28 June 2007, Sourceforge will decommission the SVN access URLs starting with https://svn.sourceforge.net/svnroot/. They are replaced by URLs with the project names in front. For LiAR, this looks like https://liar.svn.sourceforge.net/svnroot/. The new URL scheme is part of an upgrade of the Subversion access method to improve its stability. If your local working copy uses the old URL, follow the switch instructions so that you can still access the repository after 28 June.

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.

We’ve successfully moved the LiAR home page to http://liar.bramz.net. This should allow us to upload bigger renders, and get better search engine coverage. The old URLs starting with http://liar.sourceforge.net should redirect traffic to the new site so that no links get broken.

Share and Enjoy!

If you’re planning to install Visual Studio 2005 Service Pack 1, keep this in mind:

• 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.

While debugging another segmentation fault on linux, I was trying to run LiAR in gdb (actually KDbg). The program crashed somewhere in an allocator, but the reason why was almost impossible to see. The debugging experience was crippled because distutils compiles with full optimization -O3 by default, at least my linux box.

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 …

When I tried to run a first render in linux, I got a segmentation fault in the photon mapper because there were no lights. Of course, this shouldn’t cause a crash (fixed by now), but why were there no lights? I was pretty sure I defined one, and a quick investigation of the scene graph confirmed this.

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