You're blocking ads, which pay for BlenderNation. Read about other ways to support us.

Google Summer of Code: Faster Ray Tracing


800px-Soc2009-test-real-Fruits3oChris Want reports on the impressive improvements in Blender's ray tracer by André Susano Pinto.

Chris writes:

Returning Google Summer of Code student André Susano Pinto (a.k.a jaguarandi) has been working on improving Blender's ray tracer, mentored by coding god Brecht Van Lommel.

André has recently posted some speed up results from his project:

Ray tracing is an arcane art, so I asked veteran coder Daniel Genrich if he could help explain how André achieved his impressive results, in terms that anybody can understand. Daniel says

"He switched to special BVH's using adaptive children count, exploiting raycoherence using hints/LCTS, SIMD at the end. He's using self developed heuristics to build trees and reduce the expected number of bounding box tests by about 20%. He calls his BVH's "VBVH" and "SVBVH". VBVH is much slower than SBVH when using non-SIMD."

Well, that certainly clears things up for me! :)

To learn more about the details of the André's project, please check out the project proposal and the weekly progress reports for this project:

You can checkout André's SVN branch here:

Feedback on the project can be posted to the 2009 Summer of Code mailing list:

About Author

Bart Veldhuizen

I have a LONG history with Blender - I wrote some of the earliest Blender tutorials, worked for Not a Number and helped run the crowdfunding campaign that open sourced Blender (the first one on the internet!). I founded BlenderNation in 2006 and have been editing it every single day since then ;-) I also run the Blender Artists forum and I'm Head of Community at Sketchfab.


  1. wow impressive results - great project - thanks Andre

    unlike @bart I will just have to settle for acknowledging it works...somehow..

  2. wow. that is incredible! some of those are up to 3000% faster! its nice to know that that thing that makes renders really slow with large polygons in the background is fixed. now ill be able to stick a huge plane as a floor without having to worry about slowing the render down! im so happy :D

  3. Great work! Still I have a question on the performance measurements.

    Is a figure bigger than "100% faster" not weird? I suppose it is not meant to be read as percentage faster than the original render time :) but as the original render time is 100% slower (takes 2 times the time to render).

    Even so I really like to see how much time a bbb frame takes :)

  4. Jeroen Bakker: BBB didnt really use a lot of (hardly any) raytracing though. i don't know how much the speedups will affect it...

    nevertheless impressive development, thanks to André!! :)


  5. very impressive results! Are those examples really xxx% "faster" (meaning 100% being twice as fast as the old raytracer)?

  6. awesome work,
    I'm sure pimping a raytracer is very high tech, top-notch hacking.
    Gotta admire everyone that allows the users to get better, faster or more complex results due to their effort that they put into this software.
    I bow down before everyone in the coding section.

  7. Yes, Very impressive work ! Thank you for improving the raytracer.

    @thetinytoon :

    In my opinion, 100% = x1 = no change. 200% = x2 ; 300% = x3 ; 3000% = 30 x.

  8. offtopic: oh that's creepy, somehow my post got hacked by a spambot, the last line (and the website address obviously) is not mine! O_o


  9. results look good I wish that that as mentioned before the improvement were listed in a more transparent way. % faster is very un intuitive. % reduction would be better so that 0 is no reduction, %99 would mean one one hundredth the time. %100 faster I think means that there is no change but that still in english sounds like is one. time = original_time(1/%faster(

  10. Having used POV-Ray (Persistence Of Vision Raytracer) before learning of Blender, I gained two impressions of raytracing: (1) It makes lighting more realistic and (2) It makes rendering complex scenes as slow as molasses in Alaska. I use raytracing a lot and I can't wait to try the faster version! Great work!
    (P.S. This is not at all a criticism of POV-Ray - I have been using it again recently and it is an amazing program.)

  11. I still remember rendering a shiny sphere on a reflective checkerboard floor in POV on my 286, took 18 hours to get the first image.
    Ah, the good old days.

  12. mamoru :
    "I still remember rendering a shiny sphere on a reflective checkerboard floor in POV on my 286, took 18 hours to get the first image.
    Ah, the good old days."

    ....yeah, and the cpu was hot-glowing for next days ;)
    Was the time as i wish to get a 40meg Harddisk into my 286 case. "40 Megabyte Harddisk?!?!?!? You never fill it up with data.What you want with that?????" comment by an specialist in an CompuStore.
    -Ah, the good old days.- Yes but i don't miss it if i see what we can do today with blender!

  13. Their seams to be some confusion over the percentages. To clear things up 100% FASTER would be twice as fast because you have the original 100% plus a additional 100%, 200% Normal Speed = twice as fast (0% increase + original 100% = 100% normal speed). 3000% faster would be 31x (3000% increase + original 100% = 3100% normal speed).

    Loh had a good idea with reductions but I think the calculation would be a hair different, time = original_time(100/(%faster+100)). 100 percent faster would be original_time(100/(100+100)) => original_time(100/200) (1/2) original time.

    or by percentage reduction = (100 - (10,000/(100 + percentage increase))) .(0 percent increase would be 0 percent reduction) A 3000% increase would be a 96.8% reduction in time.

Leave A Reply

To add a profile picture to your message, register your email address with To protect your email address, create an account on BlenderNation and log in when posting a message.