Fluid guiding functionality was broken in the bake / read cache loop in fluid.c. Committing this to the release branch as otherwise fluid guiding would not have worked as expected (i.e. not at all).
The baking progress bar now uses the entire notification space in the UI. Before, old reports could still be visible when a bake job got started. This had the disadvantage that those message got frozen too with the bake UI freeze.
This commit cleans up the flow emission code (i.e. the code that determines where flow is generated). It also addresses an issue with initial velocities.
Related issues (that might be fixed through this commit) are: T73422, T72949
Caused by own rBe02ecd599bdc.
Can happen with e.g. cloth.
Also fixes T59583
Maniphest Tasks: T72235, T59583
Differential Revision: https://developer.blender.org/D6547
updates in particle editmode
Particles themselves were cleared correctly but this was not tagging
batch cache dirty.
Might move this to a utility function later [since it is used in more
places], but that is for after going over some more reports...
Reviewers: sergey
Differential Revision: https://developer.blender.org/D5925
are visible
Not freeing PTCacheEdit and tagging batch cache dirty on undo will have
a couple of consequences. This patch fixes:
- crash deleting a particle, then undo
- basically any edit (combing, ...), then undo will leave child hairs
untouched
- adding hairs (through mirror, add tool, ...), then undo will leave
'orphaned' child hairs
See also D5755 for a related discussion
Fixes the crasher mentioned in T69000
Might move this to a utility function later [since it is used in more
places], but that is for after going over some more reports...
Reviewers: sergey
Differential Revision: https://developer.blender.org/D5912
Fixed sized strings are always initialized & this is not done
elsewhere before calling BLI_path_join.
Remove since it's not needed and makes it read as if the function
might not initialize the output argument.
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
Similarly to physics_fluid.c (in same directory) which handled the baking process for Elbeem, there is now physics_manta.c which handles it for Mantaflow.
There are two types of jobs: one for baking and another for freeing. The generic jobs will be used to bake / free specific parts of the simulation (e.g. bake mesh, free particles, etc.).
The jobs are only being used in the "modular" cache mode where the simulation has to be baked in parts.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3856
'PE_set_data' / 'PE_set_view3d_data' would give us a depsgraph already,
so use it.
Also fix access to PEData->depsgraph without calling 'PE_set_data' prior.
Addresses concern raised in rBcf2c09002fae.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D6067
Side-reported in T70505.
Code did not ensure deleted object was removed from the RBW constraints
collection, leading to some invalid status (object in constraints
collection but without relevant contraints data).
Also fixed another issue - code deleting RBW objects would try to remove
any constraint one using it as target, in a very bad and broken way,
since you cannot iterate over objects of a collection while removing
some... Now instead just NULLify relevant pointers... I hope it works,
otherwise we'll have to take a different approach.
Needless to stress again how weak the whole RBW code is in general, and
regarding same object being used by RBW in more than one scene in particular,
that is known broken situation anyway.
visible in the viewport
Seems to be an issue of not correctly freeing the PTCacheEdit (see
T68645 for details), after discussion with sergey we went with the quick
and dirty fix to free the path cache early for now. Other solution of
freeing it in 'psys_cache_paths' for the non-evaluated psys [which would
also fix the particle delete, then undo crash from T69000] needs more
deep investigation and, possibly, reconsideration.
Reviewers: sergey
Maniphest Tasks: T68645
Differential Revision: https://developer.blender.org/D5755
Caused by rB914427afd512.
Since above commit 'pe_get_current' checks for an active depsgraph. This
caused the skipping of handling
`PT_CACHE_EDIT_UPDATE_PARTICLE_FROM_EVAL`for everything calling
`PE_get_current` (this passes a NULL depsgraph as opposed to
`PE_create_current`). So we now pass a depsgraph here as well...
Note there are two RNA cases where we pass NULL, namely
- rna_ParticleEdit_editable_get
- rna_ParticleEdit_hair_get
I guess these should be fine though (no functional change to current
master)
Reviewers: sergey
Maniphest Tasks: T69488
Differential Revision: https://developer.blender.org/D5752
If fade_time is used, particles would be flagged PEK_HIDE (depending on
time settings), but since this is not respected in drawing in 2.8 yet
the user would have no indication of them keys being hidden.
Also doing this for hair doesnt make much sense anyways...
Reviewers: jacqueslucke
Maniphest Tasks: T70259
Differential Revision: https://developer.blender.org/D5901
Even though hidden/faded keys are not supported in drawing in 2.8 yet,
the selection tools should not be able to select non-visible keys.
Spotted while looking into T70259
Reviewers: JacquesLucke
Differential Revision: https://developer.blender.org/D5902
Particularly noticeable when vertex painting with a subsurf modifier.
In some cases every sculpt or paint stroke step would evaluate the dependency
graph. This should only happen for redraws. Now more selectively choose if the
dependency graph should be evaluated to initialize the view context. Doing it
in the view context evaluation is somewhat hidden, now it's more explicit.
Differential Revision: https://developer.blender.org/D5844
If children hairs were displayed in particle editmode, these would not
update when a particle was deleted.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D5840
This is caused by rB1342d1879e12 and would also break the whole
"Connect" workflow [which relies on empties]
Reviewers: mont29, brecht
Maniphest Tasks: T69582
Differential Revision: https://developer.blender.org/D5772
unique name
This was leading to equally named particle systems, causing problems
later on.
Spotted while looking into T67958.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5632
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
