| Age | Commit message (Collapse) | Author |
|---|
|
This was a mistake in the original code from D1079.
With the current way how direction ot mirror ball works camera should look
into negative Y direction. Corrected it in the camera matrix synchronization,
so no extra calculations are needed at the render time.
That's a bit annoying, but we'd better port it to the release branch, or
otherwise we'll end up with files created with wrong camera mapping after
2.75 release.
|
|
The idea is to make it possible to control linked duplicated objects motion
blur from the scene file without need to do overrides on the linked object
settings. Currently only supported for dupligroup duplication and all now
if duplicator object has motion blur disabled then it'll be inherited into
all the duplicated objects.
There should be no regressions/changes in look of existing files because
objects do have motion blur enabled by default.
|
|
Was only used for stats, netbsd doesn't define this function.
|
|
Didn't notice it originally because compilation was threaded.
|
|
|
|
This gives quite the same problems as experimental CUDA kernels
and for until it's found a root cause of the problem we'd just
explicitly uninline the function.
|
|
|
|
triangle intersection
Should be no functional changes.
|
|
|
|
This is mainly useful for the render farms output when logging might stop at
the "Path Tracing Tile N/N" string, which makes it a bit difficult to follow
what exactly is happening (node going crazy, hardware issues or just last tile
is too much heavy).
This is more like an experiment, might be changed in the future.
|
|
They'll be checked for the version later and that check will fail anyway,
so better to not allow user to see unsupported device in the list.
Also corrected one more issue with the device enumeration.
|
|
This includes total render time spent on rendering since render() was
invoked and also prints time of actual rendering (without synchronization
step).
|
|
Skipped devices did not reflect in the device number, which might result in bad
array indices.
This might also resolve T45037, and need to be ported to a release branch.
|
|
Just need to keep in mind that these are not indirect bounces in the pass then.
|
|
The main loop only handles transparent intersections from the camera ray.
Therefore we can simplify some things.
* Avoid PATH_RAY_CAMERA check, this is always true.
* Avoid path_state_next() call, we can just set transparent flag and increase transparent bounces. This way we avoid the function call and some branching.
Also remove debug num_ray_bounces++, this is incorrect here as no indirect bounce happens here.
Should be no functional changes.
|
|
|
|
Code there started becoming a bit too big, by splitting it up it'll make it
easier to do improvements or extending the features in there.
The layout is not totally final yet, would need to try de-duplicating parts
of code from split kernel with non-split integrators,
|
|
The issue was caused by using NotificationCenter which is only available
since 10.9 so trying to build blender on OSX with 10.7 SDK would fail.
Now it should be possible to build blender with SDK 10.7 and at the same
time official builds should still be doing proper weak-linking to a
notification center.
|
|
crashes Blender
Older OSX has major issues with sincos() function, it's likely a big in OSL
or LLVM. For until we've updated to new versions of this libraries we'll use
a workaround to prevent possible crashes on all the platforms.
Shouldn't be that bad because it's mainly used for anisotropic shader where
angle is usually constant.
This fix is safe for inclusion into final Blender 2.75 release.
|
|
|
|
Glass BSDF was doing some magic with copying weigths from initial closure
onto refraction one and the code was not checking properly for the number
of closures.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ray intersection
TODO: We might want to refactor debug passes into PASS_DEBUG and some
debug_type (similar to Blender's side passes) to avoid issue of running
out of bits.
|
|
|
|
They're working just fine on AMD Tonga GPU and probably other architectures,
lets enable it under the experimental feature set and see what exact system
configuration gives issues.
|
|
This way we can avoid building the split kernel with NODE_FEATURE_BUMP enabled, in case we don't need it.
|
|
This simplification is safe, as the call to volume_phase_eval() is guarded behind a CLOSURE_IS_PHASE check, which is equal to
CLOSURE_VOLUME_HENYEY_GREENSTEIN_ID. I don't think we will add more phase functions anytime soon, if at all.
|
|
This way it is now possible to select which exact debug pass is to be used
by the render engine. Accessible from the Passes panel.
Currently it could only be one debug pass, in the future we can make menus
and image users smarter and support multiple passes of the same type.
|
|
Quite straightforward implementation, but still needs some work for the split
kernel. Includes both regular and split kernel implementation for that.
The pass is not exposed to the interface yet because it's currently not really
easy to have same pass listed in the menu multiple times.
|
|
This way it could be used for the shader/baking kernels easily n the future.
making those kernels more optimal.
|
|
Round-up was only enabled for viewport render, which was for a long time hardcoded to
use 64 closures. This was done in order to avoid unnecessary kernel re-compilations
when tweaking the shader tree.
We could enable selective closure compilation in the viewport later if it'll give
measurable speed improvements, but even then round-up is to happen outside of the
device level,
This commit also removes early output which happened in cases when max closure did
not change. It was wrong because other requested kernel features might have been
changed.
|
|
Those features are not selectively compiled, so there's no real benefit of hiding
them under the experimental feature set.
|
|
This features are now based on the scene settings, so scenes without those features
used are rendered even faster.
This gives about 30% speedup on the AMD A10 APU here, but at the same time it does
not mean such an improvement will happen on all the hardware. That being said, the
Tonga device here seems to have no measurable difference.
In any case it seems handy to have for the future, when we'll want to support SSS
in the kernel or to port selective compilation/split kernel to CUDA devices.
|
|
|
|
For now it's just generic information, still need to expose memory, workgorup
sizes and so on.
|
|
Was missing feature detection in the BumpNode in the previous selective nodes
compilation commit.
|
|
The issue was caused by the reshuffle needed to make objects flags have proper
object's bounding box to solve regressions in SSS objects intersecting volumes.
There's actually a feedback loop happening here, which is now solved in quite
naive way -- for the true displacement we consider all objects are capable of
intersecting volumes, synchronize object flags prior to displacement shader
tasks runs and then re-update object flags for proper bounding box.
Not sure what will be the proper solution here, we can't do preliminary check
of intersection for displacement shader, but on the other hand we don't really
need this flag for displacement shader anyway.
|
|
things. * SSS falloff now works.
|
|
|
|
|
|
|
|
This will help figuring out cases when node was not properly handled by the SVM
by aborting execution on CPU, where all the nodes are expected to be supported.
|
|
This commits finishes initial selective nodes compilation into kernel, which
helps a lot performance-wise for AMD OpenCL kernels.
Split by node groups is based on statistics from simple scenes like BMW and
more complex scenes like mango and gooseberry production files. Further
tweaks are always possible, but it should be a good starting point.
TODO: Still need to ignore unused nodes when calculating requested shader
features.
|
|
|
|
|
