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

Tue Jan 30 08:50:55 PST 2018

On Tue, Jan 30, 2018 at 2:56 AM, Jan Walter <jdb.walter at gmail.com> wrote:

> Hi,
>
> nice that someone still stumbles upon my images and render comparisons ;-)
>

Thanks for this, Jan (and thanks to Dion for starting this thread)!

This question comes up regularly. Since I work with energy modelers a lot,
I'm often asked "why don't you 'just' use (renderer_x) instead of Radiance,
everyone in architecture uses Revit, everyone uses GPUs and Revit and (all
the Rays) to make these awesome images, Radiance is all blotchy and takes
forever, and besides, my energy model runs in five minutes for an annual
simulation with 15-minite timesteps, blah blah blah..."

It's so refreshing to see someone who gets it. The validation issue is
huge, and we all owe a debt of gratitude to John Mardaljevec for the
initial validation of Radiance, but the whole small community of dedicated
users of Radiance also get to take a bow for rolling up their sleeves and
learning how Radiance and GI work. And the reason I rolled up my sleeves is
because I saw Radiance as one of a fery few tools out there that offered
realistic images but also the photometric truth. There is no money in this,
unfortunately, and it speaks to a larger issue in BOTH the architecture AND
the illumination engineering industries, but I digress.

Greg's account of the demise of Lightscape is even more generous that what
actually happened. When Autodesk bought Lightscape from Discreet Logic (the
original purchasers of Lightscape from the founders), it was immediately
absorbed into their "3DStudio Viz" product, aimed at architects wanting to
make nice pictures while being able to say their images are "correct",
"accurate", etc. Well, the first beta of Viz included Lightscape's
renderer, but the render-as-falsecolor option was unceremoniously removed.
This was the first thing I noticed, since I actually used Lightscape as an
illumination engineering tool. I (and others on the beta test team) brought
this up, and the falsecolor option was added by the next release candidate.
This one provided falsecolor images, but _with no scale legend_. Useless.
For me, the writing was on the wall, even before version 1.0 of 3DS Viz
with "Lightscape Inside" ever saw the light of day. I think Lightscape's
awesome radiosity renderer lasted one year in the Autodesk Death Star.

In the US, Agi32 soldiers on as an excellent, primarily radiosity-based
lighting simulation tool. But it definitely lacks the portability and
modularity that Roland alluded to, and while validated, it also is closed
source. But it's far better than the soup of renderers that Jan has
compared for us, if you're interested in, let's call it, photometric
verisimilitude.

Jan, your efforts are awesome, and I thank you for them. I'm not sure how
much Carsten Bauer follows this list any more, but he did port Radiance to
C++ (in an attempt to better learn C++), in his "Radzilla" project. Similar
to your PBRT-to-Rust effort.

The last thing I wanted to mention in all of this is that while Radiance IS
validated, all that demonstrated is that Greg's raytracing implementation
CAN work, and give accurate, credible results. But every model is an
opportunity for the simulationist to screw that all up with garbage for
input, or garbage for simulation parameters. And again, it's the
simulationist who questions the results who is drawn to Radiance in the
first place. That's why this community is so amazing.

- Rob

> > I also stumbled upon this comparison website:
> > https://www.janwalter.org/RadianceVsYouNameIt/radiance_vs_younameit.html
>
> To compare renderers is a really time consuming task and each renderer
> is changing
> over time, so one picture rendered today might look different in a 1/2
> years time.
> And to really be able to compare those renderers with some confidence
> you must know
> about all their parameters etc. A task which I like to spend my time
> on, but still after all
> those years doing it, I don't want to publish too many details, but
> rather make people
> download some files, install renderers and try for themselves.
>
> But here are some thoughts:
>
> - Radiance did have a huge impact on other renderers (and that we have
> HDR and OpenEXR).
>   That's why I called that comparison somewhat ironically Radiance vs.
> YouNameIt. Some people
>    got all the fame, but me and some others are old enough to remember
> where things came from ...
> - Other things which slowely made it into other renderers: Sun & sky
> simulations, suddenly with HDR
>   you could end up with over- or underexposed images -> exposure
> control -> camera controls/settings
>   which mimick real cameras etc. In the film world you had LUTs, now
> everybody somehow/somewhat
>   deals with color correction. All of this makes it hard to end up
> with a "similar" image.
> - Sure, other renderers are more user friendly, and there is/was some
> money to make. I would say
>    that integration into a DCC tool is sometimes more important for
> the success of a renderer than
>    the quality of the resulting images. For my tests I was using
> Blender (most of the time):
>    https://bitbucket.org/wahn/blender-add-ons (the io_scene_multi
> contains Python scripts for
>    Arnold, Indigo, Luxrender/PBRT, mental ray, Maxwell, Radiance, and
> RenderMan compliant).
>    None of this is production ready, I add only things I need
> personally to do the next step and render
>    the next comparison images ... and Blender has Cycles now, which
> changes a lot:
>    https://www.cycles-renderer.org/
> - I started to collect Blender scenes (and scene descriptions for
> various renderers) here:
>   https://github.com/wahn/export_multi ... as you may notice some of
> those scenes come from
>   Radiance. I had to write an importer first, parse Radiance files,
> store them in some renderer
>   independent format which does not loose the provided information,
> bring that into Blender and find
>   tricks to e.g. keep primitives like spheres as those in case the
> renderer in question can handle those
>   directly. Use someheuristics to mimic material settings etc. ...
> - After a while the git repository got too big, the files too large,
> the scenes/textures too big/many ...
>   So now I provide download links for scenes in various formats:
> https://www.janwalter.org/download/
>   All of them originate from a Blender scene, but I update them from
> time to time and all of this is meant
>   to make it easier for somebody else to just download the files for a
> particular renderer without having
>   to deal with Blender etc.
> - Finally I started converting PBRT's C++ code to Rust (
> https://www.rust-lang.org/en-US/ ) as a
>   learning experience. Maybe someone wants to do that for Radiance one
> day. Rust seems to be a fun language
>   with safe multi-threading etc. Here is the current state (and a bit
> of history about last year's development):
>   https://www.janwalter.org/jekyll/review/2017/2018/01/01/
> happy-new-year-2018.html
>
> Anyway, comparing renderers is really hard. Radiance is about being
> accurate, others might look good and might be easier to play with. My
> interest is in using Radiance (and others) for reference and try to
> create similar looking images. Compare rendering times etc. An ever
> changing world ... Here I was playing with false colors etc.:
> https://www.janwalter.org/jekyll/rendering/radiance/
> 2015/10/02/classroom-radiance_falsecolor.html
> But I'm not an expert user of Radiance. Most of the people on this
> list know much more about it.
>
> I just wanted to give Radiance some credit for all the things which
> made it into other renderers.
>
> My 2 cents,
>
> Jan
>
> On Mon, Jan 29, 2018 at 8:52 AM, Dion Moult <dion at thinkmoult.com> wrote:
> > Good morning all,
> >
> > Apologies if a thread like this already existed, but after searching the
> > archives I could not find it.
> >
> > I am looking for a modern-day explanation as to what Radiance offers
> that other
> > popular rendering engines (Renderman, Cycles, V-Ray, etc) do not. These
> all seem
> > to use ray-tracing, solve the global illumination problem, use physical
> units
> > (albeit sometimes not very obviously, and sometimes require a conversion
> > factor), I see hints of illumination falsecolours out there, and can
> output
> > unclipped HDRIs as final results... as you can see, at first glance to an
> > inexperienced person it really does seem that these other rendering
> engines are
> > indeed also physically based and can also give the same scientifically
> accurate
> > output that Radiance can (also perhaps not as easily parsable as Radiance
> > results). (Assuming that the user doesn't purposely use biased rendering
> > techniques)
> >
> > There seem to be features such as human eye image calibration, or
> falsecolours
> > that are rarer to be found in other engines, but slowly I am seeing
> mentions of
> > these features emerging.
> >
> > I also stumbled upon this comparison website:
> >
> > https://www.janwalter.org/RadianceVsYouNameIt/radiance_vs_younameit.html
> >
> > In that website, it is not obvious how the material and light properties
> were
> > converted for each engine, but in short, the graphical outputs look the
> same.
> >
> > I hope that someone on this list can help explain to me in simpler terms
> what I
> > am overlooking :)
> >
> > --
> > Dion Moult
> >
> > _______________________________________________
> > Radiance-general mailing list
> > Radiance-general at radiance-online.org
> > https://www.radiance-online.org/mailman/listinfo/radiance-general
> >
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> https://www.radiance-online.org/mailman/listinfo/radiance-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20180130/e1370091/attachment-0001.html>