Title says it all, based on feedback of artists from gooseberry team.
This mainly affects cases when going to a local view from layers setup
when some lamps were on invisible layers. Those lights are no longer
becoming visible to the object in local view.
Reviewers: brecht, juicyfruit, dingto
Reviewed By: juicyfruit, dingto
Subscribers: maxon, eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1326
The issue was caused by non-continuous tangent space calculated for triangles.
This commit adds a Tangent input to Hair BSDF node which can be used to hook up
Tangent calculated form UV as an input to the node in order to make sure the
tangent space is continuous.
Doing this as an input instead of using default tangent layer from UV because of
several reasons:
- This way it's really easy to preserve compatibility with existing setups.
- Default UV map is not necessarily giving continuous space, one might want to
use other tangent space sources or distort the space for some artistic
decision.
Reviewers: juicyfruit, dingto
Reviewed By: dingto
Differential Revision: https://developer.blender.org/D1428
Currently only image loading benefits of this and will give magenta color
when image manager detects it's running out of memory.
This isn't ideal solution and can't handle all cases. For example, OOM
killer might kill process before it realized it run out of memory, but
in other cases this could prevent some crashes.
Reviewers: juicyfruit, dingto
Differential Revision: https://developer.blender.org/D1502
Currently OpenCL devices are packing images into a single texture,
which means technically number of textures is not limited here.
Now OpenCL will use same number of textures as CPU. If we want
to bump number of textures further, this values are to be modified
in sync.
NOTE OpenCL still does not support float textures.
Original patch from a guy called bliblubli in the tracker with
some own modifications.
Reviewers: brecht, dingto, sergey
Differential Revision: https://developer.blender.org/D1530
Ray direction is assumed to be normalized in such areas as scaling intersection
distance on instance push/pop when doing ray-scene intersection, but it was
possible that some closures wouldn't give normalized direction which could cause
wrong intersection checks.
Now normalization will happen on surface bounce, which could be a bit of a waste
if closure actually gives normalized direction, but currently only transparent
BSDF seems to give guaranteed normalized direction.
Issue was caused by wrong intersection distance scaling on instance pop,
which could cause intersection distance to become zero, confusing following
intersection checks.
This commit exposes the interpolation parameter for environment textures (requested by DolpheenDream on IRC), just as it already is for image textures.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1544
Issue was caused by changed function signature. This is still not really full
support of new OSL API since we don't store anything in the derivatives which
could confuse mipmapping.
Notes:
- There is still some bvh cache code, but that is from the engines initial commit, we might clean this up further or keep it.
- Changes in util_cache.h/.c are kept, this might be re-used in the future.
This removes the BVH cache feature from the UI, underlying code will be removed in a separate commit.
The BVH cache was added before we had a multi-threaded BVH build, and a lot of other optimizations were done since then, which makes this not useful anymore.
Fix T46162.
So now the following OSL versions are supported (at least for compilation):
- 1.5 with closure alignment patch applied
- 1.6.8 release
- 1.7 development version from latest git
Added some extra seed to the hash, so it's now less likely to give repetitive
patters at values around zero.
This will change distribution of bricks for existing files. but it's something
inevitable.
Epsilon was quite arbitrary for GPU, replaced with checking for zero-sized faces.
It should solve both original report and the new one. After the release we can check
why GPU doesn't produce accurate math here and go to the root of the issue.
Disable Intel cards for until we'll go to the root of the issue of the crash.
This will take a bit, so being so close to the release we go safe and disable
unstable GPU, so blender at least doesn't crash.
This could be bypassed by setting OPENSUBDIV_ALLOW_INTEL environment variable.
