Allows more than one snap mode to be enabled. So different combinations are possible.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Subscribers: Christopher_Anderssarian, duarteframos
Tags: #bf_blender_2.8
Differential Revision: D3400
Existing code checked pose/edit mode to check for transforming in an
objects local space.
This added many similar checks all over the code,
which leads to confusion.
Multi-edit caused a regression in UV transform since where UV's
had the object matrix applied by accident.
Now there is a boolean to use a local matrix,
this allows for any mode to have a 4x4 matrix
applied w/o adding mode specific checks everywhere.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
This adds initial multi-object editing support.
- Selected objects are used when entering edit & pose modes.
- Selection & tools work on all objects however many tools need porting
See: T54641 for remaining tasks.
Indentation will be done separately.
See patch: D3101
Both object level and camera datablock properties animation did not work with
copy on write enabled.
The root of the issue is going to the fact, that all interface elements are
referencing original datablock. For example, View3D has pointer to camera it's
using, and all areas which does access v3d->camera should in fact query for
the evaluated version of that camera, within the current context.
Annoying part of this change is that we now need to pass depsgraph in lots
of places. Which is rather annoying.
Alternative would be to cache evaluated camera in viewport itself, but then
it makes it annoying to keep things in sync.
Not sure if there is nicer solution here.
Reviewers: dfelinto, campbellbarton, mont29
Subscribers: dragoneex
Differential Revision: https://developer.blender.org/D3007
The RenderResult struct still has a listbase of RenderLayer, but that's ok
since this is strictly for rendering.
* Subversion bump (to 2.80.2)
* DNA low level doversion (renames) - only for .blend created since 2.80 started
Note: We can't use DNA_struct_elem_find or get file version in init_structDNA,
so we are manually iterating over the array of the SDNA elements instead.
Note 2: This doversion change with renames can be reverted in a few months. But
so far it's required for 2.8 files created between October 2016 and now.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D2927
We do have an history of those pieces of evil in our code, would be nice
to get fully rid of it, but at the very least let's not add more of them
in new code. :)
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
Goal is to make them more modular, to allow more variants (variable
single-color, thickness, ...) to be added without having to
copy-and-change-one-line of whole chain of shaders.
D2729 by @IgorNull
Currently, trackball rotation sequentially applies rotation across x axis and y axis,
which produces a strange/unusable result on diagonal pointer motion.
This change fixes the problem by using a single axis which is orthogonal
and proportional to mouse delta - matching view-port trackball.
There is no reason to be special for workspace and go against other design
decision in Blender. If something like this is going to become a common
practice in Blender it should be well thought and well tested, including
tests of all supported compilers and configurations.
This feature was relying on type re-definition, which is not only confusing
but also available in C11 only.
