Computer graphics and other stuff
Some results:
Bunny benchmark (single threaded) runs approximately 1.9 times faster on my new Core 2 Quad 2.4 GHz than on the old P4 2.8GHz HT.
Exit portal test on Core 2 Quad @ 2.4 GHz, 4 threads:
80000 samples/sec
P4 HT 2.8GHz , 2 threads:
14779 samples/sec
= 5.4 times faster.
Props to the engineers at Intel!
I was having some problems with Exim4 (mail daemon) not sending emails properly on my debian server.
/var/log/exim4/mainlog contained
“Domain of sender address does not exist”
the solution was to change the contents of /etc/mailname from debian.layeredtech.com to indigorenderer.com
Hope this helps someone!
Here are some benchmark results using the Visual Studio 2005 C++ compiler, with various code generation options.
The benchmark is my ray/tri mesh intersection benchmark:
http://homepages.paradise.net.nz/nickamy/benchmark.html
Test machine is a 2.8GHz Intel Pentium 4 with hyperthreading, and 1GB RAM.
All measurements have an uncertainty of +- 1000 traces/second
No full program optimisation:
—————————–
No enhanced instruction set:
traces_per_sec: 1003812.50649
SSE1 only:
traces_per_sec: 1007481.39471
with SSE2:
traces_per_sec: 985040.55002
With full program optimisation:
—————————–
no enhanced:
traces_per_sec: 1006741.35315
SSE1:
traces_per_sec: 1026269.56725
SSE2:
traces_per_sec: 1004555.67294
with Profile guided optimisation:
—————————–
no enhanced:
traces_per_sec: 1031005.48644
SSE1:
traces_per_sec: 1065984.26006
SSE2:
traces_per_sec: 1015676.74568
So there you have it, the fastest option is profile guided optimisation using the SS1 instruction set.
It’s interesting that SSE1 only is faster than SSE2, I guess the compiler is doing something stupid and getting confused trying to generate efficient SSE2 code 
This is good news in some ways, because there seem to be a lot of people wanting to run Indigo that don’t have SSE2 capable CPUs.
Made a nice console mode build of Indigo.
So now there’s a nice indigo_console.exe (in addition to the usual indigo.exe), which doesn’t use any wxWidgets stuff.
Since there will be two similar executables, I moved the OpenEXR stuff out to .dlls.
The OpenEXR code adds up to about 1.4MB of dll executable code, all up, which I think is a pretty excessive amount for an image library.
Without energy loss compensation:
With energy loss compensation:
Some participating media tests:
Render by SmartDen
Render by me, Sponza Atrium model by Marko Dabrovic
Uniform participating medium, isotropic scattering, with some absorption.
The scattering is unbiased multiple scattering.
Time elapsed: 4h, 7m, 24s
Done 2232192000.00000 mutations (8267.37778 mutations per pixel)
mutations_per_sec: 150371.30484 (6.65020 micro-secs / mutation)
The aim of this experiment was to simulate a rainbow, purely from the interaction of a light source and a ’suspension’ of ‘water droplets’.
Credit goes to Manitwo for modeling this scene.
The water droplets are modeled as spheres. There are about 33000 (approx 180*180) droplets in this scene, positioned in an array formation with a depth of just one droplet.
The water interface/medium is modeled as an Indigo specular material with a refractive index of 1.323, and a Cauchy b-coefficient of 0.003. Absorption was 0.
The rectangular light source is positioned some distance behind the camera at an angle of approximately 16 degrees from the horizon. A sun + skylight emitter was originally used, but due to the tiny solid angle subtended by the sun, the render was taking far too long to converge.
Actually, the render below took 56 hours, making this just about the slowest converging scene ever
As in real life, the rainbow effect arises from light from an emitter being refracted into a raindrop, reflecting off the rear wall of the droplet, and refracting out of the raindrop, at an angle of approximately 40-42 degrees from the incident ray, depending on the wavelength of the light ray.
You can see in the render that the region under the rainbow is brighter than above the rainbow, which is observable in real life as well.
Time elapsed: 56h, 52m, 1s
Done 85425.99807 samples per pixel)
samples_per_sec: 112665.20675 (8.87585 micro-secs / sample)
Finally got round to making a Brewster’s angle experiment, in order to test out my polarisation code.
Brewster’s angle is the angle for which light polarised in the plane of incidence is totally transmitted, meaning none of it is reflected. By ‘polarised in the plane of incidence’, I mean the electric field vector of the incident wave is orthogonal to the light wavevector, and to a vector lying on the interface.
When the light is incident on a medium of refractive index of 1.5 (e.g glass), from a medium with a refractive index of ~= 1.0 (air), then Brewster’s angle is tan^-1(1.5/1.0) ~= 56.3 degrees.
So in this scene, I’ve set up a camera, a dielectric block with index of refraction (IOR) of 1.5, and an emitter, so that the light rays from the emitter will strike the block at Brewster’s angle, and reflect into the camera. (Actually, since I’m using the backwards pathtracing mode, rays are traced from the camera, reflected off the block, and then strike the emitter)
I’ve coded in a polarising filter simulation, which works basically by projecting the electric field onto a specified vector orthogonal to the camera direction. The overall radiance along a path therefore depends on the polarisation of the light when it hits the camera, relative to the specified ‘polarising vector’.
The polarising vector is specified by a single value, which gives the vector as the right-vector of the camera, rotated counter-clockwise looking in the camera forwards direction, around the camera forwards direction.
So an angle of 90 degrees means that only light with a vertically polarised component will register.
In the following render, the camera uses a polarising filter with an angle of 0. So only the horizontally polarised component of the light passes through. Note that the reflection of the emitter in the block is very bright.
In the next render, the camera uses a polarising filter with an angle of 90 degrees - the transmission axis is vertical.
Because the light from the emitter hits the block at Brewster’s angle, the vertically polarised component of the light is almost totally transmitted, which results in a total horizontal polarisation of the reflected light, which has a zero projection onto the polarising filter vector, resulting in basically no reflected image of the emitter.
The following image is a side view of the setup.
The dielectric block has been changed to a green diffuse material so that it can be seen more easily. The original camera position is off to the right of the image, at the same height as the block. (3 mins render )
Implemented instancing.
There are 10,000 Ajax models in this scene, at 544,000 tris each, for a total of ~5.4 * 10^9 (5 billion) tris.
Oh, to generate the xml for this scene, I used a ruby script, which i’ll link here, as it might come in useful for someone: