NOX, Cycles Mitsuba, yafaray (now lux) comparision

@JoseConseco
yes, that fixed it, thankyou.

@Jose, are these render times from cpu or gpu renders?

It’s too early to compare cycles to anything. Nothing in it’s code base is final, as Ton said : ‘Cycles is a design proposal still. During validation & testing, the features and implementation details will be further refined. It’s not a passive “wonder what the devs come up with” but a lot of daily interaction will fine-tune it to a usable system for Blender.’

Its a fair enough comparison as the other two engines are also in a very early development stage. Of the three Nox is the newest, Mitsuba the oldest and Cycles the middle child.

Better you concentrate on ONE good an stable and usable renderer for a professional production pipeline than to code 10 different, unfinished, unusable, experimental renderers at the same time.

Luxrender and Yafaray are the most “adult” and usable Opensource renderers. A Comparison to those renderers would be interesting.

How about Octane (even if it’s commercial but it’s very fast )?

Kind regards
Alain

Development wise Nox may actually be older than cycles.
We honestly don’t know how long they’ve been working on it.
My personal opinion, based on the results of Nox is that it’s
either using some code that someone else had written, or has
been in development for some time now.
It’s also likely to have a larger coding team thus more man hours.

@at wasa not really, path tracers are not so hard to code compared to other rendering systems. that’s why you see so many of them. the are some done in Softimage ICE and using Houdini’s nodes even.

I still cant get mitsuba running ;( :’( it just doesnt render anything. the strange thing is that material editor still renders the preview of the material but when i press f12 the render finishes in 0.4 secs. :confused:

heres a blend, can anybody please check if this works for you? :
http://www.pasteall.org/blend/7757

I would also like to mention my video card doesnt support GLSL. could problem be due this?

Ok - updated first post with Yafa 1.2

wasa - all cpu AMD 3x 710, 2,6Ghz i belive.
Alain - in prefect world there would be renderer with speed of mitsuba, integrated as cycles, and so one.
About Octane - thing is it is GPU so I’m not sure if it’s makes sense to compare. But I can post blend.

mohd.itqan - your scene render ok for me. It seems that preview render ok, so setup is good, but maybe there is problem with exporting collada scene. Does your builid support collada export? Maybe no write permissions for folder in exporter… I think I had same problem, and I just fixed exporter in source code, based on blender console error.
I use those builids:
http://graphicall.org/bat3a
-maybe try change output folder
-I changed mitsuba folder from C:\Mitsuba 0.2.1 to D:\Mitsuba 0.2.1 because of messed up permissions. (dont forget to change mitsuba path in render panel in blender)

I am quite interested in NOX, could anyone point me in the right direction to get it working with blender?

@alain - I think the reason so there are so manydifferent renderers is due to the different jobs they need to do:
BI is fastand flexible but un-photo-realistic
cycles is well integrated and flexible, but rather slow and noisy
luxrender is very realistic, but is even slower and not very versitile. You couldn’t even attempt a toon render with this.
mitsuba is fast, but really serves more as a research renderer than anything else
NOX looks like a faster luxrender with some good features
yafaray looks like a more versitile luxrender, but i’ve never actually used it tbh.
dare i go on?

Actually I think Cycles will be a really fast renderer in the future. Considering that Cycles is still Alpha (or Pre Alpha, or Pre-pre Alpha ;)?) and already gets close to at least Mitsubasa’s speed is a great sign imo.

Cool will check out the update.
Ah ok, I thought that might be the case, but assumed nothing. lol

If you have the time, I know it’s difficult to judge based on image quality comparison when rendering
But I was hoping that you could post a side by side of the unbiased engines at .5, 1, 5 and 10 min renders
I figure this might give us a better idea of overall speed and quality of each.

Thanks for the info you’ve posted thus far.

My mitsuba folder is :“D:\installers\3d\Mitsuba 0.2.1 32bit\Mitsuba 0.2.1”
and im using blender 2.58 (from blender.org). I think its some problem with collada export, i tried exporting a cube to collada and importing it to 3ds max 2009 but it shows some errors (in 3ds max). So I think I need to download some other build or wait for 2.59 :stuck_out_tongue:

@JoseConseco: what are the settings for yafaray? afaik PT had some changes with version 0.1.2 and 20 min for render looks like a not correct render settings, especially for that resolution. With the new changes/optimization in yafaray you don’t need a huge number of Path Samples and adaptive sampling will reduce even more the render time.

condar:
here u go:
http://picoolio.com/photos/medium/36525-d1zcr.jpg

well… try 16 or 32 Path samples, 2 AA samples, 2 Additional samples, threshold 0.003 and 1000 render passes. You can stop the render any time you think the quality is OK but it should be enough 2 or 3 render passes. path-tracing in yafaray 0.1.2 was optimised to use less path samples with same results as older versions. And more important, with shorter render times.

thx :slight_smile:

On the second part, this is the disadvantage of going with a completely physical-based approach, you can get extremely accurate rendering of phenomena like complex dispersion that is difficult for other engines to do real easily, but you can’t do so much in the way of completely unphysical rendering like toon shaders unless you decide to use post-processing to filter the data in the image to a toon look.

On the first part, I believe this is a major reason why the main areas being worked on relating to GI is GPU rendering and SPPM. I’ve been testing the new build with SPPM and I see how I can easily shorten render times of complex images drastically providing you find the right combination of settings (for example not going overboard with photon counts per-pass and setting the decrease of the search radius to not shrink too fast or too slow)

I’ve read the developers say that they felt that BI was showing it’s age when compared to more modern renderers and that they really wanted to start thinking about upgrading to something more modern. Has anyone heard any news on how that is going? Any idea when we’ll get a very modernized, fast, realistic Blender Internal? In Blender 2.6? Or what? I suppose some of the GSOC work could be helping to bring such a thing about. Some of the ideas those guys have are pretty interesting, and will be very useful, when the bugs get worked out. I’m especially interested in Pepper with the new mocap stuff (but it’s still buggy, especially when you try it with makehumans.)
But I haven’t really heard anything out of GSOC that focuses specifically on the BI renderer and modernizing it. Anyone have any thoughts? I’d hate to have to break down and pay for Octane after I pay for a new graphics card, although it does make some pretty stuff…
I fool around with external sometimes (just spent a few hours pulling my hair with Mitsuba, and my only real success (besides just rendering the CBox.zip that came with the download) was getting a very dim default cube out of the thing.) but I’m getting tired of being a pre-alpha release crash-test lab hamster…

condar - ok updated first post -> less time but more noise. Render time/quality goes somewhere behind mitsuba, close to cycles I think. Bit hard to tell.

That still seems a surprisingly long time for Yafaray. Unless the objects are extremely polygon heavy, I would expect times closer to two or three minutes for a scene like that. Obviously I am estimating for my own system here (2.8 quad core).

Any chance you could share the scene so I can try it?