This allows us to remove a callback from the modifier type info struct.
In the future the these modifiers might just be replaced by nodes
internally anyway, but in the meantime it's nice to unify the handling
of evaluated geometry a bit.
Differential Revision: https://developer.blender.org/D11080
Since the initial merge of the geometry nodes project, the modifyPointCloud
function already was already modifying a geometry set. The function wasn't
renamed back then, because then the merge would have touched many
more files.
Ref T83357.
This removes `foreachObjectLink` from `ModifierTypeInfo`, `GpencilModifierTypeInfo`
and `ShaderFxTypeInfo`. There is no need to have both, `foreachObjectLink` and `foreachIDLink`.
There is not code that actually depends on `foreachObjectLink`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D9078
As noted in T80164, there are quite a few area of Blender where the
"Reset to Default Value" operator in button context menus doesn't work.
Modifiers are one of them, because the DNA defaults system was never
set up for them.
Additionally, this should make modifier versioning easier. Whenever a
new field is added it should be automatically initialized to the
default value.
I had to make some ordering changes in the following modifiers to work
around an error with `-Wsign-conversion` in the macros:
- Solidify Modifier
- Corrective Smooth Modifier
- Screw Modifier
Some modifiers are special cases and are skipped in this commit:
- Data Transfer Modifier
- Cloth Modifier
- Fluid Modifier
- Softbody Modifier
Differential Revision: https://developer.blender.org/D8747
This reduces the number of places that have to be modified
when a new modifier is added.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D9000
With this change `outliner_draw.c` does not have to be
edited anymore when a new modifier is added.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D8998
For modifier shortcuts we added a "custom_data" field to panels.
This commit uses the same system for accessing the list data that
corresponds to each panel. This way the context is only used once
and the modifier for each panel can be accessed more easily later.
This ends up being mostly a cleanup commit with a few small changes
in interface_panel.c. The large changes in the UI functions are due
to the fact that the panel custom data is now passed around as a
single pointer instead of being created again for every panel.
The list_index variable in Panel.runtime is removed as it's now
unnecessary.
Differential Revision: https://developer.blender.org/D8559
This is part of a greater blenloader decentralization effort (T76372).
For modifiers the goal is that fewer files have to be modified when
a new modifier is added.
This patch just adds the `blendWrite` and `blendRead` callbacks to
`ModifierTypeInfo` but does not change any other code yet. In the next
steps, modifier specific code will be moved from `writefile.c` and
`readfile.c` into their corresponding `MOD_*` files.
This patch implements the list panel system D7490 for modifiers.
It also moves modifier drawing to a callback in ModifierTypeInfo
in line with the extensible architecture refactoring goal T75724.
This adds a PanelRegister callback and utilities for registering
panels and subpanels. It also adds the callbacks for expansion saving
and drag and drop reordering described in D7490.
These utilities, callbacks, and other common UI elements shared
between modifiers live in MOD_ui_common.c.
Because modifier buttons are now in panels, we can make use of
subpanels for organization. The UI layouts also use the single
column layout style consistently used elsewhere in Blender.
Additionally, the mode-setting buttons are aligned and ordered
consistently with the outliner.
However, the large number of UI changes in this patch may mean
that additional polishing is required in master.
Thanks to William Reynish (@billreynish) who did a fair amount of the
layout work and to Julian Eisel (@Severin) for consistent help.
Differential Revision: https://developer.blender.org/D7498
There is no user visible difference in standard builds, as there are no
volume modifiers yet. When using WITH_NEW_OBJECT_TYPES some deform only
modifiers are now available for hair and pointcloud objects.
Differential Revision: https://developer.blender.org/D7141
The general idea of this change is to have a runtime data pointer
in the ModifierData, so it can be preserved through copy-on-write
updates by the dependency graph.
This is where subdivision surface modifier can store its topology
cache, so it is not getting trashed on every copy-on-write which
is happening when moving a vertex.
Similar mechanism should be used by multiresolution, dynamic paint
and some other modifiers which cache evaluated data.
This fixes T61746.
Thing to keep in mind, that there are more reports about slow
subdivision surface in the tracker, but that boils down to the
fact that those have a lot of extraordinary vertices, and hence
a lot slower to evaluated topology.
Other thing is, this speeds up oeprations which doesn't change
topology (i.e. moving vertices).
Reviewers: brecht
Reviewed By: brecht
Maniphest Tasks: T61746
Differential Revision: https://developer.blender.org/D4541
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
That kind of implicit includes should really only be done when totally,
absolutely necessary, and ideally only with rather simple 'second-level'
headers.
Otherwise not being explicit with includes always end up biting in
unexpected ways...
The contents of the ModifierEvalContext struct are constant while iterating
over the modifier stack. The struct thus should be only created once, outside
any loop over the modifiers.
Makes the follow changes:
- Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers.
- Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary
- Update the rest of Blender to be aware and make use of these new functions
The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed.
Reviewers: campbellbarton, sergey, mont29
Subscribers: sybren
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D3155
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
Solves these security issues from T52924:
CVE-2017-12081
CVE-2017-12082
CVE-2017-12086
CVE-2017-12099
CVE-2017-12100
CVE-2017-12101
CVE-2017-12105
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
