YafRay fake pass?

What’s “fake pass”?
Why is it fake?


It’s still rendering,
it takes forever. Now it’s doing a whole bunch of dots… With a # sometimes.
It has filled like 150 screens already.
I don’t know why some people say that YafRay is faster than Blender Internal… My Blender Internal slowest renders are around 6 mins.
I am so close to killing the Blender process, but I realize it took alot of work.

Yafray is faster on Raytracing.
What it’s doing is normal; first the fake pass, then the render pass. If you set the quality high it will take longer.
Each # represents a rendered part, if you count them you can estimate how much it has done.

Here is some info:- http://wiki.blender.org/index.php/Manual/YafRay

Nevermind lol

Thanks, organic.
I think it’s in part pecause of the photons…

I haven’t used Yaf in ages, but if you turn off the ‘xml’ button, you can see it as it renders, instead of having to wait till the end to see the result.

Other tips to speed up renders:

If using GI, activate the ‘cache’ button and set the ‘ShadQu’ to about 0.150 for test renders. With these settings, it should be quite a bit faster than Blender.

Thanks, [email protected]
But when I disabled xml suddenly blender crashes when rendering…

Funny that you should mention that, because the exact same thing happens to me. You on Win XP?

I’ll ask about it, because that was a useful feature.

I’m on Vi$ta. I’ll change it sometime.

Hmm. well, shouldn’t make much difference. I’ll try and find out how to fix it for you (and me)

I don’t think it is fixable; something to do with the Blender-Yafray interface. Yafray development isn’t being actively pursued; have you considered Yaf(a)ray ?



Watch that thread for any potential answers.

That build seems to work

That build doesn’t have BGE!

“Fake pass” means YafRay doesn’t actually compute pixels but build the irradiance cache. For this it checks each pixel if enough nearby irradiance samples are available, and if not creates another one.
All those dots in the console on the final rendering pass are when still not enough irradiance samples are found (because reflections/refractions reach other scene parts for example).
The irradiance cache is not the most efficient one, but yaf(a)ray doesn’t even have one yet (basically because it is not very suited for glossy surfaces, which people love to excessively use, we’d need a more comples radiance cache for that)

The direct connection (without XML) has never been very robust because it is C++, which has no standardized ABI like C, that means, different compiler (-version) => possibly incompatible binaries.

About Yaf(a)Ray, maybe (only maybe) special builds will be unnecessary soon, if the Python bindings provide sufficient stability and performance, at least yafray rendered material preview is realistic…also the interface is completely C compatible, so any build of blender should work with any build of yaf(a)ray, provided the interface didn’t change between the two builds…

Thanks, Lynx3d.
I understand everything now.