Indigo Vs. Yafray

Hi. Can someone with experience in rendering with indigo answer if the quality of the Indigo output render is better than yafray’s and if it isn’t a waste to wait 12 hours for a good renderer of a mid complex scene

Oh well…Indigo has a totally different concept than Yafray. Comparing them in the way you do is not really the way you should.

Indigo is an unbiased render engine - its algorithms are slow but yield excellent results even with simple setups. But if you’re going for something non-photorealistic, you will most like have to forget about it…
Yafray on the other hand is biased. You can have very “fast” (well, GI is slow to start with…let’s say at least faster than with Indigo at a comparable noise quality) renders but they might require some tweaking.

But you can’t say Indigo is better than Yafray or the other way round. You simply can’t. But yes, if you ask me, for photorealism you might achieve better results with Indigo due to the easy setup. That might even compensate the time you spend for experiemnting and setting up Yafray properly, if you’re not a little bit experienced.
I’d take Yafray since I do think that I know a little about it already and have sufficient knowledge to get good results with it in less time than with Indigo, Nevertheless I’m surely going to try it someday, just to see the possibilites. That’s what you should do, too…try them out and see which concept you like better.

Thanks a lot for the explanation. Well i guess i will play with them a bit.I used yafray until now but indigo seemed .like u said,to give more photorealistic results but waiting 2 hours for a 32 segment sphere to render without to much noise was a bit discouraging at first.

somebody help me!!! Indigo has started to render a simple scene 2 hours ago and seems like it will never stop.I could have rendered this scene in a few minutes with yafray.

It won’t stop. That’s what unbiased means.

when comparing render engines, you should take into account not only lighting accuracy but flexibility and shading capabilities. Scanline and renderman-based render engines are much more flexible than raytracers (apart from faster), and have got powerful and imaginative shading capabilities, therefore are more used in animation.

that’s why I think that yafray should get more and more flexible with a more robust node-based and programmable shading system, better integration in blender compositing nodes, further improvement of photonmapping and new photons-based features such as volume caustics, smoke, SSS, and new and faster biased algorithms. Besides, flexibility in render engines means that it is easier to find workarounds when problems arise IMO.

Notice that this opinion is not shared for everyone in the Yafray comunity: many users/depelopers would like yafray to have got unbiased render capabilities. In my opinion, the more unbiased it gets, the more flexibility you lose. Probably this is one of the things that it is slowing yafray development now.

In my opinion, the more biased it gets, the more flexibility you lose.
Don’t you mean the more unbiased it gets, the more flexibility you lose (based on what you said above that).

Personally, I disagree. Yafray wasn’t written to use a flexible shader system like Renderman shader language so Yafray isn’t really a good choice for the things you recommend. Remember…it is a raytracer. Anyway, in practical terms yafray development has all but halted.

Indigo is what yafray aspired to be - used to make photorealistic images. Yafray is of course faster but biased with a lot more settings needed to make a good looking scene. So here is my breakdown of renderers to use with Blender…

  • Indigo. If you want photorealism use this. Few settings, beautiful images and long render times. Think of it as a light simulator. Quick previewing but slow final rendering. Awesome.

  • Yafray. Still too slow for animation work but faster than indigo if you want to play around with lots of settings. Not as good as indigo qualitywise. Better integration into Blender but development has almost come to a halt (sadly).

  • Aqsis/Pixie. Here is the shader flexibility you were talking about (again requires effort). Good for artistic stuff and faster than the two above choices.

  • Blender internal. Very fast and the best for a middle road approach. Easiest to use with Blender (obviously!).

  • Freestyle. Lightning fast NPR renderer with fantastic shader support for stills. Works on the edges of a model and not on the shading inside.

So that is it!

Koba

Yafray wasn’t written to use a flexible shader system like Renderman shader language so Yafray isn’t really a good choice for the things you recommend

AFAIK other biased raytracers are using programmable shaders and multipass rendering. I find these features very interesting, much more that unbiased raytracing. For the same reasons, I find interesting when yafray is used to enhance Blender renders, or when people use it for organic models.

Besides, with the photonmap technique you can do intesting things that are not possible with an unbiased render, although those things are not implemented in yafray yet.

BTW, just for the record, there is a person working in the yafray code (pretty much like in Indigo).

AFAIK other biased raytracers are using programmable shaders and multipass rendering.

Agreed. It is just that historically yafray hasn’t been used/developed for such techniques. Of course with a complete rewrite and lots of development, it could go that way.

BTW, just for the record, there is a person working in the yafray code, pretty much like in Indigo.

That is also true. If only Lynx were as insanely productive as Ono is with indigo then I would still be as enthusiastic about yafray as I once was.

I have seen six versions of indigo - each a big step forward - in the same time that yafray has barely managed one release (and that was mainly bug fixes).

Koba

Koba, my opinion is not a criticism against Indigo, what I’ve said that the more unbiased it gets, the more flexibility you lose, can be applied to YafRay too.

Although you might get more quality with yafray, the flexibility of the Blender internal (multipass rendering, zbuffer cheating, composition nodes, etc) makes it a better option in lots of cases.

So the quality of a render engine is, in certain aspects, a relative question IMO.

Yafray is open-source, Indigo is not.

I think this matters in long run. If Indigo developer stop developing Indigo, then it really is dead-end. WIth Yafray fresh forces can join anytime.

Yafray is open-source, Indigo is not.
From what I understand, the option of an open source version of indigo is still there.
In this particular case it make sense to keep it closed source for a while…Ono is coding at a fantastic rate and indigo remains (and always will remain) free. Keeping it closed source for now means the development can be more focused.

I am confident that when Ono will open-source when the time is right (probably when he can no longer contribute to the same extent). Yafray, while open source was maintained by a small team for a long time but when that ceased it took a very long time for someone else to try and pick it up (lynx).

My point is that a raytracer is a very complicated piece of software and open source don’t mean guaranteed development (unless it is a big project). Blender is unique in that sense…it is a complicated piece of code but luckily it has attained a critical mass (in terms of recognition and user base) when there will always been developers willing to pick up the code and move forward. For open source raytracers this is often not the case…the projects simply die. Sad but true.

So fresh forces can join anytime but they better be very, very dedicated fresh forces. :wink:

Koba

Well, I have mixed opinions about that. For instance, there are great render engines which are open source that are more or less dead, like Radiance.

The key to success for YafRay has been the Blender comunity and the fact that YafRay developers wanted to integrate YafRay into Blender, which nobody else did at that time. I mean, PovRay developers could have got interested in an integration with Blender, but only the YafRay guys did so. At that time, Blender was not as succesful as it is nowadays. YafRay was in the right place at the right time. Besides, it was a LGPL software, which made things easier and clearer for the integration I suppose.

The future of YafRay not depends on its license, but on the people committed to the GNU GPL software. I mean, YafRay is the most succesful GNU GPL raytracer to date. If we lose YafRay, there won’t be a substitute for a long time IMO.

Besides, the only pressure free but closed-source renderers like Indigo or Kerkythea have got to take the open source path is the mere existence of YafRay and its support in this comunity.

I am confident that when Ono will open-source when the time is right (probably when he can no longer contribute to the same extent)

I don’t think so. Indigo developer won’t release the sources unless the project itself is exhausted IMO. I hope I’m wrong though.

Usually, propietary software takes the open source path because of a very powerful reason. In the Blender case, it was the NAN bankrupt. In the Radiance case, it was pretty much dead when they decided to do so AFAIK.

GNU GPL open source is not a matter of convenience, you license GNU from the beginning because you have got moral motivations to do so, or as a last chance to survive.

That would be fantastic.

My point is that a raytracer is a very complicated piece of software and open source don’t mean guaranteed development (unless it is a big project).

So fresh forces can join anytime but they better be very, very dedicated fresh forces. :wink:

I agree. But, for example, I could try to make a native Linux version of Indigo if I had the source. I don’t have to know how it works, it is just matter of following compiler errors and that sort of stuff.

But still, I’m glad that we have multiple choises :o