Visibility flags are set to all visibility anyway, So there was no reason
to perform that test.
TODO: We need to investigate if having primitive intersection functions
which doesn't do visibility check gives any speedup here as well.
This way extending intersection routines with some pre-calculation step wouldn't
explode the single file size, hopefully keeping them all in a nice maintainable
state.
These nodes were assuming sRGB input/output which is for sure wrong for the
shader pipeline which works in the linear space.
So now conversion to/from linear space happens in these nodes which makes them
making sence in the shader context but which might change look and feel of
existing scenes.
The issue was caused by the way how RNA pointer was created for the bMain:
namely Cycles was using RNA_id_pointer_create to create the pointer, which
would then try to refine the poniter based on the ID type.
This is just wrong and worked so far just because of co-incident, with the
file path from the bug report first letters in the ID name happened to be
NT which corresponds to NodeTree, and for sure refining such pointer will
fail.
Simple solution -- use proper way to create RNA pointer for non-ID block.
This was caused by some internal optimization which evaluated SSS with
size of zero as BSDF but used different ID so the evaluation result
didn't appear in regular diffuse pass.
This lead to situation when SSS data was nowhere stored if the
size was zero.
Now SSS with zero size and close-to-zero sizes will be handled in the
same way from the passes point of view.
This way CUDA errors are visible in the image info line,
which makes things to behave the same across viewport and
final rendering.
That's right, we've got error reported via reports and info
line now. This is based on the feedback from our gooseberry
team.
This way when something goes wrong in Cycles (for example out of VRAM, timelimit
launching the kernel etc) we'll have a nice report in the Info space header.
Sure it'll be nice to have mention of error in the image editor's information
line, but that's for the future.
This fixes T42747: "CUDA error" appears only momentarily, then disappears
Currently it acts the same as set_cancel(), but this way we're able to
distinguish situations when rendering was aborted by user demand (for
example pressing Esc in standalone renderer) or if something went horribly
wrong (for example out of VRAM error).
This way for example we wouldn't wait a fortune while BVH is building after
GPU run out of memory when loading images just to see the render failure
message.
Forbid OSL from polluting current conext with obscure stuff from
windows.h, it's not useful and unhealthy anyway.
Maybe we sohuld also forbid using abbreviated Glog constants as
well tho.
Since the aligned allocation of shader closures in OSL memory pool
this workaround is no longer needed.
Also put a comment which describes the desired layout of the structure
so array of shader closures is all nicely aligned.
This solves bugs like T42210 which are caused by compiler being
smart and using some SSE instructions to operate with closure
classes, which was failing because those classes are not allocated
by the regular allocator but allocated in memory pool in OSL.
With newer versions of OSL it is now possible to force closure
classes being aligned to a given boundary and this commit uses
this new functionality.
Unfortunately, it means we're no longer compatible with older
versions of OSL, only latest git version from upstream and our
branch at github are supported:
https://github.com/Nazg-Gul/OpenShadingLanguage/tree/blender-fixes
For OSX and Windows it's not an issue because libraries are
already updated there, Linux users would need to run install_deps
script.
The issue was noticed with gcc-4.7 (used by the release build environment)
which didn't generate optimal enough code for BVH references swap. Seems it
looked up for the assign operator for each of the reference structure members
even though nothing special was required for assignment.
Forcing compiler to use simple memory copy gives speedup of like 2-3 times.
The issue doesn't happen with OSX's clang and new gcc-4.9, but since we're
gonna to stick to gcc-4.7 for official releases for quite some time still it's
nice to have performance issues resolved for all the compilers.
Didn't put the code into #ifdef so if in the future some issues appears with
alignment or assignment which need to happen as an operator we notice this
earlier.
* Alpha Property was removed (Fix T42690)
* Some tweaks to make the panel look better again.
* Use abreviated form "Multiple Importance" everywhere, for consistency.
So now cases when object has both hair motion blur and deformation motion blur
vector pass is all correct.
We could get rid of the flag in the future, still need to look deeper into all
the areas trying to find a more clear solution.
Issue was caused by mismatch in pre/post transform matrix spaces for mesh and
curve vectors. This happened because of current way how static transform apply
works: it only stores post/pre in the world space if there's triangle motion
exists. This lead to situation when there's no triangle motion happening but
was hair motion happening.
After long time of trying to solve it in a nice way, ended up solving it in
a bit slow way -- pre/post transform is still storing in the same spaces as
they used to be stored and just convert hair pre/post position to a world
space in the kernel.
This is because currently it's not so clear how to deal with cases when curve
and mesh motion needs different space of pre/post transform (which happens in
cases when only one of the motions exists).
Would think of some magic, and meanwhile artists could be happy with proper
render results.
It appears it's not really needed for convenient debugging when
using proper flags passed to the compiler. Basically, it is -g3
and set breakpoint to a function as if it's not in the namespace.
Not as if a code was any wrong, just it's possible to have more
clear solution for the issue i've tried to solve in the past.
Create unique flag for output shaders with displacement data and use it
to calculate transformed normal. Implementation suggested by Brecht Van
Lommel.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D890
