Blender Git Loki

fix: Collada replace <polylist> export by <triangle> export for triangulated meshes.

This is a regression from Blender 2.79 where the usage
of <triangles> was already implemented, but unintentionally
removed in Blender 2.80

Also renamed variables for better reading.

T61463: Separate Baking kernels

Cycles OpenCL: Split baking kernels in own program

Fix T61463. Before this patch baking was part of the base kernels. There
are 3 baking kernels that and all 3 uses shader evaluation. Only for one
of these kernels the functionality was wrapped in the __NO_BAKING__
compile directive.

When you start baking this leads to long compile times. By separating
in individual programs will reduce the compile times.

Also wrapped all baking kernels with __NO_BAKING__ to reduce the
compilation times.

Impact on compilation time

job | scene_name | previous | new | percentage
--------+-----------------+----------+-------+------------
T61463 | empty | 10.63 | 7.27 | 32%
T61463 | bmw | 17.91 | 14.24 | 20%
T61463 | fishycat | 19.57 | 15.08 | 23%
T61463 | barbershop | 54.10 | 48.18 | 11%
T61463 | classroom | 17.55 | 14.42 | 18%
T61463 | koro | 18.92 | 17.15 | 9%
T61463 | pavillion | 17.43 | 14.23 | 18%
T61463 | splash279 | 16.48 | 15.33 | 7%
T61463 | volume_emission | 36.22 | 34.19 | 6%

Impact on render time

job | scene_name | previous | new | percentage
--------+-----------------+----------+---------+------------
T61463 | empty | 21.06 | 20.54 | 2%
T61463 | bmw | 198.44 | 189.59 | 4%
T61463 | fishycat | 394.20 | 388.50 | 1%
T61463 | barbershop | 1188.16 | 1185.49 | 0%
T61463 | classroom | 341.08 | 339.27 | 1%
T61463 | koro | 472.43 | 360.70 | 24%
T61463 | pavillion | 905.77 | 902.14 | 0%
T61463 | splash279 | 55.26 | 54.92 | 1%
T61463 | volume_emission | 62.59 | 39.09 | 38%

I don't have a grounded explanation why koro and volume_emission is this much
faster; I have done several tests though...

Maniphest Tasks: T61463

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

T61463: Separate Baking kernels

Cycles OpenCL: Split baking kernels in own program

Fix T61463. Before this patch baking was part of the base kernels. There
are 3 baking kernels that and all 3 uses shader evaluation. Only for one
of these kernels the functionality was wrapped in the __NO_BAKING__
compile directive.

When you start baking this leads to long compile times. By separating
in individual programs will reduce the compile times.

Also wrapped all baking kernels with __NO_BAKING__ to reduce the
compilation times.

Impact on compilation time

job | scene_name | previous | new | percentage
--------+-----------------+----------+-------+------------
T61463 | empty | 10.63 | 7.27 | 32%
T61463 | bmw | 17.91 | 14.24 | 20%
T61463 | fishycat | 19.57 | 15.08 | 23%
T61463 | barbershop | 54.10 | 48.18 | 11%
T61463 | classroom | 17.55 | 14.42 | 18%
T61463 | koro | 18.92 | 17.15 | 9%
T61463 | pavillion | 17.43 | 14.23 | 18%
T61463 | splash279 | 16.48 | 15.33 | 7%
T61463 | volume_emission | 36.22 | 34.19 | 6%

Impact on render time

job | scene_name | previous | new | percentage
--------+-----------------+----------+---------+------------
T61463 | empty | 21.06 | 20.54 | 2%
T61463 | bmw | 198.44 | 189.59 | 4%
T61463 | fishycat | 394.20 | 388.50 | 1%
T61463 | barbershop | 1188.16 | 1185.49 | 0%
T61463 | classroom | 341.08 | 339.27 | 1%
T61463 | koro | 472.43 | 360.70 | 24%
T61463 | pavillion | 905.77 | 902.14 | 0%
T61463 | splash279 | 55.26 | 54.92 | 1%
T61463 | volume_emission | 62.59 | 39.09 | 38%

I don't have a grounded explanation why koro and volume_emission is this much
faster; I have done several tests though...

Maniphest Tasks: T61463

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

T61513: Refactored Cycles Attribute Retrieval

There is a generic function to retrieve float and float3 attributes
`primitive_attribute_float` and primitive_attribute_float3`. Inside
these functions an prioritised if-else construction checked where
the attribute is stored and then retrieved from that location.

Actually the calling function most of the time already knows where
the data is stored. So we could simplify this by splitting these
functions and remove the check logic.

This patch splits the `primitive_attribute_float?` functions into
`primitive_surface_attribute_float?` and `primitive_volume_attribute_float?`.
What leads to less branching and more optimum kernels.

The original function is still being used by OSL and `svm_node_attr`.

This will reduce the compilation time and render time for kernels.
Especially in production scenes there is a lot of benefit.

Impact in compilation times

job | scene_name | previous | new | percentage
-------+-----------------+----------+-------+------------
t61513 | empty | 10.63 | 10.66 | 0%
t61513 | bmw | 17.91 | 17.65 | 1%
t61513 | fishycat | 19.57 | 17.68 | 10%
t61513 | barbershop | 54.10 | 24.41 | 55%
t61513 | classroom | 17.55 | 16.29 | 7%
t61513 | koro | 18.92 | 18.05 | 5%
t61513 | pavillion | 17.43 | 16.52 | 5%
t61513 | splash279 | 16.48 | 14.91 | 10%
t61513 | volume_emission | 36.22 | 21.60 | 40%

Impact in render times

job | scene_name | previous | new | percentage
-------+-----------------+----------+--------+------------
61513 | empty | 21.06 | 20.35 | 3%
61513 | bmw | 198.44 | 190.05 | 4%
61513 | fishycat | 394.20 | 401.25 | -2%
61513 | barbershop | 1188.16 | 912.39 | 23%
61513 | classroom | 341.08 | 340.38 | 0%
61513 | koro | 472.43 | 471.80 | 0%
61513 | pavillion | 905.77 | 899.80 | 1%
61513 | splash279 | 55.26 | 54.86 | 1%
61513 | volume_emission | 62.59 | 61.70 | 1%

There is also a possitive impact when using CPU and CUDA, but they are small.

I didn't split the hair logic from the surface logic due to:

* Hair and surface use same attribute types. It was not clear if it could be
splitted when looking at the code only.
* Hair and surface are quick to compile and to read. So the benefit is quite
small.

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

T61513: Refactored Cycles Attribute Retrieval

There is a generic function to retrieve float and float3 attributes
`primitive_attribute_float` and primitive_attribute_float3`. Inside
these functions an prioritised if-else construction checked where
the attribute is stored and then retrieved from that location.

Actually the calling function most of the time already knows where
the data is stored. So we could simplify this by splitting these
functions and remove the check logic.

This patch splits the `primitive_attribute_float?` functions into
`primitive_surface_attribute_float?` and `primitive_volume_attribute_float?`.
What leads to less branching and more optimum kernels.

The original function is still being used by OSL and `svm_node_attr`.

This will reduce the compilation time and render time for kernels.
Especially in production scenes there is a lot of benefit.

Impact in compilation times

job | scene_name | previous | new | percentage
-------+-----------------+----------+-------+------------
t61513 | empty | 10.63 | 10.66 | 0%
t61513 | bmw | 17.91 | 17.65 | 1%
t61513 | fishycat | 19.57 | 17.68 | 10%
t61513 | barbershop | 54.10 | 24.41 | 55%
t61513 | classroom | 17.55 | 16.29 | 7%
t61513 | koro | 18.92 | 18.05 | 5%
t61513 | pavillion | 17.43 | 16.52 | 5%
t61513 | splash279 | 16.48 | 14.91 | 10%
t61513 | volume_emission | 36.22 | 21.60 | 40%

Impact in render times

job | scene_name | previous | new | percentage
-------+-----------------+----------+--------+------------
61513 | empty | 21.06 | 20.35 | 3%
61513 | bmw | 198.44 | 190.05 | 4%
61513 | fishycat | 394.20 | 401.25 | -2%
61513 | barbershop | 1188.16 | 912.39 | 23%
61513 | classroom | 341.08 | 340.38 | 0%
61513 | koro | 472.43 | 471.80 | 0%
61513 | pavillion | 905.77 | 899.80 | 1%
61513 | splash279 | 55.26 | 54.86 | 1%
61513 | volume_emission | 62.59 | 61.70 | 1%

There is also a possitive impact when using CPU and CUDA, but they are small.

I didn't split the hair logic from the surface logic due to:

* Hair and surface use same attribute types. It was not clear if it could be
splitted when looking at the code only.
* Hair and surface are quick to compile and to read. So the benefit is quite
small.

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

FCurves: Remember active fcurve when selecting other bone

Reviewers: brecht

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

Fix T57583: Assert when moving object parented to curve vertex

Can not reliably evaluate object's transform from the original one.

Still not ideal, see the comment in the code.

Fix T61702: obmat used incorrectly when calculating constant detail size

Reviewers: brecht

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

Fix T61690: Hidden curve vertices are drawn in edit-mode

When hiding the curve handles/points previously, the control points would still be drawn (loose verts).
Now we hide everything related to the handle if it is hidden.

Reviewed By: Cl�ment Foucault

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

Fix T61714, T61712: crash reloading images after recent changes.

Now that we are looping over all image users that were previously ignored,
it shows some scene pointers are invalid. Always clear them on load, and
don't keep scene permanently in the image user except for the image editor.
Otherwise the pointer can go out of date.

Units: Fix some property subtypes

This commit only contains some of the changes in the diff.
Some require more discussion/work.

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

Fix T61683: Linking the instance of a collection crashes Blender.

Do not instance linked object immediately in scene, this was never a
good idea and is doomed to fail nowadays, with complex relations between
objects, collections and scenes.

Instead, this commit refactors a bit linking code to add loose objects
to current scene *after* everything has been imported, and ID pointers
have been properly remapped to new ones - i.e. once new linked data is
supposed to be fully valid, just like we were already doing with
collections.

As a bonus, it means we do not have to pass around scene, view3d etc. to
`BLO_library_link_named_part_ex()` and co.

Fix Cycles OpenCL multithreaded compilation not working on Windows.

Playanim: Fix heap use after free on exit

Was caused by the wrong de-initialization order, here is
an ASAN log just in case P916.

Fix T61594: Frame playback is blank

Viewport and scissor were never initialized prior to
window move/resize.

Cleanup: remove needless comment ;)

Merge branch 'blender2.7'

Revert "Cycles: Change OpenCL split kernel to use single program by default"

This reverts commit c6bf5d47240cebef356276e369881e855dbe7e6d.

Related to D2264: When multi process opencl kernel compilation is in place single-program compiles slower then multi-program. c6bf5d47240cebef356276e369881e855dbe7e6d was created as single-program compiled faster, but this is not the case anymore. So let's revert this change. Production scenes like victor and barbershop even render quicker.

Change in Cycles OpenCL compilation times

> job | scene_name | compilation_time | render_time
> Baseline | empty | 22.73 | 20.63
> T61514 | empty | 10.63 | 21.06
> Baseline | bmw | 56.44 | 191.00
> T61514 | bmw | 17.91 | 198.44
> Baseline | fishycat | 59.50 | 393.48
> T61514 | fishycat | 19.57 | 394.20
> Baseline | barbershop | 212.28 | 1623.53
> T61514 | barbershop | 54.10 | 1188.16
> Baseline | victor | 67.51 | 1459.80
> T61514 | victor | 22.06 | 1381.58
> Baseline | classroom | 51.46 | 341.23
> T61514 | classroom | 17.55 | 341.08
> Baseline | koro | 62.48 | 475.96
> T61514 | koro | 18.92 | 472.43
> Baseline | pavillion | 54.37 | 903.48
> T61514 | pavillion | 17.43 | 905.77
> Baseline | splash279 | 47.43 | 52.92
> T61514 | splash279 | 16.48 | 55.26
> Baseline | volume_emission | 145.22 | 62.38
> T61514 | volume_emission | 36.22 | 62.59

Reviewers: #cycles, brecht, sergey

Reviewed By: #cycles, brecht

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

Cleanup: return specific handler types

Cleanup: remove unused default handler type