Yes, this is for Blender Render, I assume that is what you mean by BI (Blender internal?) It is now called Blender Render, perhaps it was called Blender Internal before? 2.68 is the first version I’ve actually used.
I didn’t realize so many people ran their own build of Blender, that’s great! I just dropped the patch in the same skydrive folder in the first post.
I did try an old build of Blender which had Raytraced Indirect Lighting, but the results were about as accurate as Approximate, maybe the colors were slightly better but not what I expected anyway… seems like the sampling was getting reversed normals and such. I had to jump through hoops to get my normals facing the right way and bake out point clouds to visualize what I was getting in Houdini. The code could be optimized to do away with all the normal flipping that happens when you use some of the built in functions which deal with setting up the ShadeInput based on the intersect. I end up simply undoing the flipping after each flip because those functions blow away any history of the fact that they were flipped by overwriting the flippednor variable. I would imagine a lot of code could be done away with by simply not doing any normal checking/flipping and just using the geom normal. But for now I am favoring maintainability over speed.
As for speed of the images above, the single bounce Indirect is just around 2min 30sec at 32 samples. The 2 bounce at 8 samples took 3 minutes. I would like to add a feature where each additional bounce can use less samples than the one before. Maybe something like a “bounce sample factor”, like 0.5 means each additional bounce gets half the number of samples. Also note that the number of samples is misleading, because under the hood it is really doing max_samples = samples*samples, I felt lied to when I saw this. :’(
As you will see in the patch, I went ahead and cleaned up the old raytracing code to be more maintainable. My build is running slightly slower in terms of raytraced occlusion than the sanctioned version, which probably has to do with the fact the code is easier to maintain for the trade-off of being slightly slower. In my test of doing nothing but ambient occlusion with 128 samples, my times were ~2:30 for the standard Blender and ~2:56 for mine. I am compiling with MSVC2008 and not building/using OpenMP, not sure if either of those factors has anything to do with that. Please share your time tests as well having only Ambient Occlusion checked. Thanks!
My main interest in Blender Render is the baking functionality. This feature is so essential! I think the need for baking in Cycles and or to have Blender Render maintained for the purpose of baking is highly important. Basically I chose to use Blender in my production because it has great baking functionality and excellent modeling/uv tools. And of course because it is open source and free. But in spite of being free, I was looking into some expensive options, and not very impressed. I kept coming back to Blender which lacked a couple features I want, but had 99% of what I need… I figured I’d just add that 1% myself. This patch is half of that 1%. I also plan on adding more baking modes, such as “all lighting” (no textures). But not sure about public interest on that one.