One mistate I found in the table at page 54: Cinema 4D is said to not support "color bleeding".

While this is true for the standard Whitted-style raytracer included in the $995 base package, it isn't true for the $3695 "Studio bundle" which is listed in the table. This includes the "Advanced Render 3" module which provides "color bleeding", caustics, SSS, AO, HDR image based lighting, etc.

I guess the term "color bleeding" means at least generic LD*E or LD*S*E light paths. It's in C4D since Release 7 XL and in the AR module since full modularisation with R8.

In the same table is said, that C4D does not provide tonemapping. But C4D has standard RGB gain/gamma tonemapping sliders in the picture viewer and a Reinhard-like tonemapping filter with less color clipping.

What's also strange about this comparison table is the randomly chosen features in "other key features". What is so special about modo's fresnel and anisotropic shaders? C4D had fresnel back in V1.5 or V2 in the early nineties on the Amiga. Schlick's fresnel approximation is about 3-5 lines of code. It's tought every student in every basic 3D image synthesis course.

Anisotropic shaders where included in C4D since SLA was integrated in XL 7.3 (around 2002?)

What's so special about "true multi-threading" in C4D. Is modo or anyone else doing "fake multi-threading"? Multithreading ray tracing is trivial, so I guess every ray tracing based renderer is doing it right. More complicated is multi-threaded setup work like construction of acceleration structures (kd-tree, etc.) or rendering (depth) shadow maps, etc.

What is special about audio synch in Blender? C4D had animated audio objects (with 3D position for shift/doppler effect) since Release 6 in 2000.

Why is spectral rendering emphasized in Indigo, but not in Fry or Maxwell. Even the RenderMan standard isn't tied to RGB color space (also I don't know if any "RenderMan compliant" renderer really support's optional color spaces with more components, and if so, you surely have to write your own spectral material and light source shaders and imagers to use it).

This comparison table is full of random "special features" which seam to come from marketing buzzword talk. The interviews with users of some renderers are also quite useless. What do you expect to tell you? No-one will say: "We are very unhappy with our render solution but to thick to evaluate alternatives. So we stick with what we are used to, also we think it's total crap."

Well they stick with what is "good enough" to get their jobs done. Or what everyone in their industry uses. "No-one ever get fired for buying IBM" is an old saying in the IT industry. Switch "IBM" to "PRman","V-Ray" oder "mental ray" and it fits for DCC.

What we really need is no biz and marketing talk about where someone talks about his prefered renderer beeing up to the task. What we really need is a reliable qualitative and quantitative evaluation of different rendering technologies.

And what is the use of all this demo pictures?
Every renderer can do great pictures in the right hands with enough artistic competence and enough effort. Well, great artists can even do great pictures in MS Paint by setting pixel by pixel using nothing but the most basic drawing tools....

People did great 3D renderings with POV-Ray *) in the rendering stone-age. (* or LW 3 on Amiga, or 3D Studio 4 on DOS, etc.)

This is my recommendation how to do a more scientifically valid comparison of physically rendering (for full GI):

One must provide some users/render artists - which have to be top notch with their renderer of choice - with a pile of standard scenes and ask them to set up one good & fast preview and one slower production quality rendering. Then (at least for photorealistic physically based rendering) one has to do a reference picture with path tracing and >10000 paths per pixel (maybe 100000 or 1M paths per pixel for complicated lighting or materials, just get it nearly noise free with sensible standard tonemapping).

You have to account for:
- setup time by this experienced ("power-") user
- pure render times for preview/production *)
- render qualitys compared to the reference

*) for progressive rendering there has to be specified noise levels compared to the basic path-tracing reference solution

You need to do a scene mix of different illumination situations (sun/sky, more indirect/interior, lots of small lights, big mesh lights, etc.) and material mix (pure diffuse, lot reflection/refraction, lots of glossy, anisotropic...)

Tonemapping should not be judged, export pure RGBA16f HDR data as OpenEXR. Tonemapping is a post process that has nothing to do with the pure rendering algorithm. Compare the HDR results.

Also camera should be simple pinhole. No DOF, motion blur, etc. No layers. Just the pure GI rendering capabilities.

Physical cameras with DOF, blur, layered output or non-photorealistic rendering could by a different test...

Posted by Paul Schröder (127.0.0.1) on January 17, 2010 at 12:39 PM GMT #

RESPONSE TO BLOG COMMENT

Hi Paul

I compiled the comparison table by sending out a standard spreadsheet to all of the developers, so that is actually the information that Maxon themselves provided.

The 'Other key features' section is there because the main body of the table is only a small subset of the feature list for each of the renderers -- a really comprehensive listing would have been impossibly unwieldy in print.

Rather than gloss over the fact that each package has other features, I wanted to give each developer the opportunity to comment on what they felt I'd omitted: so again, that information is developer-submitted.

I agree that the results are rather oddly assorted, but I think that which features each company chooses to promote - and which ones it doesn't - does give some kind of insight into the way it regards its products.

The user comments are completely independent of the developers, but they are, inevitably, only one person's opinion.

Again, I agree that some kind of comparative test would be preferable, but the logistics of developing a set of standard test scenes that would be meaningful for a set of renderers that ranges from RenderMan to Turtle is really beyond the scope of an eight-page magazine article.

I'd also say that you'd have to be careful about what you can actually quantify in a test of that type. There is usually more than one way to achieve a particular result, which makes set-up times open to debate; and trying to assess render quality in comparison to a reference image is inherently subjective.

I do think that quantitative tests are valuable, but sometimes, I think the fact that you have put a number on something gives the impression of greater objectivity than you can actually deliver.

Posted by Jim Thacker (127.0.0.1) on January 19, 2010 at 04:57 PM GMT #

Thank you Mr. Thacker for the in-depth reply and the explanation of this strange mix of "special features" in the comparison table.

It's funny that Maxon marketing stuff doesn't know about basic GI capabilities of the Advanced Render module. Even more so as this module was vastly improved in recent updates (R11 and R11.5). Maybe the C4D devs should tell the marketing people what "color bleeding" means.

Well they call it "Radiosity" also it is some irradiance cached ray tracing.

But I still would prefer at least one test scene rendered by all of the renderers in the print edition of the article. German C4D forum c4d-treff.de is just discussing the issue of usefull GI test scenes. The only one I know of (beside aged Cornell Box) is the WinOSI GI renderer comparison - and it is also quite dated:

http://www.winosi.onlinehome.de/Gallery_t14_01.htm

With kind regards

Paul Schröder

Posted by Paul Schroeder (127.0.0.1) on January 19, 2010 at 10:56 PM GMT #