Self shadowing problems 64 bit Windows build

Component:YafaRay Core
Category:bug report
Assigned:David Bluecame

Hello David,

With regard to the title of this test case, we've found that faces aren't rendered correctly with 64bit verdsion.

I'm including a couple of attachments, including the xml file where you can see that we haven't even used any normals. In fact, we get two different results using the same file.

please let us know.


ACCA Software S.p.A.

Rendering_YafarayExpiremental1_32Bit.jpg43.99 KB
Rendering_YafarayExpiremental1_64Bit.jpg67.53 KB
XML_BUG Yafaray 64Bit.zip64.4 KB



Could you please share your blender file.

I am just curious to test it myself. It may just be a modeling the mesh issue rather than yafaray.





Title:Encountering rendering problems with 64bit version» Self shadowing problems 64 bit Windows build
Priority:critical» normal
Assigned to:Anonymous» David Bluecame
Status:active» needs review


Several comments:

* I agree with 3djkk that this particular problem is caused by the modeling. There are strange polygons in this model, very long and narrow.

* It seems that the 32bit is ok and the 64bit is not ok (clear artifacts in the 64bit version), but if you look closely to the 32bit rendered image, there are artifacts too (black dots in top table, bottom left corner), but they are subtle.

So, in my opinion the model should be reviewed and corrected and afterwards try to render it again in both 32bit/64bit versions.


However, there is obviously a difference between the versions that deserves an explanation:

* Windows 32bit builds are made for the 387 floating point instruction set.

* Windows 64bit builds are made for the SSE/SSE2 floating point instruction set.


Unfortunately, the internal precision and other strange floating-point aspects are different between 387 and SSE/SSE2 instruction sets. When the models contain very narrow and long triangles, this could cause what's called "self shadowing" problems. Self shadowing issues are caused by floating point precision limitations. As the internal precision of the 387 instructions is different, it could happen that images with "difficult" models render differently and one version shows more or less artifacts than the other.

It's not the first time this happens and self shadowing is discussed. We could probably solve the self shadowing problems for good... but it would require two things:

* Use higher precision, double 64bit floating point variables instead of the current float 32bit floating point variables.

* Use stronger and more reliable triangle intersection algorithms.


The problem with that is computing requirements. If we went ahead to solve the self shadowing that way, the render times would increase in a very significant amount, as well as the RAM requirements. So far, I've implemented a few "tricks" to help with self shadowing but they are not enough to solve certain cases as this.

Possible solutions:

* Fix the models (recommended)

* I could try to build a 64bit Windows version that uses the 387 instruction set, but I tried to do it in the past and I got strange problems, possibly because the external libraries are using SSE/SSE2 so there is a conflict somewhere. Additionally, the 64bit PC architecture uses by default SSE/SSE2, not sure how 387 instructions would fit in...

* Fix the self shadowing problems for good with 64bit doubles and different intersection algorithms... but rendering will be A LOT slower!


I will leave this issue open for now for review. I hope that YafaRay developers can give us feedback about the way to go about this... In the mean time, my suggestion is to try to "sanitize" the models themselves.


Best regards. David.


Hello David,

We understand your reasoning, unfortunately 3D models are uploaded by users, so we can fix them only after we have sent the project.
Anyway thanks for the explanation, and thanks also to 3djkk.

Best regards


ACCA Software S.p.A.




I've investigated further and I've reached the same conclusions as before: the difference is caused by the default floating point processor used when compiling for 32 bits (387 processor) or for 64 bits (SSE processor). It's a known issue in many software packages and compilers.

So, the "good" solution would be a full change so all calculations are done natively in double 64bit floating point, but that would require a lot of work and it would probably cause the rendering to be slower.

For now, the only "workaround" I can think about is to make a special build for Windows 64bit using the 387 processor.

Probably you have seen in the forums that I've relased the new YafaRay-E v2.0.0 a few days ago with many improvements. I have still (pending work) to document the changes and also to document the new features available in the XML files. However for now please try it with your existing XML scenes and let me know how it works.

I've also made, just for you, a special build of YafaRay-E v2.0.0 Windows 64bits using the 387 processor and not the SSE processor. In my tests, it seems to help with the XML scene you posted here. You can download it from:

I hope it helps, please let me know. I would still expect some artifacts (like small black and white dots) that I believe are caused by the model itself (which contains too many thin narrow long triangles that cause intersection problems in the first place), but it should give you better results than the standard 64bit SSE build

PS: maybe this will be interesting for you: a new feature in v2.0.0 is the ability to save partial images during XML rendering. To use it, just add the option "-pst 3" to the yafaray-xml line before the name of the XML to be rendered. That should save the partial image every 3 seconds. You can change the number to another integer number, for example -pst 5, -pst 10 etc. I hope it helps you for the previsualizations of the renderings.


Status:needs review» postponed

This needs a deep review of the current intersection algorithms, postponed for now...