When saving a file in Edit mode with Multiframe enabled, the render did not include the modifiers.
Now the multiframe is not enabled if it's doing a render.
Multi-overrides of a same linked ID in a same override hierarchy are
currently not supported and can cause all kind of issues.
In some cases they could lead to infinite loop trying to resync the same
ID over and over, this is now prevented.
Found in some Blender studio production files.
The algorithm that calcualted the direction (inside/outside) of the
polyline was not always returing the correct result. This mean that the
polyline was filled "inside-out".
The fix uses the winding number to calculate the inside and outside.
Reviewed By: antoniov, pepeland
Maniphest Tasks: T87718
Differential Revision: https://developer.blender.org/D11054
Generally, it would be good to not allow this from happening in the
first place but that is quite tricky because an object does not know
which other object instances it. Similar checks might be necessary
in other places, but this fixes the bug already.
Differential Revision: https://developer.blender.org/D11086
This fixes T87666 and T83252.
The boolean modifier and geometry nodes can depend on the geometry
of an entire collection. Before, the modifiers had to manually create relations
to all the objects in the collection. This worked for the most part, but was
cumbersome and did not solve all issues. For example, the modifiers were not
properly updated when objects were added/removed from the referenced collection.
This commit introduces the concept of "collection geometry" in the depsgraph.
The geometry of a collection depends on the transforms and geometry of all
the objects in it. The boolean modifier and geometry nodes can now just depend
on the collection geometry instead of creating all the dependencies themselves.
Differential Revision: https://developer.blender.org/D11053
Though to my knowledge we haven't had a report about this yet, this
looks like a clear oversight-- the ids are just more data stored by the
instances component, and should be cleared and copied like other data.
This might have resulted in incorrect random IDs for instances in
renderers in some cases where the component had to be copied.
If an object named for example `Suzanne` is converted to Gpencil, a material called `Suzanne_Fill` will be created for the gpencil fill.
When this material already exists, the new material will be called `Suzanne_Fill.001` and the operator will not see that this material is already present the next iteration. This leads to a new material being created for every polygon.
This commit changes the code to search for a material starting with `ObjectName_Fill` instead of being equal to.
Reviewed By: filedescriptor, antoniov
Differential Revision: https://developer.blender.org/D11067
This is complex situation. Tagged ID deletion (used to delete several
data-blocks at once) removes IDs to be deleted from Main.
But when we remove deleted IDs' usages of other IDs (using
`BKE_libblock_relink_ex`), some specific post-process is required on
some types, like Collections. Those post-processes would in some cases
rely on data actually being in Main.
That failing condition would lead in existing code on missing processing
the very ID (collection) we were working on, leading to missing removing
some child collection pointers, leading to the crash (later on in
LayerCollection resync process).
For now we go with an optimization & fix that avoids processing all
collections in Main when we actually know which one we are working one
(case of `BKE_libblock_relink_ex`, but not of
`BKE_libblock_remap_locked`).
This is however yet another demonstration of the need to rework that
whole collection/layer resync process, since it is not only extremely
inneficient currently, but it also requires valid Main/ID state way too
deep into the remapping code.
NOTE: This fix may very well not catch/address all possible fail cases
here, dealing with the double parent/child relationships of collections
is challenging...
Issue reported by @eyecandy from the studio, thanks.
The `bisect_distance` in the mirror modifier was hard-coded to `0.001`.
This would result in some unexpected behavior like vertices close
to the mirror plane being deleted or merged.
The fix now adds a parameter to the mirror modifier to expose the
bisect distance to the user. The default is set to the previous
hard-coded value to not "change" previous files.
Ref D10201
Some persistent data code was disable due to a deeper design issue, which
meant some updates were not communicated to renderers.
Dependency graph updates work in two passes, once where Blender scene
animation updates are done, then app handler scripts can run to make further
scene modifications, and then the depsgraph is updated again to take those
into account.
Previously the viewport would update renderers twice when such app handler
scripts were present. Now both viewport and persistent data rendering update
the renderers only once, accumulating updates from both passes.
`ob->runtime.geometry_set_eval` can contain instances as well.
This only affected instances generated by geometry nodes.
We should probably have a separate function that tells us if an object
has instances or not..
In the past, custom attributes were rarely used in practice, because the
only way to use them was from Python. Since geometry nodes, more
users started to add their own attributes. Those attributes should not
be removed automatically. It is still possible to remove them in
geometry nodes explictly to improve performance.
This introduces a context path to the spreadsheet editor, which contains
information about what data is shown in the spreadsheet. The context
path (breadcrumbs) can reference a specific node in a node group
hierarchy. During object evaluation, the geometry nodes modifier checks
what data is currently requested by visible spreadsheets and stores
the corresponding geometry sets separately for later access.
The context path can be updated by the user explicitely, by clicking
on the new icon in the header of nodes. Under some circumstances,
the context path is updated automatically based on Blender's context.
This patch also consolidates the "Node" and "Final" object evaluation
mode to just "Evaluated". Based on the current context path, either
the final geometry set of an object will be displayed, or the data at
a specific node.
The new preview icon in geometry nodes now behaves more like
a toggle. It can be clicked again to clear the context path in an
open spreadsheet editor.
Previously, only an object could be pinned in the spreadsheet editor.
Now it is possible to pin the entire context path. That allows two
different spreadsheets to display geometry data from two different
nodes.
The breadcrumbs in the spreadsheet header can be collapsed by
clicking on the arrow icons. It's not ideal but works well for now.
This might be changed again, if we get a data set region on the left.
Differential Revision: https://developer.blender.org/D10931
This patch adds domain and data type information to each row of the
attribute search menu. The data type is displayed on the right, just
like how the list is exposed for the existing point cloud and hair
attribute panels. The domain is exposed on the left like the menu
hierarchy from menu search.
For the implementation, the attribute hint information is stored as a
set instead of a multi-value map so that every item (which we need to
point to descretely in the search process) contains the necessary data
type and domain information by itself. We also need to allocate a new
struct for every button, which requires a change to allow passing a
newly allocated argument to search buttons.
Note that the search does't yet handle the case where there are two
attributes with the same name but different domains or data types in
the input geometry set. That will be handled as a separate improvement.
Differential Revision: https://developer.blender.org/D10623
Previously, the bone position outside of "fit to curve length" mode was
incorrect.
It assumed that the curve was completely straight with no bends or
turns. This would lead to bones being scaled down as their final
position would be servery underestimated in some cases.
The solution is to do a sphere -> curve intersection test to see where
to put the bones while still preserving their length. As we are using
the tessellated curve data this essentially boils down to us doing a
sphere -> line intersection check.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D10849
This is especially useful when trying to add a node group instance, e.g. via
drag & drop from the Outliner or Asset Browser.
Previously this would just silently fail, with no information why. This is a
source of confusion, e.g. earlier, it took me a moment to realize I was
dragging a node group into itself, which failed of course.
Blender should always try to help the user with useful error messages.
Adds error messages like: "Nesting a node group inside of itself is not
allowed", "Not a compositor node tree", etc.
Adds a disabled hint return argument to node and node tree polling functions.
On error the hint is reported, or could even be shown in advance (e.g. if
checked via an operator poll option).
Differential Revision: https://developer.blender.org/D10422
Reviewed by: Jacques Lucke
Before rBf674976edd88, the flag indicating whether a curve was 2D or 3D was
ignored by Surfaces objects.
So it can be said that Surfaces objects were always 3D.
We could remove updates to 2D on Surface objects, so the behavior is
identical to what it was before.
But this would also cause the return of `data.dimensions` to be misleading,
complicate the code a bit and add a micro overhead.
So the solution here is just to init all Surface objects as 3D.
Surface objects can now be constrained to 2D with the command:
```
data.dimensions = '2D'
```
Linked override were not properly ignored in some part of the code,
leading to invalid resync results in some cases with recursive overrides
(i.e. overrides of overrides).
Reported by Andy @eyecandy from the studio.
We do not want to copy exiting overrides data from linked ID when
creating its local override (be it either a template, or because linked
ID is itself an override of another lib data).
Note that this was not a very serious issue, would just cause some memory
leak since override data is re-created on newly copied local data
anyway.
These use cases have been very little tested so far, but both complex
production pipeline and future restrictive workflow will make them fairly
common...
Relying on only no-main for that was weak, and inn the end it turns out
we sometimes also need to ifnore override data during copy of Main
data-blocks.
NOTE: The new `LIB_ID_COPY_NO_LIB_OVERRIDE` is also added to the
`LIB_ID_COPY_LOCALIZE` set of flags.
NOTE: The fact that we may now copy liboverrides in some non-main cases
may cause issues in some cases, pretty impossible to track all possible
ones from reading the code... Would not expect too many problem though,
usages of `LIB_ID_CREATE_NO_MAIN` by itself are not so common.
A `DataSource` provides columns for the spreadsheet to display.
Every column has a SpreadsheetColumnID as identifier. Columns
are not generated eagerly anymore, instead the main spreadsheet
code can request a column from a data source with an column
identifier. The column identifiers can be stored in DNA and allow us
to store persistent data per column.
On the user level the only thing that changes is that columns are
not shown in alphabetical order anymore. Instead, new columns
are always added on the left. The behavior can be changed,
however I'd prefer not to automate this too much currently. I think
we should just add operators to hide/reorder/resize columns soonish.
Differential Revision: https://developer.blender.org/D10901
This is a minor change to add some plumbing code
to support custom geo nodes. This is working the
same way as the custom cycles and compositor nodes.
An example add-in is attached to D10784
Reviewed By: JacquesLucke
Differential Revision: http://developer.blender.org/D10784
Where possible, nodes in the "Geometry" category should support all
geometry component types. This adds support for volumes in the
recently added bounding box node, based on functions added in the
previous two commits.
Differential Revision: https://developer.blender.org/D10906
This commit splits of the function that generates a bounding box for a
volume into a new function, so that the min and max coordinate can
be retrieved from volume data without an object. Also some cleanup:
using the float3 type.
Often you need to apply a transformation to a grid without changing the
original, and it's necessary to avoid a deep copy of the actual data.
OpenVDB has a function to do this, this commit simply adds a wrapper
to transform and use that function with blender's `float4x4` data type.
Split from D10906
Previously only attributes of "real" geometry were displayed in
attribute search. This commit adds code to look through attributes
on instances and add those to the search drop-down too.
This required implementing the same sort of recursive traversal as
the realize instances code. The situation is a bit different though,
this can return early and doesn't need to keep track of transforms.
I added a limit so that it doesn't look through the attributes of
too many instanced geometry sets. I think this is important, since
this isn't a trivial operation and it could potentially happen for
every node in a large node tree. Currently the limit is set at 8
geometry sets, which I expect will be enough, since the set of
attributes is mostly not very unique anyway.
Fixes T86282
Diffrential Revision: https://developer.blender.org/D10919
