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
These changes are smaller, made based on feedback and a pass on all
the layouts for clarity and consistency. The Multires modifier UI will
be addressed in a separate patch. Here is an overview of the changes:
Renaming Options:
- Build: "Start" -> "Start Frame"
- Curve: "From Radius" -> "Size from Radius"
- Screw: "Calc Order" -> "Calculate Order"
- Displace, Warp, Wave: "Texture Coordinates Object" -> "Object"
Move Mode Toggle to Top & Expand:
- Bevel, Boolean, Normal Edit, Subdivision
Use Columns for Tighter Spacing:
- Displace, Explode, Ocean, Particle Instance, Remesh, Shrinkwrap,
Solidify, Warp, Weighted Normal, Wave
Misc:
- Bevel: Set inactive properties for vertex bevel
- Mesh Sequence Cache: Remove box for cache file
- Skin: Don't align "Mark Loose" and "Clear Loose"
- Array: Expand relative offset subpanel by default
- Array: Move start cap, end cap to a new subpanel
- Bevel: Move width type above width
Differential Revision: https://developer.blender.org/D8115
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
This commit actually fixes several issues in this modifier, but main one
from the report was caused by adding a `CD_NORMAL` layer to loops to
store temp real clnors. Unless we plan on modifying the topology itself,
this is useless, and would require some additional 'dirty normals'
tagging to work properly, so just switched to simpler, cleaner solution
of having a local array of computed clnors.
This was wrong and violating design to force modifiers to query
evaluated objects and IDs. It is up to the caller to make sure
the object is properly evaluatable.
Effectively, reverting changes from de491abf99 (and possibly
other related changes).
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
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
BLI should always comes first, before DNA, BKE etc. And
`BLI_utildefines.h` should come before any other BLI (since it's some
sort of system include really, among other things...).
Thisi should help to reduce the noise in patches when adding stuff
like uint64_t members to DNA structs... ;)
This is what modifiers are to use to indicate that they depend
on a transformation of the object itself.
Currently should be no functional changes, but in the future
this will allow to easily change transform operation depending
on whether there is a simulation associated with the object.
Turns out most of our 'local working copy' cases can use same set of
flags.
Note that this commit adds LIB_ID_COPY_CACHES to all our local meshes
copying, however this is no-op since that flag is unused during mesh
copying... We may want to add another set of flags without that one at
some point, but for now it would not be useful imho.
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.
Fix T58237: Exporters: Curve Modifier not applied when "apply modifiers" are selected.
Fix T58856: Python: "to_mesh" broken in 2.8.
...And many other cases... ;)
Thing is, we need target IDs to always be evaluated ones (at least I
cannot see any case where having orig ones is desired effect here).
Depsgraph/Cow system ensures us that when modifiers are evaluated by it,
but they can also be called outside of this context, e.g. when doing
binding, or object conversion...
So we need to ensure in modifiers code that we actually are always
working with eval data for those targets.
Note that I did not touch to physics modifiers, those are a bit touchy
and rather not 'fix' something there until proven broken!
When a modifier depends on some other object's position, then it also
depends in its own position, this has to be also told to depsgraph.
Fixes several modifiers where moving target would update the modifier,
while moving modified object itself would not.
this is actually adding option to add buggy behavior, but.. NPR often
expects buggy behaviors, and its one of the main targets for normal editing.
So think it's reasonable to add that option (disabled by default of
course).
Note that am not really happy with UI, but:
* Not sure where to put it, it's kind of own self-contained area option.
* Don't to make it too much visible, using this should be the exception!
Note that custom normals drawing seems to be broken, and there also are
some refresh issues in some cases... But this is same with old DM-based
code, so not related to modifiers themselves probably.
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.
