- Undo that changes modes currently asserts,
since undo is now screen data.
Most likely we will change how object mode and workspaces work
since it's not practical/maintainable at the moment.
- Removed view_layer from particle settings
(wasn't needed and complicated undo).
- WM_manipulatorgrouptype_remove- > free
- WM_manipulator_group -> WM_manipulator_group_type
Naming here is still a bit confusing,
now at least free/remove are differentiated.
Was complicating general use case, also support for transforming with matrix_space set.
Add matrix_space support for manipulator_window_project_2d too.
Naming was confusing, while technically correct -
the result is no scaling (manipulator ignores zoom-level).
Also remove 3D from name since this can be supported for 2D views too.
Changes from custom-manipulator branch.
- use property type definitions.
- add property free callback.
- move properties into the wmManipulator struct (over alloc).
- use array length from property types instead of arg passing.
This makes manipulator access closer to operators,
and allows Python access.
This adds RNA for manipulators, but not Python registration yet.
- Split draw style into 2x settings:
`draw_style` (enum) & `draw_options` (enum-flag)
- Rename wmManipulator.properties -> properties_edit,
Use wmManipulator.properties for ID-properties.
Note that this area of the API will need further work since
manipulators now have 2 kinds of properties & API's to access them.
This avoids having to use manipulator-type specific functions
to set the orientation.
And will make it simpler to access transformation from Python.
Currently the matrix is still used as an offset in places.
Also per-type orientation values still need to be removed.
- Option to start helper angle lines based on a vector
instead of the initial mouse coords (useful for bisect & spin).
- Option to show 2x helper lines
useful when dial is used to rotate an axis value.
Instead use generic 'WM_manipulator_new', adding a new 'setup'
callback (like wmManipulatorGroup.setup) used to initialize type vars.
This moves conventions closer to wmOperator and simplifies exposing to
Python.
Was the case of several Mesh operators actually (and probably others, but cannot check
everything). Added `RNA_def_property_float_distance` helper, avoids having to
set PROP_DISTANCE subtype explicitly each time...
Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
* Revert 776bfa64a5 and c3dad7953a (some X11 systems are doing
stupid things forcing me to do an extra check that completely breaks the
click type handling on other systems using the slightly changed
implementation from those commits - see T44278)
* Fix sample lines in Compositor+VSE
(And yes, this time I tested on both of my systems to make sure
everything is fine)
extruding
More practical description of the bug: extruding with ctrl to use
snapping and confirming the action added another extrusion to the mouse
position.
This was caused from the second event that is now sent if a key release
happens within the click timeout. It triggers the "Extrude to Cursor"
operator since it is called by CTRL+LMB wich is exactly the event that
is sent in this case.
I'm not totally happy with this workaround since it changes the Confirm/
Abort event for all transformation actions to key release which *might*
result in more conflicts (fingers crossed this isn't the case). If this
happens we might need to write some special transformation handling for
extrusion.
This is an example of the difficulties we get from loading too much
functions on the same keys - we need to be careful with that!
Also cleanup extrude code.
- remove normal calculation.
- remove return values for transform type.
- use enums.
Thanks to Psy-fi for finding the initial fix.
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
