| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
source/blender/modifiers/intern/MOD_wireframe.c
|
|
This was caused by recent pass refactoring from f78e963.
|
|
|
|
Previously only scalar displacement along the normal was supported,
now displacement can go in any direction. For backwards compatibility,
a Displacement node will be automatically inserted in existing files.
This will make it possible to support vector displacement maps in the
future. It's already possible to use them to some extent, but requires
a manual shader node setup. For tangent space maps the right tangent
may also not be available yet, depends on the map.
Differential Revision: https://developer.blender.org/D3015
|
|
This converts object space height to world space displacement, to be
linked to the new vector displacement material output.
Differential Revision: https://developer.blender.org/D3015
|
|
|
|
This was we can introduce other types of BVH, for example, wider ones, without
causing too much mess around boolean flags.
Thoughs:
- Ideally device info should probably return bitflag of what BVH types it
supports.
It is possible to implement based on simple logic in device/ and mesh.cpp,
rest of the changes will stay the same.
- Not happy with workarounds in util_debug and duplicated enum in kernel.
Maybe enbum should be stores in kernel, but then it's kind of weird to include
kernel types from utils. Soudns some cyclkic dependency.
Reviewers: brecht, maxim_d33
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3011
|
|
|
|
Also try to move them from headers to implementation files as much as possible.
|
|
|
|
The displacement shared was running before particle data was copied to the
device causing bad memory access when the particle info node was used. Fix
is simply to move particle update before mesh update so the data is
available to displacement shaders.
(Altho this fixes the crash the particle info node is still mostly useless
with displacement for now...)
|
|
|
|
|
|
|
|
Adds the code to get screen size of a point in world space, which is
used for subdividing geometry to the correct level. The approximate
method of treating the point as if it were directly in front of the
camera is used, as panoramic projections can become very distorted
near the edges of an image. This should be fine for most uses.
There is also no support yet for offscreen dicing scale, though
panorama cameras are often used for rendering 360° renders anyway.
Fixes T49254.
Differential Revision: https://developer.blender.org/D2468
|
|
|
|
|
|
This can be enabled in the Film panel, with an option to control the
transmisison roughness below which glass becomes transparent.
Differential Revision: https://developer.blender.org/D2904
|
|
The offscreen dicing scale helps to significantly reduce memory usage,
by reducing the dicing rate for objects the further they are outside of
the camera view.
The dicing camera can be specified now, to keep the geometry fixed and
avoid crawling artifacts in animation. It is also useful for debugging,
to see the tesselation from a different camera location.
Differential Revision: https://developer.blender.org/D2891
|
|
|
|
This was disabled previously due to CUDA compiler bugs, see T32900.
Differential Revision: https://developer.blender.org/D2937
|
|
|
|
Fixes a few corner cases found while stress testing host mapped memory.
|
|
|
|
|
|
|
|
|
|
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D2920
|
|
No color pass because it's hard to define what to use as color in a volume.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D2903
|
|
passes
|
|
Considerable non-trivial merge conflict fixes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goal is to reduce OpenCL kernel recompilations.
Currently viewport renders are still set to use 64 closures as this seems to
be faster and we don't want to cause a performance regression there. Needs
to be investigated.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2775
|
|
|
|
The algorithm averages normals from nearby surfaces. It uses the same
sampling strategy as BSSRDFs, casting rays along the normal and two
orthogonal axes, and combining the samples with MIS.
The main concern here is that we are introducing raytracing inside
shader evaluation, which could be quite bad for GPU performance and
stack memory usage. In practice it doesn't seem so bad though.
Note that using this feature can easily slow down renders 20%, and
that if you care about performance then it's better to use a bevel
modifier. Mainly this is useful for baking, and for cases where the
mesh topology makes it difficult for the bevel modifier to work well.
Differential Revision: https://developer.blender.org/D2803
|
|
|
|
|
|
This causes some difference in the classroom scene, where ray visibility
tricks are used and break the MIS balance. Otherwise there doesn't seem
to be much effect, but better to use the right formulas. Problem originally
identified by Lukas.
|
|
|
|
|
|
Conflicts:
intern/cycles/device/device.cpp
source/blender/blenkernel/intern/library.c
source/blender/blenkernel/intern/material.c
source/blender/editors/object/object_add.c
source/blender/editors/object/object_relations.c
source/blender/editors/space_outliner/outliner_draw.c
source/blender/editors/space_outliner/outliner_edit.c
source/blender/editors/space_view3d/drawobject.c
source/blender/editors/util/ed_util.c
source/blender/windowmanager/intern/wm_files_link.c
|
|
|
|
|
|
|
