There's an optimization in the shadow intersection code where (for non-transparent) shadows if any intersection is found then the ray tracing stops, as opposed to continuing to test any other additional surfaces to find a possibly closer intersection point. Also, remember that reflections and the like have to perform shading, while shadows do not (unless transparent shadows are enabled).<br>
<br>Joe<br><br><div class="gmail_quote">On Fri, May 9, 2008 at 4:01 PM, Yves Poissant <<a href="mailto:ypoissant2@videotron.ca">ypoissant2@videotron.ca</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
After some time fiddling with the BIH and then reading some more papers,<br>
thesis and ompf forum threads, I came to the conclusion that the BIH<br>
implementation that was ripped from SunFlow and adapted to Blender was<br>
optimal. But I was not satisfied with the results so I implemented a BVH<br>
just to compare. The BVH alone is faster than the BIH for half of the scenes<br>
I had for testing purposes. Then I implemented SAH (Surface Area Heuristic)<br>
BVH and this one is clearly the winner. It is always faster than the BIH.<br>
And it is as fast to much faster than the octree. So that is good news. I<br>
still need to implement other triangle intersection functions and test them.<br>
I'm convinced I can get even more speed with a good implementation of the<br>
barycentric test. And I still haven't attempted to use SSE optimization yet.<br>
<br>
Here is the question: There are a few bugs though and I need to trace the<br>
execution for specific pixels. What is the technique for tracing the code<br>
execution for specific pixels? Say I want to break into to code at pixel<br>
x:10,y:20. Is there a known way to do that? I can certainly find this out<br>
but if someone already knows the trick, that would help me. I plan to do<br>
that bug hunting this week-end.<br>
<br>
BTW, the bug is related to processing shadow rays vs non-shadow rays.<br>
Non-shadow rays are much slower to process than shadow rays and there are no<br>
reasons for that especially given that the non-shadow rays are quite slower<br>
with BIH or BVH than with the octree. For example, it is no uncomon to get 3<br>
to 6 times speed improvement with scenes that uses soft raytraced shadows<br>
but that same improvement is difficult to get with scene that have a lot of<br>
reflections. So I think there is a bug with the data returned by the<br>
intersector when intersecting non-shadow rays.<br>
<br>
Yves Poissant<br>
<br>
_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</blockquote></div><br>