The mirror modifiers merge option caused unnecessary re-ordering
to the vertex array with original vertices merging into their copies.
While this wasn't an error, it meant creating a 1:1 mapping from input
vertices to their final output wasn't reliable (when looping over
vertices first to last) as is done in
BKE_editmesh_vert_coords_when_deformed.
As merging in either direction is supported, keep the source meshes
vertices in-order since it allows the vertex coordinates to be extracted.
NOTE: Since this change introduce issues for some cases (e.g. bound
modifiers like SurfaceDeform), this change is only applied to newly
created modifiers, existing ones will still use the old incorrect merge
behavior.
Reviewed By: @brecht
Maniphest Tasks: T93321, T91444
Differential Revision: https://developer.blender.org/D13355
When a node is executed, it usually schedules other nodes.
Right now, those newly scheduled nodes are added to a
task pool so that another thread can start working on them
immediatly.
However, that leads to the situation where sometimes each
node in a simple chain is executed by another thread. That
leads to additional threading overhead and reduced cache
efficiency (for caches that are not shared between cores).
Now, when a node is executed and schedules other nodes,
the first of those newly scheduled nodes will always be
executed on the same thread once the current node is done.
If it schedules more than one other node, those will be
added to the task pool as before.
The speedup achieved by this is hard to measure. I found it
to be a couple percent faster in some extreme cases, not
much to get excited about. It's nice though that the number
of tasks added to the task pool is commonly reduced by a
factor of 4 or 5.
This is only meant to be used for development purposes for now,
not to show warnings to the user.
Differential Revision: https://developer.blender.org/D13348
Previously, there were a couple of cases where nodes were scheduled when
that was not really necessary. This change doesn't seem to have a big impact
on performance, but simplifies the code a bit.
Alternative to D13291 (description partially copied from there).
New drag & drop reordering code would call constraints reordering
operator with the generic context, and not the one from the panel's
layout. missing the "constraint" member which is mandatory for poll
function to properly deal with override vs. local constraints.
For this to work in a decent way, there needs to be some panel-wide
context that we can restore when executing callbacks outside of the
normal draw context. So similar to uiLayoutSetContextPointer() to set
context on a layout level, this introduces
UI_panel_context_pointer_set() for panel level context (this calls the
former for the current panel root layout as well).
Differential Revision: https://developer.blender.org/D13308
Adds a new overlay called "Timings" to the Geometry Node editor.
This shows the node execution time in milliseconds above the node.
For group nodes and frames, the total time for all nodes inside
(recursively) is shown. Group output node shows the node tree total.
The code is prepared for easily adding new rows of information
to the box above the node in the future.
Differential Revision: https://developer.blender.org/D13256
Currently the geometry nodes evaluator always stores a field for every
type that supports it, even if it is just a single value. This results in a lot
of overhead when there are many sockets that just contain a single
value, which is often the case.
This introduces a new `ValueOrField<T>` type that is used by the geometry
nodes evaluator. Now a field will only be created when it is actually
necessary. See D13307 for more details. In extrem cases this can speed
up the evaluation 2-3x (those cases are probably never hit in practice
though, but it's good to get rid of unnecessary overhead nevertheless).
Differential Revision: https://developer.blender.org/D13307
This regression was introduced by D11832, but there was problems before
that as well. I seem to have missed it in review. See the differential
revision for a screenshot of the difference.
Differential Revision: https://developer.blender.org/D13216
It's valid for a node group connected to the modifier not to
have a geometry input, but I didn't consider that case
with the last change I made here, f3bdabbe24.
Differential Revision: https://developer.blender.org/D13231
The code assumed that any geometry input that wasn't the first input
was a second geometry input. Fix by separating the warning for the
first input and for the number of geometry inputs.
rBc473b2ce8bdbf8fa42 improved the situation somewhat, but
attribute search still crashes during animation playback, because
the UI search data references stale memory. The proper solution
is to allow the search to own data rather than just referencing it,
but I would prefer not to do that for 3.0. In the meantime, just
disable attribute search when animation is playing.
Differential Revision: https://developer.blender.org/D13179
This commit adds modifier error messages to some of the cases
where the node group is configured improperly. It also clears the
geometry set when there is an error with the node group. This is
consistent to what we do in nodes themselves, and feels more
intuitive than passing the input geometry through the node group
silently.
Fixes T87142
Decorators were only added for the first item of an array.
Decorators for all items of an array are added:
- if the layout is flagged `UI_ITEM_PROP_DECORATE` automatically in
`uiItemFullR` or
- calling `uiItemDecoratorR` (but only in certain situations, see below)
When calling `uiItemDecoratorR` with an index of 0, the following
happens:
- the index is passed to `uiItemDecoratorR_prop`
- that checks with `ui_item_rna_is_expand` if decorators should be added
to all items of an array
- the check fails (because it only permits RNA_NO_INDEX -- which is -1)
So two things we can do:
- remain using `uiItemDecoratorR` (that would require to pass an index
of RNA_NO_INDEX -- a bad level include -- or -1
- just use `uiLayoutSetPropDecorate` to flag the row properly
This patch does later.
Differential Revision: https://developer.blender.org/D13159
Reference struct members by name instead relying on their order.
This also simplifies moving back to named members when all compilers
we use support them.
During animation playback, data-blocks are reallocated, so storing
pointers to the resulting data is not okay. Instead, the data should
be retrieved from the context. This works when the applied search
item is the "dummy" item added for non-matches. However, it still
crashes for every other item, because the memory is owned by the
modifier value log, which has been freed by the time the exec function
runs.
The next part of the solution is to allow uiSearchItems
to own memory for the search items.
Cloth modifier had a unique, weird and weak way of copying its
pointcache, now make it use `BKE_ptcache_copy_list` like done for e.g.
particles or softbody data.
The geometry node evaluator now has access to the entire socket path
from the node that produces a value to the node that uses it. This allows
the evaluator to make decisions about at which points in the path the
value should be converted. Multiple conversions may be necessary under
some circumstances with nested node groups.
Differential Revision: https://developer.blender.org/D13034
This is meant to add something to the sub-panel when it is empty
so it looks more purposeful, but also add a hint that might be helpful
when figuring out how to output a named attribute.
Differential Revision: https://developer.blender.org/D12715
Mantaflow could steal tasks from dependency graph, which under
certain conditions causes a recursive lock involving GIL.
Isolate threading done in mantaflow when it is interfaced form
the dependency graph.
Isolation done from the modifier, since the deeper calls are
branching out quite quickly.
Differential Revision: https://developer.blender.org/D13011
Instance IDs serve no purpose for rendering when they aren't stable from
one frame to the next, and if the index is used in the end anyway, there
is no point in storing a vector of IDs and copying it around.
This commit exposes the `id` attribute on the instances component,
makes it optional-- only generated by default with the distribute points
on faces node.
Since the string to curves node only added the index as each instance's
ID, I removed it. This means that it would be necessary to add the ID
data manually if the initial index actually helps (when deleting only
certain characters, for example).
Differential Revision: https://developer.blender.org/D12980
The leak happened when two things were true:
* Inside of a node group a socket is linked to a Group Input that has
a different type.
* The corresponding input on the parent Group node is not linked.
The conversion happened correctly, but the original value wasn't
destructed.
