25th June 2006
I purchased some hosting at dreamhost.com, and since they have an easy install for the Wordpress blogging software, I've decided to try it out. So this blog will continue at www.indigorenderer.com/blog/.
18th June 2006
Released v0.5 test 7 as v0.5, finally :)
Main new features are:
Download it from the Indigo page.
In other news, new stuff I'm working on: (from the shader thread)
Alphamapping/transparency support using blended materials:
What I've done here is to create a new kind of BSDF, the 'Null bsdf'.
The null bsdf basically just transmits 100% of light without changing
Then I've created a blend material, that blends between two other bsdfs/materials. In this image, it is blending between a white diffuse material, and the null bsdf. The blend factor is set procedurally depending on the hit position - this gives the ring effect.
So transparency is achieved through the use of a simple material tree, with the root being the blend material, and the two children the white diffuse and null materials.
18th May 2006 (permalink)
I've been learning about colour spaces in the last few days. I think I've got the basics sorted now. I've coded a cool new related feature for Indigo which I'll write about soon (well at least i think it's cool :P).
As for the images, the top one shows Indigo rendering the Macbeth colour chart. The bottom one is the reference from http://www.babelcolor.com. Both the indigo render and the reference are in sRGB. So yeah, i guess the official output colour space for Indigo is now (gamma corrected) sRGB :)
Indigo render of Macbeth colour chart lit with 6500K blackbody illuminant
14th May 2006 (permalink)
I added 'reverse gamma correction' for textures to Indigo a while back... but I don't think I explained in enough detail why it can be helpful. When a Jpeg photo file is created, the expectation is usually that it will be displayed on a monitor with e.g. a gamma of around 2.2 - which means that the emitted power from each pixel is nonlinearly proportional to the RGB values of the pixel. But if such a photo is going to be used as a texture, we want the reflectance to be proportional to what the photo creator expected the emitted pixel power to be. Therefore, the RGB values should each be raised by the power of a usual monitor gamma such as 2.2. This process is called (AFAIK) reverse gamma correction, in analogy with gamma correction, which involves raising the final render RGB values to the power of e.g. 1.0/2.2.
The images below show, for two different reference images,
a) the reference image,
b) the un-reverse gamma corrected texture shown in a scene,
c) the reverse gamma corrected texture shown in a scene.
The scene is a white plane and quad textured with the reference image, lit by a 6500K blackbody emitter. The usual Reinhard tonemapping and gamma correction pipeline is used.
No reverse gamma correction
With reverse gamma correction
No reverse gamma correction
With reverse gamma correction
As you can see, the colours appear washed out if reverse gamma correction is not used.
13th May 2006
Just doing a little bit of work on a more general spectrum system for emitters. There are now 3 types of spectra definable. Here's an example:
<!--Area Light--> <rectanglelight> <pos>0.8 5 5</pos> <width>1.0</width> <height>1.0</height> <spectrum> <!--blackbody> <temperature>8000</temperature> <gain>0.0001</gain> </blackbody--> <!--peak> <peak_min>400</peak_min> <peak_width>500</peak_width> <base_value>0</base_value> <peak_value>400</peak_value> </peak--> <rgb> <rgb>1 0 0</rgb> </rgb> </spectrum> </rectanglelight>
And here's a cool image created using the blackbody spectrum type: (please excuse the noise, 2min render time)
The Blackbody emission spectrum is calculated from Planck's formula. One of the perks of writing a spectral renderer is that this kind of stuff fits in very naturally.
16th April 2006
I've been trying to pull off something like this image for a while, mainly my modelling skills are too crap tho :) This scene is kindly modelled by Jackei. It shows light being emitted from a 'light gun' (which is basically a small rectangular mesh emitter at the end of a tube, with a small rectangular aperture at the other end), then being refracted twice through a prism and finally bouncing off the diffuse wall into the camera. The light undergoes dispersive refraction when entering and exiting the prism, and as a result is split up into a rainbow.
This took about 13 hours to render on 1 pc. I used my (in development) bi-directional MLT code for this, which is really well suited for this scene, as light subpaths can be generated on the light gun emitter and propagated through the prism with a fairly high probability density, as opposed to with plain-old path tracing MLT, in which a path would need to start on the diffuse wall, then manage to bounce through the prism and hit the light-gun emitter.
11th April 2006
Indigo v0.4 is out! Bump mapping, new scene format, exr output, some important bug fixes, and other stuff.
26th March 2006
No, i'm not dead, I've just been working on bidirectional path-tracing, and bidirectional MLT, which let me tell you, is a total mission to debug. In fact it's still not finished, but it's getting there. Already it's looking very promising as a big improvement over the current path-tracing path generation technique used for my MLT code.
Please excuse the crappy jpeg compression artifacts in the images below, I used MSpaint for PNG->JPG out of pure laziness.
MLT on top of (unoptimised) bidirectional path tracing, render time: 10mins
MLT on top of standard path tracing, render time: 10mins
15th March 2006
Working on getting the blender exporter going with the new xml model format. Testing a scene posted here. Approx 15 hours on 2 comps. Floor has new sexy bumpmapping on it :P Click for full size.
13th March 2006
Pretty happy with this image.. an awesome scene from M3willia that I rendered for about 3 1/2 days on 2 computers :) The sunlight caustic noise took *forever* to come out :) Click for full size image.
26th Feb 2006
Indigo v0.3 is out, which means that features like dispersion, absorption, mesh emitters, and network rendering are *officially* out. Also I finally wrote some decent documentation :)
This image was done at 800x600 in ~2.5 hours with 3 computers, and downscaled so as not to break this site. Material is Phong with white diffuse substrate. The model is the 540,000 tri Ajax bust by Jotero. Thx Jotero!!!
12th Feb 2006
I readded dispersive refraction: this is gonna be in the v0.3 release. I'm using Cauchy's equation to model the IOR wavelength dependence this time; last time I used the Sellmeier equation. While less accurate, the Cauchy equation is pretty good in the visible wavelengths, and has the great advantage that the dispersion strength can be controlled with just one parameter. The render below has a pretty unrealistic amount of dispersion, but it's so purty!
11th Feb 2006
This is the depth-of-field test scene that's gonna be in the next release. Render time: ~2 hours
10th Feb 2006
Well I've started on the documentation, in particular the scene xml file format.
9th Feb 2006
Phew, thanks to everyone for the positive response! I've got work and stuff so can't go too hard on major new features right now. I'm working on the documentation tho. And in the meantime I've released v0.2, whose biggest addition is per-mesh disabling of normal smoothing: use it like this:
<model> <!-- other stuff... --> <normal_smoothing>false</normal_smoothing> <!-- other stuff... --> </model>
This should come in handy for all those people getting b0rked normals :P
A great render by U3dreal using indigo v0.1, 1hr 45mins:
6th Feb 2006
Well i got sick of not releasing Indigo, so I've released it, polish be damned! In fact there is not even any documentation. You might have to wait till later this week for some documentation. Otherwise, head over to the Indigo page to download
3rd Feb 2006
The return of the Sponza atrium. The model is of course by Marko Dabrovic. Using new sky model of course :) Render time: somewhere between 10 and 20 hours :P
I thought of a name for my raytracer: from now on I'm gonna call it Indigo. in the past it was just 'my raytracer' :) I'm gonna have a free version available for download soon, as soon as I can add some essential minor features, and fix up some important stuff that I have broken such as perfect specular reflection.
Oh and DSA (thx DSA!) has kindly added a forum for Indigo over at #flipcode, our flipcode replacement :). So feel free to leave any comments or questions over there.
24th Jan 2006
Forgot to roll over to 2006, lol, corrected now :)
15th Jan 2006
A render of the room modelled by Hao La, using the new skylight model mentioned below. Spectral MLT. Render time: ~10 hours.
10th Jan 2006
Done heaps of stuff over the break. I implemented Preetham, Shirley and Smits' physically based sky model (apart from the aerial perspective stuff). I think it looks quite nice. Might say more about this later. Started writing a tutorial/doc on Monte Carlo path tracing. And generally messed around with Metropolis stuff. I'm rendering Hao La's scene (or scene copy at least :)) with the skylighting model right now, it'll be an overnight job :). Oh, it seems to me that i'm going down the path of (the absolutely amazing) Maxwell Render. I think they use this skylight model, and i suspect they use some form of MLT for their renderer. I think this because on their webpage they say they use an unbiased algorithm, and there's no way a path tracer can handle the kind of caustics you can see in some of their renders. Other possibilities are hybrid algs like Energy redistribution path tracing, or perhaps something entirely novel :)
21st December 2005
The sun in these pics is modelled using a far-off rectangular area light, emitting energy according to a blackbody spectrum at 5700K, calced using Planck's blackbody formula. The sky is just a constant bluish environment light for now. As you can see in the pic below, I have to turn off normal smoothing for this scene, otherwise the normals go a bit AWOL. Both renders took about 15 hours.
20th December 2005
Go to past news
--Nick Chapman, email@example.com