Commit Graph

85055 Commits

Author SHA1 Message Date
Campbell Barton
e53676a5c7 Cleanup: use iterator macros for event handlers 2019-02-20 09:38:33 +11:00
Campbell Barton
c1c01f062e BLI_listbase: add an iterator macro that supports removal
Avoids manually defining 'for' loops that store the next item in the
linked list.
2019-02-20 09:38:33 +11:00
Dalai Felinto
0e7409d466 EEVEE Shader comments: Explain why material gets darkened when using mix shader
We are still ditching the specular intensity of SSR (ssr_data.xyz).
But at least now there is some comment about it.

See T61704 for user reports on that matter.

Comments with the blessing of Clément Foucault.
2019-02-19 18:51:14 -03:00
Campbell Barton
a10dc319ca Comment: clarify reason for using scale as size 2019-02-20 08:27:15 +11:00
Campbell Barton
39afc2775f Cleanup: style 2019-02-20 08:27:01 +11:00
Dalai Felinto
6c0cbfcd53 Fix T61696: Filepath buttons not accepting empty values
The reported case was with the render output filename,
however the same was happening for file open.

Bug introduced on c20c203b82260c06888c2a535c08ec383923ee8a.
I can't find in the original commit any reasoning for the change
that introduced this bug.
2019-02-19 17:24:10 -03:00
e2a90b8045 Merge branch 'blender2.7' 2019-02-19 19:00:46 +01:00
Sebastian Parborg
2be29999bd Fix T61701: Orthographic Viewpoints Hidden Grid
If all axis and grid options were turned off, the grid in the main ortho views would not be rendered.
Now we force rendering of the grid regardless of the settings when in one of the main ortho views.

Reviewed By: Brecht Van Lommel

Differential Revision: https://developer.blender.org/D4378
2019-02-19 18:53:15 +01:00
Philipp Oeser
81aa2a93e9 Fix T61274: duplicate current workspace makes the workspace menu disappear.
Differential Revision: https://developer.blender.org/D4321
2019-02-19 18:43:32 +01:00
Gaia Clary
df8bd07313 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.
2019-02-19 17:49:54 +01:00
Jeroen Bakker
667033e89e 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
2019-02-19 16:34:55 +01:00
Jeroen Bakker
15edda3a8e 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
2019-02-19 16:33:50 +01:00
Jeroen Bakker
e6f5632eb1 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
2019-02-19 16:28:25 +01:00
Jeroen Bakker
d6d306441f 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
2019-02-19 16:25:48 +01:00
Jacques Lucke
c598ad9ac6 FCurves: Remember active fcurve when selecting other bone
Reviewers: brecht

Differential Revision: https://developer.blender.org/D4312
2019-02-19 15:59:09 +01:00
Sergey Sharybin
13f28798de 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.
2019-02-19 15:56:00 +01:00
Jacques Lucke
7c53bca1dd Fix T61702: obmat used incorrectly when calculating constant detail size
Reviewers: brecht

Differential Revision: https://developer.blender.org/D4372
2019-02-19 15:52:49 +01:00
Sebastian Parborg
655eb8eabd 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
2019-02-19 15:45:40 +01:00
38f0d5f75a 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.
2019-02-19 15:40:04 +01:00
Vaishnav S
22eeae8104 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
2019-02-19 15:23:46 +01:00
Bastien Montagne
cba447966e 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.
2019-02-19 13:49:54 +01:00
8138eb0dfe Fix Cycles OpenCL multithreaded compilation not working on Windows. 2019-02-19 13:48:56 +01:00
Sergey Sharybin
4df8896062 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.
2019-02-19 13:08:22 +01:00
Sergey Sharybin
bab2d2ba43 Fix T61594: Frame playback is blank
Viewport and scissor were never initialized prior to
window move/resize.
2019-02-19 13:01:36 +01:00
Bastien Montagne
a8bbe140fd Cleanup: remove needless comment ;) 2019-02-19 10:23:23 +01:00
Jeroen Bakker
84a5abdb31 Merge branch 'blender2.7' 2019-02-19 08:05:15 +01:00
Jeroen Bakker
ecd66f69e7 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
2019-02-19 07:48:51 +01:00
Campbell Barton
eb4acd5064 Cleanup: return specific handler types 2019-02-19 16:57:36 +11:00
Campbell Barton
e617e6395b Cleanup: remove unused default handler type 2019-02-19 16:18:58 +11:00
Campbell Barton
bb6692be8a WM: move keymap handler to it's own type
Illuminate dead code, using wmEventHandler_KeymapFn from gizmo handler
type where it was never set.
2019-02-19 16:18:23 +11:00
Campbell Barton
d718338828 WM: move dropbox handler to it's own type 2019-02-19 16:17:21 +11:00
Campbell Barton
f88ea20285 WM: move operator handler to it's own type 2019-02-19 16:17:21 +11:00
Campbell Barton
eae2942474 WM: move UI handler to it's own type 2019-02-19 16:17:21 +11:00
Campbell Barton
55ac296358 WM: move gizmo handler to it's own type 2019-02-19 16:17:21 +11:00
Campbell Barton
0767b63f1b WM: move wmEventHandler.type to a boolean
Currently it's effectively a boolean for file-select handlers.

Prepare for refactoring event handlers into their own types (keymap,
operator, gizmo, ui & dropbox) to help make logic easier to follow.
2019-02-19 16:14:51 +11:00
Campbell Barton
790cb7799d Cleanup: rename parent_origin_eval to parent_display_origin
The term 'eval' is often used by depsgraph result,
where this is just used for drawing.
2019-02-19 11:38:25 +11:00
Campbell Barton
ec57d76db8 Fix edit-curve display for hidden handles
When the first handle was hidden, all others would show as hidden too.
2019-02-19 10:04:15 +11:00
Campbell Barton
53e95a982c Cleanup: remove unused Object.smoothresh 2019-02-19 09:50:00 +11:00
Campbell Barton
53b484d081 DNA: rename select_color -> select_id
The term color is misleading, it's an integer id that happens to be
written to a color in some cases, then converted back to an integer.
2019-02-19 09:45:48 +11:00
Campbell Barton
fc10e89918 DNA: rename Object.col -> color
Was confusing, unrelated to:
colbits, col_mask, col_group, actcol & totcol.
2019-02-19 08:48:15 +11:00
Bastien Montagne
ecdd1864d1 Fix (unreported) broken-by-design code in depsgraph's deg_backup_object_runtime()
Committing this since it does fix broken logic (previously in that
condition obdata would always be set to NULL, since
`BKE_object_runtime_reset()` is called before).

However, this has presumably been broken that way since 05/2018, so
maybe that whole condition is not needed anymore? Or NULL pointer was
working as well here?

@sergey eyes are required here I guess ;)
2019-02-18 18:21:44 +01:00
Bastien Montagne
16a290bb6f Fix Object bbox memleak in depsgraph code.
Caused by rBae2b677dcb5a70f5, Object.runtime has lot of weird specific
handlings in depsgraph...

For now modified `deg_backup_object_runtime()` and
`deg_restore_object_runtime()` to mimic previous behavior regarding
Object bbox (i.e. pass it around, instead of wiping it clean).

Reported in T61660.
2019-02-18 18:15:00 +01:00
Bastien Montagne
49c7b34547 Cleanup some Object's bbox code.
Now that bbox is in runtime, no need to explicitely clear it when we
call BKE_object_runtime_reset() two lines below.
2019-02-18 17:55:44 +01:00
Bastien Montagne
aed631fa47 Fix (unreported) wrong handling of some parameters combination in bpy.data.user_map()
Would add undesired keys...
2019-02-18 17:16:33 +01:00
Bastien Montagne
1414c4496c ID Management Py API: Fix (unreported) crash in some cases.
Would crash when passing some kind of invalid parameters, e.g.:

   >>>D.user_map(key_types={'brush'})
2019-02-18 17:16:33 +01:00
Bastien Montagne
b8ec2c9559 ID management: use FOREACH_MAIN_ID in some places. 2019-02-18 17:16:33 +01:00
Bastien Montagne
b36f78abf4 ID management: use FOREACH_MAIN_ID in some places. 2019-02-18 17:16:33 +01:00
Bastien Montagne
4977321c5a ID management: use FOREACH_MAIN_ID in some places. 2019-02-18 17:16:33 +01:00
Bastien Montagne
ff7165957f ID management: use FOREACH_MAIN_ID in some places. 2019-02-18 17:16:33 +01:00
Bastien Montagne
0951778eba ID management: use FOREACH_MAIN_ID in some places. 2019-02-18 17:16:33 +01:00