Things like pointers to particle systems, or softbody data being stored
outside of its modifier, make it impossible for internal modifier copy
data code to be self-contained currently. It requires extra processing.
In existing code this was handled in several different places, in
several ways, and alltogether fairly inconsistently. Some cases were
even not properly handled, causing e.g. crashes as in T82945.
This commit addresses those issues by:
* Adding comments about the hackish/unsafe parts `psys` implies when
copying some modifier data (since we need to ensure particle system
copying and remapping of those pointers separately).
* Adding as-best-as-possible handling of those cases to
`BKE_object_copy_modifier` (note that it remains fragile, but is
expected to behave 'good enough' in any practical usecase).
* Remove special handling for specific editor code
(`copy_or_reuse_particle_system`). This should never have been
accepted in ED code area, and is now handled by
`BKE_object_copy_modifier`.
* Factorize copying of the whole modifier stack into new
`BKE_object_modifier_stack_copy`, now used by both `object_copy_data`
and `BKE_object_link_modifiers`.
Note that this implies that `BKE_object_copy_modifier` and
`BKE_object_copy_gpencil_modifier` are now to be used exclusively to
copy single modifiers. Full modifier stack copy should always use
`BKE_object_modifier_stack_copy` instead.
Fix T82945: Crash when dragging modifiers in Outliner.
Maniphest Tasks: T82945
Differential Revision: https://developer.blender.org/D10148
Mainly updated the Mantaflow version. It includes the new viscosity solver plugin based on the method from 'Accurate Viscous Free Surfaces for Buckling, Coiling, and Rotating Liquids' (Batty & Bridson).
In the UI, this update adds a new 'Viscosity' section to the fluid modifier UI (liquid domains only). For now, there is a single 'strength' value to control the viscosity of liquids.
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
Scaling of forces needs more work. Before making changes to them it would be nice to have a setup, that works physically correct across multiple modifiers (cloth, rigid bodies, fluid).
This will be a to do for 2.92.
Basic support for velocity updates with the APIC method.
This commit adds APIC to the already existing dropdown menu for the simulation method. The APIC plugin within Mantaflow has been updated to the latest version.
Being able to adjust the distance between fluid and obstacles comes in handy when trying to achieve a fluid motion over inclined obstacles.
Depending on the slope of such obstacles, already small adjustments of this value can help when particles stick to obstacle surfaces (i.e. make particles not stick to obstacles).
A general refactor / fix commit that should clear out the issues that have been reported on external forces and moving effectors (e.g. T79537, T81660, T80088).
When creating a particle system to display simulated particles, the phystype needs to be set to 'no physics' so that particle positions are just copied and not integrated.
This will make the "Reset to Default Value" operator in button right
click menus work for the fluid modifier. Before they always reset
the values to 0.
Differential Revision: https://developer.blender.org/D9206
Do not escape flow / effector objects if they have a disabled use flow / use effector flag.
Vertex velocities still need to be kept track of in order to have correct object velocities when enabling flows / effectors intermittenly. It is possible though to skip the emission loop if the flags are disabled.
This refactor is in response to an unreported bug in which overlapping, moving colliders produced an unstable simulation.
Things that change apart from cleanup through this refactor:
- Effector objects with no velocities (either non-animated or animated but non-moving object) will explicitly set zero velocities in their flow bounding box.
- When applying object velocities to the global grid, they will now be accumulated per cell (add and not set velocities). Later they will be averaged with the object count at any cell.
All the changes made in the branch `soc-2020-fluid-tools` are included in this patch.
**Major changes:**
=== Viewport Display ===
- //Raw voxel display// or //closest (nearest-neighbor)// interpolation for displaying the underlying voxel data of the simulation grids more clearly.
- An option to display //gridlines// when the slicing method is //single//.
==== Grid Display ====
- Visualization for flags, pressure and level-set representation grids with a fixed color coding based on Manta GUI.
==== Vector Display ====
- //**M**arker **A**nd **C**ell// grid visualization options for vector grids like velocity or external forces.
- Made vector display options available for external forces.
==== Coloring options for //gridlines// ====
- Range highlighting and cell filtering options for displaying the simulation grid data more precisely.
- Color gridlines with flags.
- Also, made slicing and interpolation options available for Volume Object.
Reviewed By: JacquesLucke, sebbas
Differential Revision: https://developer.blender.org/D8705
Load all grids when the grid display option is turned on. Otherwise, the grid from the viewport display options might not have been loaded from the cache.
The problem in this case was that the flag for active fire was not set. With hidden flow sources the flag was not updated in update_flowsflags().
The solution for this is to take the active field from the config cache file.
Before: If the current frame is out of the cache start/end range, the viewport will show the fluid as it was on the last frame that was still in the cache frame range.
Now: If the current frame is out of the cache start/end range, the viewport will show no fluid at all (even if there are cache files present for this frame).
This fix is related / in response to T79423.
Instead of clearing forces at the end of the simulation step, they will now be cleared before writing to them, i.e. at the beginning of a step.
Also cleaned up minor areas that I looked at while making this change.
Yet another update to ensure that pointer variables are always up to date, i.e. those referencing the memory allocated by Mantaflow. Outdated pointers usually show up through flickering in viewport.
In f2b04302cd the pointer update was refactored. It was sufficient to update pointers just in replay mode at the end of a step since the 'ensure()' functions from manta_fluid_API.cpp had their own pointer update call. These were removed in 51f4bee5a5, however, and so in order to still have some sort of update, the given update call needs to be available to all cache types.
A collection of multiple changes that had been living in my stash:
- Use nullptr instead of NULL in C++ files
- Removed unused/deprecated functions from headers
- Cleared animatable flag in cache UI
- Comment cleanups
Use static_cast() where possible and refresh pointers for every frame when in replay mode. The latter is particularly important as this seems to have caused the issue where smoke in the viewport was flickering when loading data from pointers after loading them from disk for the frame before (e.g. when resuming a bake job).
New option that lets users the define the maximum number of fluid particles that will be allowed in the simulation. This can come in handy, for example, to ensure that the particle count will not exceed the hardware capabilities, or to avoid excessive amounts of particles in a scene.
