All the controls were just really thrown in there without any proper
organization.
This gives it more structure.
- Correct use of sub-panels to communicate hierarchy and sections.
- Use flow layout for toggles.
- Use consistent names for "Bake Type".
Smaller adjustments to the Light Probe properties layout.
- Correctly use alignment for multi-property values.
- Correctly use sub-panels.
- Correctly use PROP_FACTOR for visibility_bleed_bias and
visibility_blur.
Some RNA errors are quite similar, use clog for consistent logging that
always includes the file, function and line number - making errors
quicker to troubleshoot.
This affects point, spot and area lights. Sun light strength remains without
a unit. This change does not affect .blend file compatibility in any way, as
with the rest of the unit system it's purely a display and editing feature.
Not used for Cycles yet, that will be done after unifying the settings with
Eevee.
The code assumed all datablocks were read from .blend files saved with the
same version. This restructures the Cycles versioning code to take into
account libraries.
When modal map was introduced, left out handling of what
happens when bevel is made active tool in toolbar and user
starts bevel by clicking and dragging.
Fail to build on errors in new names - without this renamed values
would be written to DNA breaking backwards & forwards compatibility.
Note that errors in old names aren't detected.
This allows us to rename struct & struct members in the source code
without changing the file format.
This is useful because the code becomes increasingly confusing when
names such as oops, ipo & dupli aren't used anywhere except DNA headers.
dna_rename_defs.h is used to define renaming operations.
The renaming it's self will be done separately.
In this case we simply create a new screen area that copies the currently
fullscreened area.
Note: At the moment there is no indicative in the non-main window that we are in
fullscreen. That happens because this information is part of the bar and we have
no topbar in this window.
The problem
===========
For armature, if the active object was in pose mode and the newly
selected armature data (not the pose, but the edit armature) we would
get a crash.
For mesh objects, the issue would happen with the active object in object mode.
Then the new selected object would switch to edit mode, however the overall
mode would still be object mode, leading to unsynced mode across the objects.
The solution
============
Using shift to extend selection makes current selected (compatible)
objects to go to edit mode as well. Otherwise only the newly selected
object will switch to edit mode.
This also works if you are in edit mode for a curve, and click in a mesh icon.
This also changes the rules for multi-object editing (or rather, how we
put objects in and out of it). Now shirt is also taking into
consideration there. So if you simply click in another mesh object's
data, it will have only the newly selected object in edit mode.
To reproduce the old behaviour you need to use shift to include the
newly selected object in the multi-edit party.
Reviewers: campbellbarton
Subscribers: brecht
Differential Revision: https://developer.blender.org/D4344
was caused by rBc6e3a20ab60b, copied node was actually added to the
nodetree, resulting in an endless loop.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4360
At some I unified the "move to collection" with the remove from all collections
functionality. That meant that even when we were still to keep the object in one
of the collections we would clear its rigid body data.
Now why to even remove the rigidbody data when removing an object from all
collections? That mimics the 2.79 behaviour when we were to unlink an
object from a scene. I suspect it has to do with the rigid body data
being tied to the scene rigid body. Which is a strange design anyways
(add to the list?) since an object can be in more than one scene.
Is mainly used by drivers variables. The slow part was about
iterating over all pose channels to find the one which has a
given constraint.
Now we build a look up table, so this operation is way cheaper,
Brings down relations update time from 0.7sec to 0.4 with Spring
production file.
