Yafaray Code Sprint 2012

Hi All.
Just a bump to remind everyone (in these times of conferences) that the Yafaray team has put together what seems to be a very good opportunity for developers (or aspiring ones) without an aim.

The team is planning to host a Coding Sprint to help get new developers introduced to the Fafaray code and to get familiar developers of Yafaray a motivational boost.

The outline of the arrangement is very well described at the provided link:

http://www.yafaray.org/community/forum/viewtopic.php?f=15&t=4537

and if anybody with the skills to help the Yafaray team needs a reason to do so, just take a look at this page:
http://www.yafaray.org/gallery?g2_itemId=4204
and this:
http://www.yafaray.org/gallery?g2_itemId=4356
and:
http://www.yafaray.org/gallery?g2_itemId=4388
and
http://www.yafaray.org/gallery?g2_itemId=4304
the list goes on:
http://www.yafaray.org/gallery?g2_itemId=39

Good luck to the team and I hope to see some feedback from it!

ah i wish i was a programmer right now! i just got back into using Yafaray and i’m finding that with the right optimizations, it’s actually a pretty impressive renderer… i hope people get involved, 'cause i’d love to see it move forward!

While Yafaray may have some good things, previous readings of Yafaray and rendering threads gives me the impression that the project leader (known as Alvaro on this forum), almost seems to get angry when he sees another render engine project pop up or when he sees a post of someone saying they bought an engine like Vray (in which the money could’ve be used as a donation to the Yafaray project instead).

Personally, the tone of his posts back then (in terms of how it sounded to me) was a major reason I couldn’t see myself backing the Yafaray project, but now I’ve spoiled myself on the nodal-based workflow that came with Cycles and I couldn’t see myself switching for the long term unless they were able to put together a similar system (which as far as I’m aware is still a work in progress and on top of that we might need to poke Lukas Tonne some more to finish his custom nodes work).

Thanks for the publicity ejnaren, and thanks for your words ohsnapitsjoel. YafaRay users is one of the reason we keep on working on this project, at least for me it is the main reason right now.

It is possible that we will publish a more complete program of the event and them I will publish it here on Blenderartists. The University of Mostoles is going to collaborate with us and it is possible that we can prepare one-day free workshop, with help from at least two YafaRay Gurus. Olivier Boscornou ( http://www.olivier-boscournu.com/ ) will be one of them and we are looking for a second guru especialised in cooking YafaRay renders in the Blender compositor. We will inform people about available seats for the event as soon as we have more information.

PD: Ace Dragon, I don’t believe for a second you have ever been genuinely interested in the YafaRay project. It is a lie. I sometimes doubt whether you’re interested in 3D at all. One of the problems we face in free open source communities is people like you, making too much noise and too little actual work. You have many threads going on to talk about how wonderful Cycles is. This thread is about YafaRay, if you have something nice or constructive to say about it, then you’re welcome.

Okay, so maybe I got a bit too personal in my last post, the main thing I was trying to say is that the defenses I’ve seen over the years on behalf of Yafaray, to me, seemed to be more in the lines of being a bit aggressive than something that simply made an assertive and clear-cut case for the project. I’m not arguing over the fact that it can indeed produce some great results, I’m not arguing over the fact that it is the engine of choice for many people, I’m just saying, as written in the first part, that there could’ve been ways that would’ve made the Yafaray initiative more inviting to a larger set of users.

We don’t put ut with the ‘entitlement’ attitude so many people show up on these forums,
and I personally don’t put up with misinformation and hype. People with much more work done than you (well that’s not difficult) show appreciation or at least a respecful silence about what we do, why shoud I care about your opinion?

Ace Dragon, I think you’re getting way too caught up in politics. Why is what anyone says at all relevant, aggressive, defensive or not? It’s either a good fit for your project or it isn’t, and you make that decision based on technical aspects, on a per-project basis. Yafaray is an excellent piece of engineering and a particularly good fit for archiviz applications (where cycles is pretty inefficient for interiors by the way). You are not married to one renderer, so all that talk of ‘switching’ just doesn’t make a lot of sense. You should be thankful the Yafaray team is making it available to you, with all its source code, for free. Instead you’re, what, gossiping about them? Really? I don’t even know what to say to that. :frowning:

I’d love to see Yafaray get some real development, it’s a super capable renderer, as you can tell from the gallery images. I personally hope some day this can be a replacement of sorts for BI. It’s especially useful for animation which is something unfortunately Cycles doesn’t excel at IMHO. Best of luck with the code sprint!

I encourage everyone to take another look at Yafaray if you haven’t touched it for a while. The current add on plugs in easily to the latest version of Blender just like in 2.4x days.

Wow. http://www.olivier-boscournu.com/ actually made half the projects I listed in the examples… I am an architect and he is truly inspiring… I will have to research more of his work…

Apart from that, this thread is NOT going to be a pro/con Cycles vs Luxrender vs Yafaray vs Mitsuba vs Appleseed vs etc post!
Each has its own strengths and weaknesses. Capital on weaknesses. Rendering is faking the truth. That is where the art steps into the picture. Where one artist lies his work another another steps beside.

This thread is meant to push everybody who feel they can help with the render engine that produced fore mentioned pictures.
Remember the spirit behind open source is that we learn from each other by communicating freely between each other.

without intending any offense at all, i think you’ve actually done this quite a bit on the forums. just as an aside here, i’m pretty interested in new GI renderers and new development on old or dead ones, so i follow a lot of BA threads about various renderers. i have to say that i’ve seen you say about several render engines that the effort being put into them would be better spent on helping the Blender Foundation develop Cycles. just my two cents, if it’s worth two cents - take care not to have a double standard. people are interested in what they’re interested in when it comes to render engines, i’m not sure there should BE much discussion about why to like one more than another. and like MadMinstrel said, there’s a time and a place for each of them.

maybe this is a moot discussion though…

anyways, back on topic, what kind of developments can be expected from the coding sprint??

Sounds great, are there any specific features or improvements that you have planned to get working during the sprint?

Admittedly I haven’t used Yafaray as much as I’d like to, I am always astounded by what Yafaray can do but I don’t have a clue how to use it correctly :stuck_out_tongue:

haha me neither. i’ll bet some general docs about how to optimize render settings for speed would draw some people in.

A few version back there was a custom build of Blender with Yafaray that utilized GPU accelerated Photon mapping, I think it was a summer of code project. Are there any plans to do more work on this?

I must say, I wish I have used Yafaray more as well… I always get the Graphicall builds with Yafaray and Lux, as I love caustics! (Photon Caustics ftw!!!)

I’m always interested in Yafaray, and looking forward to improvements and new features :slight_smile: Keep up the great work :slight_smile:

Funny thing - a lot of people say they won’t use Yaf(a)ray anymore because of lack of GPU support. So they choose Cycles that renders interiors with a graphic card even longer than Yaf(a)ray!

I keep my fingers crossed for this sprint. I love Yaf(a)ray and in my opinion its calculations look way better than the ones provided by Cycles. I don’t know why but Yaf(a)ray’s light is just more realistic.

Have there been any updates to blender’s render api that would allow a yafaray sprint to become more integrated? (eg nodal materials…)

It’s been a while since I last investigated yafaray and back then the lack of motion blur and simplistic materials made it not a good choice for me… (I needed to be able to make a slope based snow shader or custom dirt passes modulated by AO…

i like yafaray…
but it is slowly developed - compared to LuxRender
i do not see that here is something happen on yafaray
i hope code sprint change something

what i need is GPU+CPU hybrid!
and extra samples control for glossy pixels (1. ray from cam)!!!

If I am correct, isn’t yafarays strength in photon mapping? I which is something that is ahead of luxrenders by a fair bit? Hope I’m right anyhow :stuck_out_tongue:

As far as I can tell, integrating external engines to work with the node system would require heavy alterations of the C/C++ of Blender itself. In fact, I believe it’s a bit of a sore spot to some external devs who were promised a more open render API in 2.6, as part of a concurrent effort to go with Cycles development.

For a while don’t expect too many changes in YafaRay and now the focus is on improving the current set of features and implementing irradiance cache and the SSS shader.

GPU won’t happen. The total cost and the opportunity cost of GPU raytracing is huge even for commercial raytracers. GPU raytracing is a whole different specimen with it own set of advantages and problems, some of which don’t have a clear answer yet. I still believe that intelligent algorithms will beat brute force ones in the long run and at the moment those “intelligent” algorithms need broad CPU computing to run.