Looping twice on same ID pointer may not be an issue in master currently, but with work done in id-remap
branch this should be avoided as much as possible, so for now assuming we do not need this here.
Note: if we really need this and have to add it back, then please at least use IDWALK_USER, and not
IDWALK_NOP flag!
Place non-editor related keymaps together, place animation editor keymaps together, move 'Header' keymap (which had exactly 1 entry) into 'Screen' keymap, move SCREEN_OT_header (for showing/hiding header) into 'Header' keymap.
Again, this shouldn't break any key configs, but key configs that contain SCREEN_OT_header will add an entry for this under 'Screen' again. Just a very minor glitch.
Apparently this is the result of some sloppiness during 2.5 project and since then it confused people who were trying to understand the area-region relation (myself included).
Sorry if this causes merge conflicts for anyone, but at some point we really had to do it :/
C++ structures might be rather big and passing them by value is not really
optimal. There should be no functional changes apart from better memory
access pattern when synchronizing huge scenes to Cycles.
There were multiple issues which are solved now:
- It was possible that ray wouldn't be bounced off the BSSRDF, for example
when PDF or shader eval is zero. In this case PathState might have been
left in pre-bounced state which would have been gave incorrect shading
results.
This is solved by having separate PathState for each of the hits.
- Path radiance summing wasn't happening correct as well, indirect rays
were using wrong path radiance in the case when there were more than
one hit recorded.
This is now using a bit trickier state machine which calculates path
radiance for just SSS (both direct and indirect) and then sums it back
to the final radiance.
- Previous commit wasn't totally correct either and was an induced bug
due to wrong path state left from the "un-happened" ray bounce.
There should be no special case happening here, BSSRDFs will be replaced
with diffuse ones due to PATH_RAY_DIFFUSE_ANCESTOR flag.
- Merged back codebases for "delayed" and "immediate" indirect SSS ray
tracing, hopefully making it easier to maintain the codebase.
Sure this changes brings memory usage back by about 4-5%, but overall
it's still about 2x memory reduction for the experimental kernel here.
Thanks Brecht for the review!
This is actually how it was intended to work, just didn't notice it wasn't
really happening in the main ray loop.
Solves some memory issues reported in T46880.
Restore fixed function lighting code for now and control use of GLSL shader
with a variable, make light types more clear, reduce state changes, some other
minor tweaks.
Issue was with datablocks which names would include '/', new filebrowser filelisting code
would cleanup the entire filepath, hence giving invalid filename in this case.
That 'path separator in ID names' bit us already in lib/datatype/datablock separating func,
this is really stupid to allow that in something handled as a filepath imho, but well...
Note: would have break the same under *nix with '\' char.
There are some issues to be solved with the recent optimization we did for
the indirect rays for the SSS. Those issues will take a bit of a time to
be fully solved still and we need to unlock Caminandes team now, so let's
revert some changes back.
CUDA will still use delayed indirect rays since it's an experimental
feature.
For the details about what's to be done still please refer to T46880.
This wasn't really a complete fix and only worked if there was a single scatter
event recorded only. Proper fix requires some more thoughts to make it correct
without memory use increase.
This reverts commit bf9e88bfbe.
The issue was caused by a conflict between std::error_code linked into
Blender which is compiled without C++11 support and POCL's expectations
of std::error_code which was actually linked against C++11's STL.
Radiance sum and reset was happening in different order after 26f1c51.
This is a quick fix to unlock Caminandes team, perhaps we can avoid having
separate variable to detect when radiance is to be sum.
