- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache
modifier in order to use and test it from Blender.
To enable it, one has to switch the render feature set to experimental and
activate the Procedural in the modifier. An Alembic Procedural is then
created for each CacheFile from Blender set to use the Procedural, and each
Blender object having a MeshSequenceCache modifier is added to list of objects
of the right procedural.
The procedural's parameters derive from the CacheFile's properties which are
already exposed in the UI through the modifier, although more Cycles specific
options might be added in the future.
As there is currently no cache controls and since we load all the data at the
beginning of the render session, the procedural is only available during
viewport renders at the moment. When an Alembic procedural is rendered, data
from the archive are not read on the Blender side.
If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural,
bounding boxes are used to display the objects in the scene as a signal that the
objects are not processed by Blender anymore. This is standard in other DCCs.
However this does not reduce the memory usage from Blender as the Alembic data
was already loaded either during an import or during a .blend file read.
This is mostly a hack to test the Cycles Alembic procedural until we have a
better Blender side mechanism for letting renderers load their own geometry,
which will be based on import and export settings on Collections (T68933).
Ref T79174, D3089
Reviewed By: brecht, sybren
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D10197
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
The check to include particle edit mode in the object-mode drop-down
didn't match the poll function to edit particle edit mode.
Share the check between both functions.
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.
It's easier to read and less 'weird' to check that an item is non-local
in a liboverride data-block, than the other way around. Thanks to
@sybren for noticing it.
RNA collections that support insertion of new items in liboverride
data-block need a special way to distiguish between locale and
orig-from-linked items (since some operations are allowed on the forer,
but no the latter).
In future we want a proper solution to abstract that at the
`BKE_lib_override` level, but for now we need to add some code for each
case.
Note that this commit also fixes a few potential issues with GPencil
modifiers, and constraints, regarding their handling of local overrides.
This commit adds functions to set and get the object's active
modifier, which is stored as a flag in the ModifierData struct,
similar to constraints. This will be used to set the context in
the node editor. There are no visible changes in this commit.
Similar to how the node editor context works for materials, this commit
makes the node group displayed in the node editor depend on the active
object and its active modifier. To keep the node group from changing,
just pin the node group in the header.
* Shortcuts performed while there is an active modifier will affect
only that modifier (the exception is the A to expand the modifiers).
* Clicking anywhere on the empty space in a modifier's panel will make it active.
These changes require some refactoring of object modifier code. First
is splitting up the modifier property invoke callback, which now needs
to be able to get the active modifier separately from the hovered
modifier for the different operators.
Second is a change to removing modifiers, where there is now a separate
function to remove a modifier from an object's list, in order to handle
changing the active.
Finally, the panel handler needs a small tweak so that this "click in panel"
event can be handled afterwards.
This is the initial merge from the geometry-nodes branch.
Nodes:
* Attribute Math
* Boolean
* Edge Split
* Float Compare
* Object Info
* Point Distribute
* Point Instance
* Random Attribute
* Random Float
* Subdivision Surface
* Transform
* Triangulate
It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier.
Notes on the Generic attribute access API
The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).
Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.
It includes commits from:
* Dalai Felinto
* Hans Goudey
* Jacques Lucke
* Léo Depoix
When outliner datablocks are selected, switch to the corresponding tab
for that datablock in properties editors. Only properties editors
that share an edge with the outliner will change tabs.
Additionally, when modifiers, constraints, and shader effects are
selected from the outliner, the panel will be expanded in all properties
editors.
Part of T77408
Manifest Task: https://developer.blender.org/T63991
Differential Revision: https://developer.blender.org/D8638
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
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
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
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
This resolves a performance regression in 2.8x where every edit-mode
update performed an edit-mesh to mesh conversion.
Now the conversion will be lazily initialized if/when it's required.
New BKE_mesh_wrapper_* functions abstract over mesh data access.
Currently only edit-mesh and regular meshes are supported.
In the future sub-surface meshes may be supported too.
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
Show control edges stores the control edges in the mesh which is
picked up by the draw manager. When applyng a subsurf (or multires) we
don't want that data present in the base mesh. Any rebuilding of the mesh
would overwrite the data anyway.
This patch introduces a new flag for applying modifiers
that can be checked to ignore storing display specific data in
the base mesh.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D7163
C++ is used more and more, and it is becoming more and more annoying to
keep track of whether header have C++ guard or not.
Is easier and more clear to be consistent in all headers and have such
guards in all headers.
The `modifiers_getVirtualModifierList()` function previously took a non-
const `Object *ob` parameter, preventing it from being called from more
restrictive functions. Since the function doesn't modify the passed
object, it could easily be made const.
No functional changes.
Previously in 2.79 we were using a specialized drawing using derivedMesh.
Now the subsurf modifier tag each center vertex as facedot and let the
DRWManager pick it up.
Some modifiers (deforming ones) do not clear the tag so we can use this
technique even if there is deforming modifiers after subsurf modifiers.
This saves memory and evaluation time for simple static meshes with e.g. a
subdivision surface modifier. If no CD_ORCO layer exists then we assume the
actual vertex coordinates are equal to the original undeformed coordinates.
