* When resizing sidebars, don't collapse when the region becomes too big but
instead clamp the region size to the available space.
* Fix clicking the tab to expand sidebars no working if the sidebar is too
wide to fit. Instead make it less wide so it does fit.
* Fix incorrect limit on tool properties region height, for example in the
file browser.
Differential Revision: https://developer.blender.org/D4611
Random place in the modifier stack can not be referenced,
so it doesn't make sense to sue GEOMETRY component as a
FROM operation.
So now drivers on modifiers are driving GEOMETRY component,
but are using PARAMETERS as a source for variables.
A new parameter in the layer adjustment panel allows to define the color of the channel in Dopesheet.
This is needed when there are a lot of layers.
See D4623 for more details.
Caused by own recent rB17c15798c35f33e (already a fix in that code).
We cannot erase immediately master_collection's childrn list, as it is
used in sub-code to check in how many scenes an object is instanciated.
Further more, we only want to do the remove old/add new children
collections in case we are actually duplicating them.
Makes me even more eager to nuke that whole piece of code and rethink
from scratch that kind of ID handling. Some day...
We were already getting the designated output node in
'ntreeGPUMaterialNodes()' but this wasnt used in 'ntreeExecGPUNodes()',
instead whatever node was tagged NODE_DO_OUTPUT was executed.
note: this is just the bare minimum to fix the bug, other improvements
previously done in D4482 might follow as a separate commit.
Reviewers: brecht, fclem
Maniphest Tasks: T62434
Differential Revision: https://developer.blender.org/D4630
'Linked objects' option was not behaving correctly before, effectively
linking in collections, so this one has been renamed to just 'Linked Copy',
and gives a fully shallow copy of current scene.
'Linked Obdata' was not really useful, kind of confusing, and was
painful to maintain, so dropping it now.
Some alignment rules from Visual Studion on 32 bit are not taken into
account, this fixes the structs to confirm. We now have static asserts
to catch when such breakage happens in the future.
This is just not practical to do for the code as a whole, and having it as an
exception for one specific data structure is not that helpful. This has only
been in the way for me when refactoring code.
The issue is that Eevee directly evaluates animation on a datablock which
is a part of active dependency graph.
This is a broken logic by design and requires a complete revamp to support
more real life cases when camera is parented to a camera rig, but it is
beyond of what i can do with a simple bugfix.
Issue was that (deep) duplication code of scene ended up leaving
children collections of new master one without any parent.
Note that even though I think that fix is OK for now, we should really
make 'deep' duplication of IDs part of the generic ID management code.
Am less and less happy with current handling of this, done half from
/editors code, half from some semi-specialized helpers from /blenkernel,
with sometimes nearly the same logic replicated several times for
slightly different needs, etc. Unfortunately this would not be a small
refactor, so it will have to wait...
In extrude operator when the point was added, the weight data pointer was wrongly connected to old pointer.
Now, when move the data, the pointer is moved, but when a new point is added, the memory is duplicated to keep separated copies of the pointer.
This is related T62872
Thanks to @sergey for his help fixing this bug.
- Passing original object with apply_modifiers=false will give a
non-modified non-deformed mesh.
The result mesh will point to datablocks from the original "domain". For
example, materials will be original.
- Passing original object with apply_modifiers=true will give a mesh which
has all modifiers applied.
The result mesh will point to datablocks from the original "domain". For
example, materials will be original.
- Passing evaluated object will ignore apply_modifiers argument, and the
result always contains all modifiers applied.
The result mesh will point to an evaluated datablocks. For example,
materials will be an evaluated IDs from the dependency graph.
Fixes T62916: Applying boolean modifier does not set material properly
Differential Revision: https://developer.blender.org/D4604
This was wrong and violating design to force modifiers to query
evaluated objects and IDs. It is up to the caller to make sure
the object is properly evaluatable.
Effectively, reverting changes from de491abf99 (and possibly
other related changes).
Since there is a flush of evaluated values back to the original
for an active dependency graph we don't need this lookup anymore.
Not only it slows interface drawing down, but also is becoming
in a way of the upcoming fix.
Some iterations in bevel were over a hash table, which leads
to possibly different results run-to-run, especially when
loop_slide is enabled. Changed those iters to go over all verts
of BMesh, which leads to consistent order run-to-run.
The old logic was working if the eraser was moved towards the end of the stroke, but got ugly results when the eraser was done towards the start of the stroke.
Dynamic callbacks generating lists of tools should accept None context,
not crash on it.
Similar to what we do with dynamic RNA enums, when NULL/None context is
given, assume we are in 'introspection' mode and return as many things
as possible.
This is currently essentially used by i18n messages extraction tool
(where getting all possible entries is kind of mandatory ;) ).
Also add some initial missing tranlations for complex cases that cannot
be automated, there'll likely be more of that kind...
