Added Raytraced Indirect Lighting for BI #37015
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
15 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37015
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
%%%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%%%
%%%+1
Incredibly useful for game artists needing to bake lightmaps for their levels.%%%
%%%+1
raytracing on BI is slow anyway, so ...why not?%%%
%%%+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.%%%
%%%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? %%%
%%%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
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);
Line 614-615:
+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...
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.
@ bashi
OH YES i'm very interested to try it all on an OS X build :-)
OSX build here .
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).
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
Changed status from 'Open' to: 'Archived'