Added Raytraced Indirect Lighting for BI #37015

New Issue

%%%This patch enables raytraced Indirect Lighting for Blender Render. This is a feature that has been requested by many for the use of baking indirect lighting in games. It seems like there is not many resources dedicated to expanding baking/Blender Render at this time. I needed this feature for my project and figured it would not be too difficult to add myself, and thought I would contribute it back to the Foundation to show my appreciation of all the amazing work that has made Blender what it is.

As you can see, I went ahead and cleaned up the old raytracing code, the functionality should be the same, but it is now more maintainable as it was branching out with a lot of duplicate code. Essentially I broke it down into what each different sample method does uniquely, allowed those to provide the sample ray direction which then per sample gets passed into the generic AO evaluation code and accumulated the same for every sample method, and then the resulting data gets passed back and handled differently depending on the sample method (adaptive, non-adaptive, etc) and then the results are finally averaged back down based on samples/skyhits the same.

My build is running slightly slower in terms of raytraced occlusion than the trunk version. This might have something to do with the fact the code is easier to maintain for the trade-off of being slightly slower, though it could also be the compiler I am using (MSVC2008). I know for a fact it could/would be slightly faster if I were not sharing code between functions... but there's that maintainability thing. Basically I figure if I ever need to go back in and change this code, I would rather make changes in 1 place than 4 places.

If desired, I could always revert the previous ray_ao_qmc and ray_ao_spheresamp functions back to what they were and simply put in a new path for indirect. It just made sense at the time since there is a lot of code repetition between what would have been 4 large functions to support the different sample methods. So if a bug were ever fixed it would have to be fixed in all the branches.

Now I did notice some strange code having to do with Env lighting. In particular I am not sure what this is doing or what the point would be as the input seems rather bogus:
dxyview- [x] = 1.0f/(float)R.wrld.aosamp;
dxyview- [x] = 1.0f/(float)R.wrld.aosamp;
dxyview- [x] = 0.0f;

This vector is passed into shadeSkyView like so:
shadeSkyView(skycol, isec->start, isec->dir, dxyview, shi->thread)

I dug around a little bit, but got kind of lost and wanted some feedback from whoever wrote that or understands what it is doing. Either way, the patch is essentially doing the same thing, but I do not understand why "1/samples" is being passed into a variable named something-"view".. shouldn't this be a texture coordinate for a env map or something and not a meaningless constant? But if we have a texture coordinate, then why would we need to pass it into a function for env map sampling.. wouldn't that be the point of the function to figure out? Confused.

I also noticed some strange code for providing a bounding box ray hint with the function "RE_rayobject_hint_bb". isec->start was passed in for both min and max of the bounding box.. which doesn't seem like much of a hint to me. I put in the maximum ray position as the max, though I do not notice a lot of speedup or penalty with this, so please let me know if I am doing something wrong. It did seem to make a slight difference on a more complicated test scene with lots of geometry that might be outside the bounding box, but either way I need to know if I am using it right or if I should take out the hint altogether, or if the hint system is somewhat non-functional at the moment. Whatever the case, feedback needed.

Other than that things seemed pretty straight forward.

I put a post in the Blender Artists forum where I have invited artists to test my Windows build/patch. This can be found here:
http://blenderartists.org/forum/showthread.php?313932-Raytraced-Indirect-Lighting-For-Blender-Render-Available-Now-Please-Test!

I wanted to go ahead and get this patch into the tracker for additional testing and under-the-hood feedback or change requests.

Thanks for your time! My hope is that this is more of a help than a bother.%%%

%%%This patch enables raytraced Indirect Lighting for Blender Render. This is a feature that has been requested by many for the use of baking indirect lighting in games. It seems like there is not many resources dedicated to expanding baking/Blender Render at this time. I needed this feature for my project and figured it would not be too difficult to add myself, and thought I would contribute it back to the Foundation to show my appreciation of all the amazing work that has made Blender what it is. As you can see, I went ahead and cleaned up the old raytracing code, the functionality should be the same, but it is now more maintainable as it was branching out with a lot of duplicate code. Essentially I broke it down into what each different sample method does uniquely, allowed those to provide the sample ray direction which then per sample gets passed into the generic AO evaluation code and accumulated the same for every sample method, and then the resulting data gets passed back and handled differently depending on the sample method (adaptive, non-adaptive, etc) and then the results are finally averaged back down based on samples/skyhits the same. My build is running slightly slower in terms of raytraced occlusion than the trunk version. This might have something to do with the fact the code is easier to maintain for the trade-off of being slightly slower, though it could also be the compiler I am using (MSVC2008). I know for a fact it could/would be slightly faster if I were not sharing code between functions... but there's that maintainability thing. Basically I figure if I ever need to go back in and change this code, I would rather make changes in 1 place than 4 places. If desired, I could always revert the previous ray_ao_qmc and ray_ao_spheresamp functions back to what they were and simply put in a new path for indirect. It just made sense at the time since there is a lot of code repetition between what would have been 4 large functions to support the different sample methods. So if a bug were ever fixed it would have to be fixed in all the branches. Now I did notice some strange code having to do with Env lighting. In particular I am not sure what this is doing or what the point would be as the input seems rather bogus: dxyview- [x] = 1.0f/(float)R.wrld.aosamp; dxyview- [x] = 1.0f/(float)R.wrld.aosamp; dxyview- [x] = 0.0f; This vector is passed into shadeSkyView like so: shadeSkyView(skycol, isec->start, isec->dir, dxyview, shi->thread) I dug around a little bit, but got kind of lost and wanted some feedback from whoever wrote that or understands what it is doing. Either way, the patch is essentially doing the same thing, but I do not understand why "1/samples" is being passed into a variable named something-"view".. shouldn't this be a texture coordinate for a env map or something and not a meaningless constant? But if we have a texture coordinate, then why would we need to pass it into a function for env map sampling.. wouldn't that be the point of the function to figure out? Confused. I also noticed some strange code for providing a bounding box ray hint with the function "RE_rayobject_hint_bb". isec->start was passed in for both min and max of the bounding box.. which doesn't seem like much of a hint to me. I put in the maximum ray position as the max, though I do not notice a lot of speedup or penalty with this, so please let me know if I am doing something wrong. It did seem to make a slight difference on a more complicated test scene with lots of geometry that might be outside the bounding box, but either way I need to know if I am using it right or if I should take out the hint altogether, or if the hint system is somewhat non-functional at the moment. Whatever the case, feedback needed. Other than that things seemed pretty straight forward. I put a post in the Blender Artists forum where I have invited artists to test my Windows build/patch. This can be found here: http://blenderartists.org/forum/showthread.php?313932-Raytraced-Indirect-Lighting-For-Blender-Render-Available-Now-Please-Test! I wanted to go ahead and get this patch into the tracker for additional testing and under-the-hood feedback or change requests. Thanks for your time! My hope is that this is more of a help than a bother.%%%

Changed status to: 'Open'

%%%+1

I tested this patch in a 64bit Linux build (2.69 r60729). The code seems stable and works exactly as advertised. I didn't experience any bugs or regressions. UI integration is good. The feature itself is useful and has been requested for a long time.%%%

%%%+1 I tested this patch in a 64bit Linux build (2.69 r60729). The code seems stable and works exactly as advertised. I didn't experience any bugs or regressions. UI integration is good. The feature itself is useful and has been requested for a long time.%%%

%%%+1%%%

%%%+1

Incredibly useful for game artists needing to bake lightmaps for their levels.%%%

%%%+1 Incredibly useful for game artists needing to bake lightmaps for their levels.%%%

%%%+1
raytracing on BI is slow anyway, so ...why not?%%%

%%%+1 raytracing on BI is slow anyway, so ...why not?%%%

%%%+1
%%%

%%%+1 %%%

%%%+1 Definitely a big difference from the Legacy BI Indirect lighting... %%%

%%%+1
I still use BI for most work that i need 3D for.
Using Blender in OS X.%%%

%%%+1 I still use BI for most work that i need 3D for. Using Blender in OS X.%%%

%%%Guys, no matter what you read on blenderartists, posting "+1" posts here won't make us review and include patches faster. We have 409 open patches here, bugs, an upcoming release, the UI discussion... Resources are just limited.

It would be much more helpful to test the patch, report issues or limitations, so the patch developer can improve the work. %%%

%%%Guys, no matter what you read on blenderartists, posting "+1" posts here won't make us review and include patches faster. We have 409 open patches here, bugs, an upcoming release, the UI discussion... Resources are just limited. It would be much more helpful to test the patch, report issues or limitations, so the patch developer can improve the work. %%%

%%%It is in the instructions when submitting a patch that users should add +1's, which is why I promoted that concept in the artist forums. Good to know this is no longer desired, perhaps it should be taken out of the instructions?%%%

%%%This is part of "3) The review process" and applies to developers only.

Anyway, this feature is nice to have and if properly coded a welcome addition to Blender Internal. I checked the blenderartists thread and it seems this is currently slower that what Brecht added in the render25 branch. The render25 branch also had an additional Irradiance Cache to speed it up. Have you thought about that? %%%

%%%This is part of "3) The review process" and applies to developers only. Anyway, this feature is nice to have and if properly coded a welcome addition to Blender Internal. I checked the blenderartists thread and it seems this is currently slower that what Brecht added in the render25 branch. The render25 branch also had an additional Irradiance Cache to speed it up. Have you thought about that? %%%

%%%I have thought about caching stuff. But I wanted a brute force method to compare against at bare minimum (also faster to get up and running now). what kinds of caching abilities do we have in Blender currently, or am I kind of on my own here? Do we have an Octree lib or KDtree? Do we already have the ability to scatter points on geometry?%%%

%%%Also, sorry about promoting the +1's from non-programmers. I did indeed misunderstand the instructions. Now that you've mentioned it, it does make more sense.%%%

Added subscriber: @JorgeBernalMartinez

Added subscriber: @Swyter

Added subscriber: @SebastianRothlisberger

Patch won't build on osx with Clang nor gcc 4.8

blender version 2.69.8: 2014-01-07, ead8b82

Compiling ==> 'rayshade.c'
source/blender/render/intern/source/rayshade.c:2109:6: error: conflicting types for ‘ray_ao’
 void ray_ao(ShadeInput *shi, float ao[3], float env[3])
      ^
In file included from source/blender/render/intern/source/rayshade.c:61:0:
source/blender/render/intern/include/rendercore.h:94:13: note: previous declaration of ‘ray_ao’ was here
 extern void ray_ao(ShadeInput *shi);
             ^
scons: *** [/Volumes/space/blender-build/build/darwin-BI_ray/source/blender/render/intern/source/rayshade.o] Error 1
scons: building terminated because of errors.

Patch won't build on osx with Clang nor gcc 4.8 blender version 2.69.8: 2014-01-07, ead8b82 ``` Compiling ==> 'rayshade.c' source/blender/render/intern/source/rayshade.c:2109:6: error: conflicting types for ‘ray_ao’ void ray_ao(ShadeInput *shi, float ao[3], float env[3]) ^ In file included from source/blender/render/intern/source/rayshade.c:61:0: source/blender/render/intern/include/rendercore.h:94:13: note: previous declaration of ‘ray_ao’ was here extern void ray_ao(ShadeInput *shi); ^ scons: *** [/Volumes/space/blender-build/build/darwin-BI_ray/source/blender/render/intern/source/rayshade.o] Error 1 scons: building terminated because of errors. ```

bashi, it appears the patch was not applied successfully. Looking at the patch file both places are changed to the single input version.

See patch file:

Line 31-32:

extern void ray_ao(ShadeInput *shi, float ao- , float env[3]);
+extern void ray_ao(ShadeInput *shi);

Line 614-615:

void ray_ao(ShadeInput *shi, float ao- , float env[3])
+void ray_ao(ShadeInput *shi)

But the error shows your rendercore.h is the old version.

bashi, it appears the patch was not applied successfully. Looking at the patch file both places are changed to the single input version. See patch file: Line 31-32: - extern void ray_ao(ShadeInput *shi, float ao- [x], float env[3]); +extern void ray_ao(ShadeInput *shi); Line 614-615: - void ray_ao(ShadeInput *shi, float ao- [x], float env[3]) +void ray_ao(ShadeInput *shi) But the error shows your rendercore.h is the old version.

Excuse me, it looks like the rayshade.c was not patched correctly but rendercore.h was. Not the other way around...

thank you. i now realise i patched current blender not the revision 60414 mentioned in the patch. so i guess i will try to patch this one. thanks for the tip, saved me some time.

Removed subscriber: @ThomasDinges

Thanks, it worked with revision r61268.

Unfortunately - it is quite slow if bounce grater than 1 - have to do some more tests.

But anyway many thanks for your work on this - Long live BI.

BTW: Any interest on a OSX build of this? Can upload it somewhere if so...

Thanks, it worked with revision r61268. Unfortunately - it is quite slow if bounce grater than 1 - have to do some more tests. But anyway many thanks for your work on this - Long live BI. BTW: Any interest on a OSX build of this? Can upload it somewhere if so...

Removed subscriber: @ygtsvtr

Added subscriber: @ZauberParacelsus

Well, I just tried this patch out, and it seems to be a mixed bag for me. On one hand, the results are much more accurate than with approximate gather. On the other, the rendering is slower. In particular, the pain points are (A) using more than 1 bounce (as mentioned above), and (b) raytraced transparency. A single object with raytraced transparency can easily double or even quadruple the rendering time.

Still get a better (ie: not as noisy) render in less time than it would take with Cycles, though. So I am pleased.

Well, I just tried this patch out, and it seems to be a mixed bag for me. On one hand, the results are much more accurate than with approximate gather. On the other, the rendering is slower. In particular, the pain points are (A) using more than 1 bounce (as mentioned above), and (b) raytraced transparency. A single object with raytraced transparency can easily double or even quadruple the rendering time. Still get a better (ie: not as noisy) render in less time than it would take with Cycles, though. So I am pleased.

@ bashi

OH YES i'm very interested to try it all on an OS X build :-)

@ bashi OH YES i'm very interested to try it all on an OS X build :-)

OSX build here .

OSX build [here ](https://www.dropbox.com/s/hf0zqssg68qvjpi/blender_BI_raytrace.zip).

Thanks bashi,

Tested it quickly and as previous mentioned some settings gives very long rendertimes but it's still highly impressive.
I hope this will be developed further and become a future update of BI as it would be a great complement to Cycles.

Amazing work guys :-)

Thanks bashi, Tested it quickly and as previous mentioned some settings gives very long rendertimes but it's still highly impressive. I hope this will be developed further and become a future update of BI as it would be a great complement to Cycles. Amazing work guys :-)

Added subscriber: @aocif23

patch fail on 2.70 RC
commit 4ce7d5cb79

I:\BlenderDEV\blender>patch -p0 < raytraced_indirect.patch
patching file release/scripts/startup/bl_ui/properties_world.py' patching file source/blender/render/intern/include/rendercore.h'
patching file source/blender/render/intern/source/rayshade.c' Hunk #1 succeeded at 1169 (offset -31 lines). Hunk #2 FAILED at 1821. Hunk #3 FAILED at 2102. 2 out of 3 hunks FAILED -- saving rejects to source/blender/render/intern/source/rayshade.c.rej patching file source/blender/render/intern/source/shadeoutput.c'
Hunk #1 succeeded at 1080 (offset 2 lines).
Hunk #3 succeeded at 1818 with fuzz 2 (offset 9 lines).
Hunk #4 succeeded at 1920 (offset 2 lines).
Hunk #5 succeeded at 1975 (offset 9 lines).

patch fail on 2.70 RC commit 4ce7d5cb79e23c4b28b1f1afe11fa066f3a5ea9c I:\BlenderDEV\blender>patch -p0 < raytraced_indirect.patch patching file `release/scripts/startup/bl_ui/properties_world.py' patching file `source/blender/render/intern/include/rendercore.h' patching file `source/blender/render/intern/source/rayshade.c' Hunk #1 succeeded at 1169 (offset -31 lines). Hunk #2 FAILED at 1821. Hunk #3 FAILED at 2102. 2 out of 3 hunks FAILED -- saving rejects to source/blender/render/intern/source/rayshade.c.rej patching file `source/blender/render/intern/source/shadeoutput.c' Hunk #1 succeeded at 1080 (offset 2 lines). Hunk #3 succeeded at 1818 with fuzz 2 (offset 9 lines). Hunk #4 succeeded at 1920 (offset 2 lines). Hunk #5 succeeded at 1975 (offset 9 lines).

As Bashi discovered above, this patch was written for the "current" release a couple current releases ago (2.68).. so in other words it will not work with the current blender 2.70RC without some manual updating to compensate for changes made to the master branch.

@ sgraham

ok,it worked on 2.69

@ sgraham ok,it worked on 2.69

Changed status from 'Open' to: 'Archived'

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Added Raytraced Indirect Lighting for BI #37015