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

DateNumber of Commits
April, 20164
March, 20160
February, 20160
January, 20160
December, 20150
November, 20150
October, 20150
September, 201513

Committers

AuthorNumber of Commits
Lukas Toenne17

Popular Files

FilenameTotal Edits
DerivedMesh.c10
object_update.c6
depsgraph_build_nodes.cc5
BKE_object.h4
modifier_calc.c3
depsgraph_build_relations.cc2
CMakeLists.txt2
BKE_DerivedMesh.h2
particle_system.c2
depsnode_opcodes.h2

Latest commits Feed

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
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021