Not only were those often making doublons with already existing
BLI_math's stuff, but they were also used to hide implicit type
conversions...
As usual this adds some more exotic inlined vector functions (one of
the rare cases where I really miss C++ and its templates... ;) ).
Needed to port operator to use evaluated particle system.
But also changed interface to always show Convert button when
draw type is set to Path (Hair particle system is forced to
be draws as path). This avoid rather expensive lookup on every
redraw, but will show Convert button for un-baked particle
emitter.
Probably, an acceptable compromise.
Was only visible after going in and out (with some strokes inbetween)
hair edit mode. The edit structure was never freed during Blender
session for some reason. Now we free those when leaving particle
edit mode.
We cannot let those data be generated on-the-fly in RBW evaluation
anymore, since those would be added to CoW eval object and never ported
back to orig objects.
We *could* get orig objects in eval code, of course, but as in
constratints, this is not really threadsafe and future proof, depsgraph
evaluation should really write back to orig data as little as possible.
So instead, add code to ensure required data is generated to objects
when their collection is added to rigidbody world.
Note that we *may* want to clean that up once collection is no more used
by RB? On the other hand, people might want to keep those data around to
be able to switch between different setups easily... So think it's OK to
keep them at least for now.
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
This should be purely an implementation change,
for end users there should be no functional difference.
The entire key configuration is in one file with ~5000 lines of code.
Mostly avoiding code duplication and preserve comments and utility
functions from the C code.
It's a bit long but for searching and editing it's also convenient to
have it all in one file.
Notes:
- Actual keymap is shared by blender / blender_legacy
and stored in `keymap_data/blender_default.py`
This only generates JSON-like data to be passed into
`keyconfig_import_from_data`, allowing other presets to load and
manipulate the default keymap.
- Each preset defines 'keyconfig_data'
which can be shared between presets.
- Some of the utility functions for generating keymap items still
need to be ported over to Python.
- Some keymap items can be made into loops (marked as TODO).
See: D3907
That kind of implicit includes should really only be done when totally,
absolutely necessary, and ideally only with rather simple 'second-level'
headers.
Otherwise not being explicit with includes always end up biting in
unexpected ways...
This is a variation of older hach which was setting is_rendering
to truth to tell window manager to not do dependency graph update.
In the nowadays reality window manager is supposed to do dependency
graph update during rendering, that was the whole purpose of CoW
project. This works fine for rendering, since render engines has
their own dependency graphs.
Physics, on the other hand, is using same dependency graph as used
for the viewport, and what's worse: it modifies objects from it.
For example, in a single threaded evaluation ASAN instantly catches
case when cached BVH constructed by smoke is referencing looptri
layer which is freed by viewport's update.
Now we are locking interface, allowing only a subset of navigation
operators to run. This seems to be safest way of dealing with the
problem. There are following variations which we can consider
doing:
- Allow viewport navigation, which will require making it so draw
manager does not write to the objects.
A bit dangerous, since smoke simulation might in theory modify
data which is also used by a draw manager.
- Make physics simulation to have own dedicated dependency graph,
solving all threading conflicts all together.
This fixes crash when baking smoke. Steps to reproduce:
- Call "Quick Smoke"
- In smoke panel, click "Bake".
* Icons in specials menu (Copy and the new Duplicate icon)
* Remove redundant "Settings" label next to ID template widget.
* Remove "Type" label and expand dropdown, since it only has 2 options (emitter/hair), saves 1 click.
* Move "Seed" to and "Hair Segments" to Emission panel
* Rename "Duplicate Particle Systems" to "Duplicate Particle System", since it
only duplicates one (the active one) at a time.
Add tool options to control how select operates (add/sub/set/and/xor).
Note: edit mode armature select still needs to support all options,
this is complicated by how it handles partial end-point selection.
