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
'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
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 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
Make sure particle system edit never points to a modifier or particle system
which becomes inactive.
This is needed because copy-on-write will change pointers of them and those
pointers are supposed to be restored from particle system evaluation. But
since the particle system is disabled it never updates pointers.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5180
This reverts commit 36faf739a7.
Somewhat annoying but this change had some unforeseen consequences,
which lead to an actual bug.
Since this change was not sufficient to get original report fixed
is easier to simply revert for now.
Fixes T65842: Hair disappears when clicking on particle system name
Allows it to be preserved during copy-on-write update when on-geometry
related update is needed.
This is a required part for T63537, where we need to preserve the entire
evaluation data when object is tagged for only RECALC_COPY_ON_WRITE.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5023
Add back the ability to choose the select operation for random select.
Now we allow the operator to specify if the select operation should be
visible in the GUI or not.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D4665
Now the depth order of objects when trying to select them is only used when not in X-ray mode.
Before, this was only the case in wireframe mode regardless of X-ray settings.
I've also unified the usage of V3D_XRAY and XRAY_FLAG as they were basically copies of each other.
Reviewed By: Clément
Differential Revision: http://developer.blender.org/D4504
This removes `VIEW3D_OT_select_or_deselect_all`, adding a
deselect_all option to the `VIEW3D_OT_select` operator.
- Add utility functions to simplify de-selecting all.
- Return true from selection functions when they change the selection
to avoid redundant updates.
- Use arrays of bases when passing objects between selection utility
functions since some users require bases.
- Fix logical error in box selection that updated all objects after
the first hit.
This replaces the global `PEData->dist` with a thread local variable
that is passed into the callback functions separately.
There are two new function types which have `Hit` in the name.
Those take the distance to the mouse as an additional parameter.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4538
The shaders are: `GPU_SHADER_3D_FLAT_SELECT_ID` and `GPU_SHADER_3D_UNIFORM_SELECT_ID`.
This commit allows the drawing of the mesh select ids to be done on a 32UI format texture.
This simplifies the shader that previously acted on the backbuffer and had to do an uint to rgba conversion.
Differential Revision: https://developer.blender.org/D4350
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
