[Radiance-general] A modern comparison of Radiance and other rendering engines

[Greg Ward]

It's a great question, and I think Lars and Germán summarized the differences pretty well.  The bottom line is that you can take almost any renderer and add the needed features and capabilities to make it physically accurate, but there is little economic motivation to do so.  The main, important difference between Radiance and other tools is the dedication of this community to keeping the focus on accuracy every step of the way.

This discussion reminds me of an interesting study performed by Christoph Reinhard and Pierre-Félix Breton, comparing Daysim to Autodesk 3ds Max.  They found that 3ds could in fact simulate the simple side-lighting case they were testing, but figuring out how to set the materials correctly and interpreting the output was tricky.  (The reference is linked below.)

	C F Reinhart and P-F Breton, “Experimental Validation of Autodesk® 3ds Max® Design 2009 and Daysim3.0”.LEUKOS, 6:1, 2009
	http://www.ibpsa.org/proceedings/BS2009/BS09_1514_1521.pdf

You might read this report and decide, "Hey, I'll go with the big commercial software, since it probably has a smoother workflow," and you could be right.  Except, the next release comes out and the features you were relying on are no longer supported, or just don't work as they used to.  This has happened many, many times over the past 30 years or so that I've been paying attention.  

The most tragic trajectory was the one followed by LightScape, which was initially intended as a head-to-head competitor of Radiance, and was quite good at it, taking more of a radiosity approach with some ray-tracing add-ons.  This was eventually bought by Autodesk, and stayed true to its purpose for maybe 5 years before things like photometric files lost support, followed by numeric output, followed by every useful feature for lighting simulation.  (I can't say for sure, but I bet the renderings got nicer-looking in the same period.)  The point is, although there is a small community of people who are keen on accurate results out of their renderer, the money is in good-looking output.

In contrast, Radiance has been plodding along a lonely but very constrained path over its lifetime, where features are added only if they improve accuracy, or add capabilities without compromising accuracy.  There's no money in it, but the reward is that we have at least one tool to which all the others can be compared when you really need to know, "Is this the right result, or does it just look right?"

Cheers,
-Greg

P.S.  To Germán - irradiance caching was originally unique to Radiance, but a lot of ray-tracers have picked it up since then.

P.P.S.  I should mention that AGi32 is the one commercial tool that has consistently stayed true to the cause of lighting simulation over the years.  When we get together, Ian Ashdown and I like to joke about what would happen to lighting software if a meteor were to choose that moment to take both of us out.

> From: Germán Molina Larrain <germolinal at gmail.com>
> Date: January 29, 2018 5:44:09 AM PST
> 
> Hello, 
> 
> I agree with Lars in everything, but I also want to add some things:
> I believe that, for scientific use of daylight simulations, you need extensive numerical validation. Some renders are not focused on that, but only on speed and generating "photorealistic images", which are different from "photometrically correct images"... Does that make sense? I think this is the most important difference between Radiance and other renderers out there.
> In 2012 I asked this in the PBRT google group, and they advice me to keep using Radiance (LINK) 
> The irradiance Cache seem to be pretty unique for Radiance.... ? 
> Best,
> 
> Germán
> 
> 
> 2018-01-29 9:23 GMT-03:00 Lars O. Grobe <grobe at gmx.net>:
> Hi,
> 
> there are even more renderers, e.g. pbrt/luxrender, mitsuba, ....
> 
> I think the main difference is - that the difference is not known. In the Radiance universe, a lot of work is spent on testing the validity of the models and methods. This allows professionals to rely on the software, as long as they are within the boundaries of the validations. There is a lot of other software capable to solve the global illumination, but few people will rely on it for quantitative studies before they have been validated.
> 
> Another, really important reason that people stick with Radiance regardless what exists "out there" is that for daylight simulation, a good renderer does not help you without the ecosystem of tools making it a useful simulation environment. So to make use of climate data, perform annual simulations, model the often exotic properties of fenestration, and analyze the results, you need more than the ray-tracer.
> 
> Finally, what may appear as an advantage - the quick introduction of new features and state-of-the-art rendering algorithms, can become a serious drawback. The "modular" renderers out there, e.g. Mitsuba, allow to combine different modules. Other, often commcercial renderers, may bring new features with every release (and may not even tell you if something changed). However, if you need to redo all your validations with every combination of such modules, or any change in your implementation, you hardly reach the point where you can make use of the software.
> 
> So while there exist lots of codes to trace light, the motivation of the developers usually is not to ensure valid quantitative simulation for building performance analysis. In fact, most software in this field is based on tuning and adapting good-old radiosity.
> 
> https://www.janwalter.org/RadianceVsYouNameIt/radiance_vs_younameit.html
> 
> This is an impressive coverage of rendering engines! It just lacks the numbers. So while images may look similar, we do not know about quantitative agreement.
> 
> Cheers,
> Lars
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20180129/cb149342/attachment-0001.html>