Previously only the active object was used.
Use coroutines to support baking frames for multiple objects at once,
without having to playback the animation multiple times.
This exposes 2 methods for manipulators:
- new_custom_shape
- draw_custom_shape
This can be used for script authors to create and re-use shapes
without dealing with lower level API's.
This changes the Cycles exporting and Cycles/Eevee UI code to support both
output material nodes, giving priority to the renderer native one. Still
missing is Eevee code to prefer the Eevee output node.
Now that some node types may have custom context, we need to handle that
in the (convoluted :| ) UI code of nodes as well.
Reported in T43295 by Gabriel Gazzán (@gab3d), thanks.
Initial support for Python/Manipulator integration
from 'custom-manipulators' branch.
Supports:
- Registering custom manipulators & manipulator-groups.
- Modifying RNA properties, custom values via get/set callbacks,
or invoking an operator.
- Drawing shape presets for Python defined manipulators (arrow, circle, face-maps)
Limitations:
- Only float properties supported.
- Drawing only supported via shape presets.
(we'll likely want a way to define custom geometry or draw directly).
- When to refresh, recalculate manipulators will likely need
integration with notifier system.
Development will be continued in the 2.8 branch
We could not edit them, but still could delete them, which makes no
sense, API-defined properties are similar to class members, removing
them from single instances is pure garbage. And it was broken anyway.
Found by @a.romanov while checking on T51198, thanks.
Doing this in a fully 'clean' way is far from obvious, especially
unregister, you often end up leaving nasty 'orphanned' keymap items
referring to unregistered operators...
Moving to manual class registration means its easier to accidentally
miss registering classes.
Now detect missing class registration
and warn when running with `--debug-python`
