Blender Git Statistics -> Developers -> jbakker

Jeroen Bakker (jbakker)

Total Commits : 539
Master Commits : 385
Branch Commits : 154
First Commit : July 4, 2011
Latest Commit : February 19, 2019 (Today)

Commits by Month

DateNumber of Commits
February, 20196
January, 20190
December, 20180
November, 20180
October, 20180
September, 20181
August, 20184
July, 201810
June, 2018101
May, 201880
April, 201884
March, 20181
February, 20180
January, 20180
December, 20170
November, 20170
October, 20170
September, 20172
August, 20170
July, 20170
June, 20170
May, 20170
April, 20170
March, 20170
February, 20170
January, 20170
December, 20160
November, 20160
October, 20160
September, 20160
August, 20160
July, 20160
June, 20163
May, 20164
April, 20160
March, 20160
February, 20160
January, 20160
December, 20150
November, 20150
October, 20150
September, 20150
August, 20150
July, 20150
June, 20152
May, 20150
April, 20150
March, 20150
February, 20151
January, 20151
December, 20140
November, 20140
October, 20140
September, 20146
August, 20143
July, 201417
June, 20140
May, 20145
April, 20142
March, 20141
February, 20140
January, 20140
December, 20136
November, 20130
October, 20132
September, 20130
August, 20130
July, 20130
June, 20132
May, 20130
April, 20131
March, 20130
February, 20134
January, 20130
December, 20120
November, 20120
October, 20128
September, 20124
August, 20125
July, 201226
June, 201227
May, 201252
April, 201230
March, 20120
February, 20129
January, 201210
December, 20117
November, 20112
October, 20110
September, 20110
August, 20113
July, 20117

Commit Distribution

PathNumber of Commits
master383
temp-outliner-visibility253
interactive_physics253
hair_object253
collada2.8253
blender2.8_snap_gizmo253
temp-ui-layout-2.8253
temp-select-axis251
temp-udim-images248
hair_guides_grooming248
hair_guides248
temp-benchmark248
soc-2018-cycles-volumes248
benchmark248
soc-2018-bevel248
tmp_hair_curves246
temp-eeveelightcache246
temp-greasepencil-vfx246
temp-sybren-cow-ocean246
temp-tab_drag_drop238
temp-dynamic-overrides220
temp-greasepencil-object-stacksplit206
TEMP-UI-DECOR194
temp-flexible-spacing165
ui_layout_gridflow164
temp-keymap-changes157
tmp-CollectionsAnim146
tmp-b28-motionpath-drawing144
temp-keymap-save133
temp-unified-collections110
tmp-COW_InsertKeyframe_Fix110
experimental_gp_weight108
temp-sybren-particles108
blender2.8-workbench106
topbar96
tmp-TimelineHeaderButtonsStretching96
temp-modifier-rm-cddm95
temp-sybren-modifier-nonmesh94
temp-sybren-meshdeform91
tile89
blender2.8-snapping_with_occlusion89
tmp-static-override-insertion85
blender-tiles31
compositor-20167
tiles-scheduler5
blender2.72
temp-fracture-modifier-2.81
blender-v2.79b-release1
blender-v2.79a-release1
blender-v2.79-release1
blender-v2.75-release1
fracture_modifier-master1
fracture_modifier1

Favourite Files

FilenameTotal Edits
workbench_materials.c70
rna_space.c69
space_view3d.py53
workbench_private.h52
DNA_view3d_types.h46
CMakeLists.txt41
studiolight.c40
versioning_280.c31
COM_VariableSizeBokehBlurOperation.cpp25
workbench_forward.c25

File Changes

ActionTotalPer Commit
Added1 1732.2
Modified3 5356.6
Deleted990.2

Code Changes

ActionTotalPer Commit
Lines Added31 98869.2
Lines Removed14 49131.4

Latest commits Feed

Revision 667033e by Jeroen Bakker (master)
8 hours 20 min ago
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
Revision 15edda3 by Jeroen Bakker (master)
8 hours 21 min ago
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
Revision e6f5632 by Jeroen Bakker (master)
8 hours 26 min ago
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
Revision d6d3064 by Jeroen Bakker (master)
8 hours 29 min ago
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
Revision 84a5abd by Jeroen Bakker (master)
16 hours 50 min ago
Merge branch 'blender2.7'
Revision ecd66f6 by Jeroen Bakker (master)
17 hours 6 min ago
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
Revision 3da46a8 by Jeroen Bakker / Alexander Gavrilov (master)
September 27, 2018, 14:33 (GMT)
Implement a new dedicated weight painting shader.

Move the weight paint drawing to the fragment shader. The shader
uses a texture that uses the U.coba_weight custom color band, or
an internal color band.

In addition to actual weights, the shader has to display two
alert colors: missing vertex group, and zero weight. The zero
weight alert has to be blended with regular weight colors,
so that a single alert vertex surrounded by weighted ones is
still visible.

Reviewers: campbellbarton, fclem

Differential Revision: https://developer.blender.org/D3675
Revision b8c9df6 by Jeroen Bakker (master)
August 24, 2018, 08:04 (GMT)
Compositor: Added Weighted Standard Curve evaluation

Available in RGB Curve node in the compositor and as modifier in the
sequencer. I reshuffled the values of the enum. But a the first commit
is just 1 day old I think that the order is more important than the file
compatibility.
Revision 4de7c0c by Jeroen Bakker (master)
August 23, 2018, 09:39 (GMT)
Compositor: Film-like curve

Film-like curves for the RGB Curve node (Compositor) and Curve Modifier
(Sequencer)

Film-like curves originated from Adobe.
"It?s an RGB curve where the tone curve is applied on the largest and smallest value, and then the middle value is adapted to keep a constant hue as defined by RGB-HSL/HSV. In terms of look and saturation increase it?s very similar to a pure RGB curve, more so than a HSL-L curve or HSV-V curve, but some color shift problems are avoided."

Other tools like Natron, Krita and RawTherapee have implemented this curve tone.

Reviewers: brecht, campbellbarton

Reviewed By: brecht

Tags: #compositing, #video_sequencer

Differential Revision: https://developer.blender.org/D3638
Revision acc4507 by Jeroen Bakker (master)
August 21, 2018, 09:00 (GMT)
Workbench: Support XRay rendering in OpenGL

OpenGL rendering only implemented the deferred renderer. This commit
will add the forward renderer. The forward renderer is used when XRay
mode is enabled

MiikaHweb - Blender Git Statistics v1.06
By: Miika HämäläinenLast update: Nov-07-2014 14:18 MiikaHweb | 2003-2019