Revision 7398acb by Jacques Lucke (builtin-simulation-nodes, functions, particle-solver-dev, simulation-tree) November 13, 2019, 13:55 (GMT) |
initial group input node |
Revision 16f7804 by Jacques Lucke (builtin-simulation-nodes, functions, particle-solver-dev, simulation-tree) November 13, 2019, 13:23 (GMT) |
bring back Clamp and Map Range nodes |
November 13, 2019, 13:09 (GMT) |
Cleanup: correct mul_v4_v4fl declaration |
November 13, 2019, 13:08 (GMT) |
Cleanup: use int for operator return argument |
Revision ccfe2a2 by Jacques Lucke (builtin-simulation-nodes, functions, particle-solver-dev, simulation-tree) November 13, 2019, 12:48 (GMT) |
initial Closest Point on Object node |
November 13, 2019, 12:02 (GMT) |
Merge branch 'temp-openxr-ghostxr' into temp-openxr-blenderside |
November 13, 2019, 12:02 (GMT) |
Merge branch 'temp-openxr-directx' into temp-openxr-ghostxr |
November 13, 2019, 12:01 (GMT) |
Merge branch 'temp-openxr-buildstuff' into temp-openxr-directx |
November 13, 2019, 12:01 (GMT) |
Merge branch 'master' into temp-openxr-buildstuff |
November 13, 2019, 11:57 (GMT) |
Core XR Support [part 1]: Add OpenXR-SDK dependency and WITH_OPENXR build option Some points on the OpenXR-SDK dependency: * The repository is located at https://github.com/KhronosGroup/OpenXR-SDK (Apache 2). * We use the OpenXR loader lib from it, the headers, and some CMake utilities. * It contains a bunch of generated files, for which the sources are in a separate repository. * To use the injected OpenXR API-layers from the SDK (e.g. API validation layers), the SDK needs to be compiled from this other repository. * We could use that other repo by default, but I'd rather go with the simpler solution and allow people to opt in if they want advanced dev features. * For Windows a patch is needed to link the CRT in a compatible way. All this is entirely untested on macOS. Maniphest Tasks: T71365 Differential Revision: https://developer.blender.org/D6188 |
November 13, 2019, 11:55 (GMT) |
Cycles: OpenCL Performance When using OpenCL with Cycles the rendering time increased substantial. After doing some tests the bottleneck was found in 4d voronoi and 2d and 3d smooth voronoi. This change will hide these behind a specific compile directive so the speed will improve. AMD RX480 + BMW scene 2.80 (3:10) 2.81 (5:48) 2.81 excluding 4d voronoi+2d/3d smooth (3:50) Reviewed By: sergey Differential Revision: https://developer.blender.org/D6231 |
Revision 03d7ba7 by Jacques Lucke (builtin-simulation-nodes, functions, particle-solver-dev, simulation-tree) November 13, 2019, 11:40 (GMT) |
Make Particle Info node a normal function |
Revision 253e046 by Bastien Montagne (undo-experiments, undo-experiments-idnames, undo-experiments-remap-history, undo-experiments-swap-reread-datablocks, uuid-undo-experiments, uuid-undo-experiments-swap-reread-datablocks) November 13, 2019, 11:37 (GMT) |
Merge branch 'master' into undo-experiments |
November 13, 2019, 11:33 (GMT) |
Merge remote-tracking branch 'origin/master' into temp-graph-select-changes |
November 13, 2019, 11:30 (GMT) |
Merge branch 'temp-graph-select-changes' of git.blender.org:blender into temp-graph-select-changes |
Revision 3235d6c by Jacques Lucke (builtin-simulation-nodes, functions, particle-solver-dev, simulation-tree) November 13, 2019, 11:02 (GMT) |
pass MFContext directly |
Revision 4dfc1e9 by Jacques Lucke (builtin-simulation-nodes, functions, particle-solver-dev, simulation-tree) November 13, 2019, 10:53 (GMT) |
pass MFParams directly |
November 13, 2019, 10:49 (GMT) |
Merge branch 'blender-v2.81-release' |
Revision ce59ef0 by Jacques Lucke (builtin-simulation-nodes, functions, particle-solver-dev, simulation-tree) November 13, 2019, 10:29 (GMT) |
pass MFMask directly |
November 13, 2019, 10:29 (GMT) |
Fix T71503: Wrap + displace + multires + Sculpt crash The root of the issue goes to the discontinuity between the way how mesh_calc_modifiers() and BKE_sculpt_multires_active() works. At some point detection of original data usage by a modifier got broken: the mesh_final based check is unreliable because deform-only modifiers will create mesh_final for the connectivity information. This made it so modifier stack evaluation would skip multires evaluation, but the sculpt code will assume the multires is properly applied. This change makes it an explicit check about whether there are any non-deform-only modifiers applied. Pair programming and review together with Bastien, thanks! |
|
|
|


Master Commits
MiikaHweb | 2003-2021