Blender Git Statistics -> Branches -> temp_depsgraph_split_ubereval
"Temp_depsgraph_split_ubereval" branch
Total commits : 17
Total committers : 1
First Commit : September 22, 2015
Latest Commit : April 21, 2016
Commits by Month
Date | Number of Commits | |
---|---|---|
April, 2016 | 4 | |
March, 2016 | 0 | |
February, 2016 | 0 | |
January, 2016 | 0 | |
December, 2015 | 0 | |
November, 2015 | 0 | |
October, 2015 | 0 | |
September, 2015 | 13 |
Committers
Author | Number of Commits |
---|---|
Lukas Toenne | 17 |
Popular Files
Filename | Total Edits |
---|---|
DerivedMesh.c | 10 |
object_update.c | 6 |
depsgraph_build_nodes.cc | 5 |
BKE_object.h | 4 |
modifier_calc.c | 3 |
depsgraph_build_relations.cc | 2 |
CMakeLists.txt | 2 |
BKE_DerivedMesh.h | 2 |
particle_system.c | 2 |
depsnode_opcodes.h | 2 |
Latest commits
April 21, 2016, 09:24 (GMT) |
Moved function declarations for modifier stack eval into BKE_modifier_calc.h. |
April 21, 2016, 08:06 (GMT) |
Avoid shadowing 'mask' function parameter by a local variable. |
April 21, 2016, 07:46 (GMT) |
Moved code for modifier evaluation out of DerivedMesh.c. These files contained a confusing mix of DM code (for manipulating DMs and various utility functions relating to these types), and the code for evaluating object modifier stacks. These are two very distinct areas and putting them in a single huge file doesn't promote code clarity at all. This commit only moves code, but does not alter any of it. This is important for log continuity, so history of specific functions can be clearly traced back! |
April 20, 2016, 14:45 (GMT) |
Merge branch 'master' into temp_depsgraph_split_ubereval |
September 25, 2015, 10:53 (GMT) |
Result struct for storing various points to DerivedMesh and deform during modifier eval. |
September 25, 2015, 10:12 (GMT) |
Own function for finalizing the modifier eval result. |
September 25, 2015, 09:54 (GMT) |
Use a localized ndm variable for the main dm and both possibl orco results. Proper scoping helps understanding of the code. |
September 25, 2015, 09:45 (GMT) |
Own function for setting up the DerivedMesh input for constructive modifiers. |
September 25, 2015, 09:10 (GMT) |
Use a common function for deform-only modifier evaluation. The distinction between leading and interspersed deform modifier in the evaluation loop is superficial. The primary difference is the existence of a derived mesh (dm), which can be handled optionally. Further conditionals can be moved outside the loop (dyntopo would immediately cancel leading deform eval anyway). |
September 24, 2015, 09:26 (GMT) |
Simplify initialization of the deformedVerts variable. No need to do the same thing in both code branches, the result is the same. |
September 23, 2015, 17:30 (GMT) |
Moved the rather elaborate test for modifier sculptmode compatibility into own function. |
September 23, 2015, 16:19 (GMT) |
Cleanup for mesh_calc_modifiers: Context and Iteration structs. These gather most of the large number of local variables in that function, in order to gain some clarity on their usage and scope. Context is where immutable settings and global precomputed data is stored during the computation. These values are initialized once and not touched by modifiers. Iterator struct holds the combined md/datamask pointers and some (hackish) mutable data that gets updated during the process. Where possible local variables have also been moved into narrower code blocks to make the overall procedure less confusing. |
September 23, 2015, 08:16 (GMT) |
Split the "uber-eval" function for object data into individual operations based on object type. This means making a dedicated data generation function for object types that need it, and a few utility functions for particles and extra driver evaluation (hopefully soon to be deprecated). Remaining "uber" functions in the depsgraph should be split in a similar manner in future. The splitting allows us to go deeper into the design of certain object types (meshes in particular) and improve these without having to deal with all the other types. Note on mesh vs editmesh operations: Mesh and editmesh are calculated in separate functions. In order to get to a point where splitting into individual modifiers makes sense, the first step is to have two separate operations for these. Changing edit mode does not rebuild the depsgraph, so we cannot selectively add only one or the other at build time. Instead both operations are added, but only one of them is actually executed. Currently this uses an internal test for the edit mesh, but could later be controlled on the depsgraph level based on active branches. Differential Revision: https://developer.blender.org/D1527 |
September 23, 2015, 06:53 (GMT) |
Further split of the object derived mesh update into mesh vs. editmesh operations. Mesh and editmesh are calculated in separate functions. In order to get to a point where splitting into individual modifiers makes sense, the first step is to have two separate operations for these. Note that changing edit mode does not rebuild the depsgraph, so we cannot selectively add only one or the other at build time. Instead both operations are added, but only one of them is actually executed. Currently this uses an internal test for the edit mesh, but could later be controlled on the depsgraph level based on active branches. |
September 22, 2015, 14:49 (GMT) |
Removed pointless conditional, function call is the same in both cases. |
September 22, 2015, 14:41 (GMT) |
Renamed functions a bit for simplicity. Rationale is to use "eval" for all functions which are called directly from the depsgraph. |
September 22, 2015, 12:35 (GMT) |
Split the "uber-eval" function for object data into individual operations based on object type. This means making a dedicated data generation function for object types that need it, and a few utility functions for particles and extra driver evaluation (hopefully soon to be deprecated). Remaining "uber" functions in the depsgraph should be split in a similar manner in future. The splitting allows use to go deeper into the design of certain object types (meshes in particular) and improve these without having to deal with all the other types. |
MiikaHweb - Blender Git Statistics v1.06