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.
This commit moves the list of transform orientations from scenes to workspaces.
Main reasons for this are:
* Transform orientations are UI data and should not be stored in the scene.
* Introducion of workspaces caused some (expected) glitches with transform orientations. Mainly when removing one.
* Improves code.
More technically speaking, this commit does:
* Move list of custom transform orientations from Scene to WorkSpace struct.
* Store active transform orientation index separate from View3D.twmode (twmode can only be set to preprocessor defined values now).
* Display custom transform orientation name in header when transforming in it (used to show "global" which isn't really correct).
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
Note that I also made 'dash anchor point' consistent (the static one,
not the mouse one), in previous code somtimes dashed were anchored to
the static center point, in others, to the moving mouse position, the
later was rather disturbing imho...
