Blender Git Loki

libquery: add new 'BKE_library_idtype_can_use_idtype()' helper.

This should allow us to avoid a lot of useless processing when iterating over the
whole main database (unlink/remap/usages checks/etc.).

Note that some ID types report they can use any type for now, due to
fuzzyness/indefined nature of some usages (like constraints/modifiers/game logic,
or ID pointer of nodes...). Maybe we could address this (like e.g. adding defines
in relevant headers to restrict ID types used by constraints, by modifiers, etc.).
But don?t think this is top priority for now.

Cleanup/fix animsys 'id_type_can_have_animdata()'.

This func now actually takes an ID type as argument, added new 'id_can_have_animdata()'
to check whether a datablock may be animated or not.

Extend libquery checks to test wether an ID is used locally and/or indirectly.

Fix T48793: Bilinear filter clamps at edge pixels

Fix single threaded compositor define

Cycles: Enable unaligned BVH builder for scenes with hair

This commit enables new unaligned BVH builder and traversal for scenes
with hair. This happens automatically, no need of manual control over
this.

There are some possible optimization still to happen here and there,
but overall there's already nice speedup:

Master Hair BVH
bunny.blend 8:06.54 5:57.14
victor.blend 16:07.44 15:37.35

Unfortunately, such more complexity is not really coming for free,
so there's some downsides, but those are within acceptable range:

Master Hair BVH
classroom.blend 5:31.79 5:35.11
barcelona.blend 4:38.58 4:44.51

Memory usage is also somewhat bigger for hairy scenes, but speed
benefit pays well for that. Additionally as was mentioned in one
of previous commits we can add an option to disable hair BVH and
have similar render time but have memory saving.

Reviewers: brecht, dingto, lukasstockner97, juicyfruit, maiself

Differential Revision: https://developer.blender.org/D2086

Cycles: Implement unaligned nodes BVH traversal

This commit implements traversal of unaligned BVH nodes.

QBVH traversal is fully SIMD optimized and calculates orientation
for all 4 children at a time, regular BVH might probably be optimized
a bit more.

Cycles: Implement unaligned nodes BVH builder

This is a special builder type which is allowed to orient nodes to
strands direction, hence minimizing their surface area in comparison
with axis-aligned nodes. Such nodes are much more efficient for hair
rendering.

Implementation of BVH builder is based on Embree, and generally idea
there is to calculate axis-aligned SAH and oriented SAH and if SAH
of oriented node is smaller than axis-aligned SAH we create unaligned
node.

We store both aligned and unaligned nodes in the same tree (which
seems to be different from what Embree is doing) so we don't have
any any extra calculations needed to set up hair ray for BVH
traversal, hence avoiding any possible negative effect of this new
BVH nodes type.

This new builder is currently not in use, still need to make BVH
traversal code aware of unaligned nodes.

Cycles: Switch node address to absolute values in BVH tree

This seems to be straightforward way to support heterogeneous nodes
in the same tree.

There is some penalty related on 4gig limit of the address space now,
but here's are the thing:

Traversal code was already using ints to store final offset, so
there can't be regressions really.

This is a required commit to make it possible to encode both aligned
and unaligned nodes in the same array. Also, in the future we can use
this to get rid of __leaf_nodes array (which is a bit tricky to do since
trickery in pack_instances().

Cycles: Reduce memory usage by de-duplicating triangle storage

There are several internal changes for this:

First idea is to make __tri_verts to behave similar to __tri_storage,
meaning, __tri_verts array now contains all vertices of all triangles
instead of just mesh vertices. This saves some lookup when reading
triangle coordinates in functions like triangle_normal().

In order to make it efficient needed to store global triangle offset
somewhere. So no __tri_vindex.w contains a global triangle index which
can be used to read triangle vertices.

Additionally, the order of vertices in that array is aligned with
primitives from BVH. This is needed to keep cache as much coherent as
possible for BVH traversal. This causes some extra tricks needed to
fill the array in and deal with True Displacement but those trickery
is fully required to prevent noticeable slowdown.

Next idea was to use this __tri_verts instead of __tri_storage in
intersection code. Unfortunately, this is quite tricky to do without
noticeable speed loss. Mainly this loss is caused by extra lookup
happening to access vertex coordinate.

Fortunately, tricks here and there (i,e, some types changes to avoid
casts which are not really coming for free) reduces those losses to
an acceptable level. So now they are within couple of percent only,

On a positive site we've achieved:

- Few percent of memory save with triangle-only scenes. Actual save
in this case is close to size of all vertices.

On a more fine-subdivided scenes this benefit might become more
obvious.

- Huge memory save of hairy scenes. For example, on koro.blend
there is about 20% memory save. Similar figure for bunny.blend.

This memory save was the main goal of this commit to move forward
with Hair BVH which required more memory per BVH node. So while
this sounds exciting, this memory optimization will become invisible
by upcoming Hair BVH work.

But again on a positive side, we can add an option to NOT use Hair
BVH and then we'll have same-ish render times as we've got currently
but will have this 20% memory benefit on hairy scenes.

Cycles: Support visibility check for inner nodes of QBVH

It was initially unsupported because initial idea of checking visibility
of all children was slowing scenes down a lot. Now the idea has changed
and we only perform visibility check of current node. This avoids huge
slowdown (from tests here it seems to be withing 1-2%, but more tests
would never hurt) and gives nice speedup of ray traversal for complex
scenes which utilized ray visibility.

Here's timing of koro.blend:

Without visibility check With visibility check
Original file 4min 20sec 4min 23sec
Camera rays only 1min 43 sec 55sec

Unfortunately, this doesn't come for free and requires extra data in
BVH node, which increases memory usage of BVH nodes by 15%. This we
can solve with some future trickery of avoiding __tri_storage created
for curve segments.

Quiet gcc warning-as-error about non-const pointer passed to const parameter.

Fix T48802 Unwrap buttons, can't add hotkey in 3DView's UV Unwrap menu.

Those unwrap operators are a bit tricky, some are available from both 3DView and UVEditor, others only from 3DView...

Hacked around this by returning Mesh keymap for UV_OT ops for specific 3DView/MeshEditMode context.

RNA: rename sorting -> sort

Shorter and consistent with other RNA.

Skip the ID part of object names when comparing

Also no need to calloc arrays which are immediately filled

Cleanup: spelling, style

Cleanup: use static sets, remove redundant copy

Revert "ChildOf Constraint: Hide the Loc/Rot/Scale toggles"

This reverts commit 4fd78bb06faa31f265af6a5f247cf4255b5ac479.

After further testing, it turns out that these options are less-broken than
I remember them being (and have been hearing about). Specifically, as long
as you disable all 3-axes of a transform component (i.e. all location, all
rotation, all scale) you're not likely to have problems, whereas if you only
disabled one axis (i.e. y-rotation), you may have problems in some cases.

So, restoring these to the UI.

Code Cleanup - Split out the FCurve auto-color code into a separate function

Fix T48747: Stuck in edit mode after selecting another object in the animation editors