Call for supporting yafaray !!!!

hello everybody!
For those who don’t know, YAF(a)ray is a free rendering software developed by enthusiasts in their spare time. Known before as Yafray, it shoulders Blender as an external GI engine for many years and has allowed many designers to produce photorealistic renderings. Often cited for its ease of use and speed, it remains today one of the only free solutions face to Vray, TheaRender, MentalRay, etc. … (There is also Aqsis, PovRay, Kerkythea, Sunflow, Mitsuba … but for most, development is stopped). Yafaray is also compatible with Sketchup, wings3d, XSI (3dsMax & Maya will follow later).
Today Yafaray is focused on the version of Blender 2.62 with new features such as SPPM, IES lights,… this version is more focused on the adaptation of the exporter. It is planned in the roadmap full support particles, accelerated by the GPU, the Irrandiance Cache, … and others. That’s why a code sprint is planned, funded by donations, to fix bugs and speed up development.
Yafaray truly deserves to be supported by its history, its existence as any other creative and free project.

Good call.
It says the sprint will begin second half of 2012. Is there any deadline for supporting?
I ask as I have little money this month but will save some for next.
Good luck!

Yafaray is fantastic, donated $100

Going to donate very soon.

I haven’t played with Yafaray for a long time, until yesterday, and it’s looking very awesome (Try out the 2.62 add-on!!)

I believe there is / was an issue with the API’s between Blender & Yafaray in that it’s not possible to make use of Yafaray’s nodal materials, I really, really hope this can get worked out as the rendering options, speed, and quality of yafaray looks like it really can go toe-to-toe with some of the bigger commercial rendering engines out there!

Imagine you say to Brecht to stop with Cycles and take a look to help the integration of Yafaray with Blender. What you have is a program (Blender) that creates an incredible output with Yafaray and you can do Mango or whatever rendering with it and using many features Cycles at the moment lacks. After such an integration then Brecht can go back to Cycles again. Users would be incredible pleased, Mango would be done and in some months Cycles would be end. All people with smiles.

But what is happening instead now: you have now Yafaray people don’t smiling because they don’t have the integration they want with blender (they need help from Brecht or Campbell as I see it), Mango with some doubts if it will be able to use Cycles because scene memory use (that could be solved using Yafaray and the Jukacluster (name?) they have, and Brecht stressed trying to code that beast (that yet lacks so important things as: anysotropy, SSS, hair…etc…etc…).

But well, I have not tried Yafaray myself. And perhaps Cycles is much faster for the scenes that are needed in Mango?.

What a lovely idea; dreaming is such fun :slight_smile:

There is some work being done on a standalone shader editor for Yafaray. No one is making any promises about its future, but it is an exciting development.
http://www.yafaray.org/community/forum/viewtopic.php?f=16&t=4596

I’d prefer to see these people helping Brecht to develop Cycles and not the inverse, why having a lot of external open source renderers but incomplete or poorly integrated, instead of a fully functional, flexible, speedy and production ready Blender renderer…?

I don’t really get it. Right now every week a new path tracer appears but no new coders helping for Cycles (few non-official guys excluded). It’s really sad

The shader editor looks quite good, thanks for pointing it out :slight_smile:

I’m not too sure how the material / shader system works, but in my eyes if it could write out materials into XML files, which could be loaded into Blender, Maya etcetera as a Yafaray XML shader then that’d be such an awesome thing. Being able to perfectly match materials between all of the supported applications.

I won’t get into the whole Blender Foundation developers / external engine developers conversation as it’s not something I know an awful lot about, I do hope it can be resolved though. Perhaps having a few words with Ton, and mentioning the use of Yafaray, or an external engine during Mango for specific tasks may allow the developers a little time to look at it from the other direction i.e. What is really hampering mixing Blender & external applications in a production environment.

Anyway, I shall donate and I hope that you guys can meet the target!

Yeah, and V-Ray should be banned and the Blender Foundation should buy Autodesk :smiley:

I’ll try to help, Yaf(a)ray is worth it.

Yafaray is already coded and they asked for a good integration with blender (an API so they can call their functions and interact with blender to read scene meshes, materials, nodes…). It would be great such integration is done and then you have the yafaray guys happy, a lot of users that use yafaray happy too, and then other render engines like luxrender (the one I like the most) would be happy too because the API would be working and they would be using it too.

Then Mango could be be rendered using the already coded yafaray that now would be using a great fast and correct API. Mango would be rendered in the justacluster using CPU.

Instead we have:

  • Yafaray saying they need the API
  • Luxrender guys the same
  • Cycles not coded yet
  • Mango probably to be rendered in the justacluster because probably scenes will be too big for GPU cards.
  • Brecht stressed trying to add the lot of features that Cycles lacks yet.

I certainly would love things like luxrender or yafaray interact with blender and be able to work the way Cycles does with nodes and compositing. That is the API the other renderers programmers want.
And I would love Mango rendered in Yafaray or luxrender in other future project (until Cycles can do everything this renderers can, and that will be months or years ahead yet).

What is sad, is that people think Blender’s artists now only need Cycles to make GI renderings. Cycles is not the only way to produce photorealistic renders, developing several external solutions for artist, help to find new process of calculation ( look at Mitsuba). It’s like to say: " Why developing electric cars, when you have already petrol motor cars".
Cycles is very impressive regarding its youth ( I like it too !), and will be a powerfull integrated solution. But for now it is limited and requires a good/expansive graphic card to be fully appreciated, and not everybody doesn’ t want/have to render with an unbiased engine ( Yafaray is “hybrid”, it has got Photon Mapping for biased solution, unbiased are PathTracing and Bidirectional-PathTracing). I’m not asking developers to help Yafa dropping Brecht and Cycles, but helping Yafa with some donations and mainly by having interest. Don’t worry about Cycles, it will be “finished” a day, maybe sooner than we expect, with the help from some external developpers.

Poor integration is a consequence of blender making it hard to integrate properly. Why should the authors of yafaray suddenly work on cycles? Yafaray has been around for much longer, and it doesn’t just target blender. Cycles is designed for blender. Also, cycles is written in a very gpu-oriented style and isn’t well documented. If you enjoy working on a nice,flexible C++ codebase, you probably won’t enjoy working on Cycles. And why should you do work for free that you don’t enjoy? So you get the gratitude of us dicks on BA? :wink:

It does not seem like the progressbar is updating?

I’m not saying Yafaray shouldn’t exists guys, I really like and admire their work. My point was only concerning about lot of coders who spend their time with limited renderers who will disappear in a while, instead of supporting doable projects such as Cycles. Plus you can even work on specifical features on cycles and ask for donations if you don’t want to work for free, the community would help you. I would donate too for a coder working independetly i.e. on SSS, fur, displacement…

It was not intended to say “stop Yafa and go Cycles”…

Then you completely miss the point of the Open Movies. They are about improving Blender, not external engines etc.

Are you serious? " limited renderers who will disappear in a while" ???

To be fair, Yafaray and Luxrender exist for quite a few years, long before Cycles was born. So saying that the developers of these applications should now all come to Cycles and abandon their own project is…well I am in a loss of words here.

DingTo, that’s exactly what i was trying to explain, I’m not referring to Yafa or Lux of course, but other small renderers who appears on the web and then disappear…i know i can’t speak english very well but i thought it was quite easy to understand.

Ah I see, sorry for the misunderstanding.

Well I agree, but on the other hand I can imagine it’s quite some fun to write your own engine. :slight_smile:

OK MarcoG_ita, no problem ! :wink:
But this topic is not for Cycles ( there’s so many others), it’s for Yafa. And I’m not asking for donations because " we don’t work for free", but for the " code sprint", to fund it and pay for accommodation and travel of coders. Cycles is only for Blender, Yafa goes to be compatible with some major 3d solutions. And it’s a good way too, for students ( for example) to learn programing.

_“Then you completely miss the point of the Open Movies. They are about improving Blender, not external engines etc.”

DingTo has right, do not confuse things :slight_smile: But somewhere, it should be cool if a project like Mango is rendered by Lux or Yafa :wink: