Currently, a node either supports lazyness during execution (like the Switch
node), or it doesn't. If it does support lazyness, then every input is computed
lazily. However, usually not all inputs actually have to be computed lazily.
E.g. the boolean switch input is always required, while the other inputs
should be computed lazily.
Better support for such sockets can avoid unnecessary round trips through
the node execution function.
At the time of allocating the buffer with vertices in context, we don't
know exactly how many vertices are affected, but we do know that it is
less than or equal to twice the number of vertices killed.
The array modifier does not necessarily tag normals dirty.
If it doesnt, normals are recalculated "internally" using the offset ob
transform. This was happening for the array items, but not for the caps.
Now do the same thing for caps.
Maniphest Tasks: T94422
Differential Revision: https://developer.blender.org/D13681
I had assumed that the span's size was the same as the length variable.
In the future, separate lengths could be removed in favor of using
lengths directly from spans.
This evaluator is used in order to evaluate subdivision at render time, allowing for
faster renders of meshes with a subdivision surface modifier placed at the last
position in the modifier list.
When evaluating the subsurf modifier, we detect whether we can delegate evaluation
to the draw code. If so, the subdivision is first evaluated on the GPU using our own
custom evaluator (only the coarse data needs to be initially sent to the GPU), then,
buffers for the final `MeshBufferCache` are filled on the GPU using a set of
compute shaders. However, some buffers are still filled on the CPU side, if doing so
on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose
logic is hardly GPU compatible).
This is done at the mesh buffer extraction level so that the result can be readily used
in the various OpenGL engines, without having to write custom geometry or tesselation
shaders.
We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in
order to control the data layout, and interpolation. For example, we store vertex colors
as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float
types.
In order to still access the modified geometry on the CPU side, for use in modifiers
or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`.
Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will
create such a wrapper if possible. If the final subdivision surface is not needed on
the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used.
Enabling or disabling GPU subdivision can be done through the user preferences (under
Viewport -> Subdivision).
See patch description for benchmarks.
Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport
Differential Revision: https://developer.blender.org/D12406
This adds `blender::is_same_any_v` which is the almost the same as
`std::is_same_v`. The difference is that it allows for checking multiple
types at the same time.
Differential Revision: https://developer.blender.org/D13673
The crash happens when opening a panel (added in rB43f5e761a66e87fed664a199cda867639f8daf3e)
when no CacheFile is set in the modifier.
To fix this, check that the CacheFile pointer is not null before attempting to draw anything.
This adds interface panels to organize the Cache File UI parameters for
modifiers and constraints into related components: velocity, time, and
render procedural.
Properties relating to the three aforementioned components are separated
from `uiTemplateCacheFile` into their own functions (e.g.
`uiTemplateCacheFileVelocity` for the velocity one), which are in turn
called from the specific panel creation routines of the modifiers and
constraints (for constraints, the functions are exposed to the RNA).
`uiTemplateCacheFile` now only shows the properties for the file path,
and in the case of constraints, the scale property.
The properties that are only defined per modifier (like the velocity
scale), are shown in the proper modifier layout panel if applicable.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D13652
Previously, the values passed to a multi-input socket were stored
in the order that they arrived in. Then, when the values are accessed,
they are sorted depending on the link order.
Now, the ordering is determined in the beginning before execution starts.
Every value is assigned to the right index directly, avoiding the sort
in the end. This makes the ordering more explicit.
Goals of this refactor:
* More unified approach to updating everything that needs to be updated
after a change in a node tree.
* The updates should happen in the correct order and quadratic or worse
algorithms should be avoided.
* Improve detection of changes to the output to avoid tagging the depsgraph
when it's not necessary.
* Move towards a more declarative style of defining nodes by having a
more centralized update procedure.
The refactor consists of two main parts:
* Node tree tagging and update refactor.
* Generally, when changes are done to a node tree, it is tagged dirty
until a global update function is called that updates everything in
the correct order.
* The tagging is more fine-grained compared to before, to allow for more
precise depsgraph update tagging.
* Depsgraph changes.
* The shading specific depsgraph node for node trees as been removed.
* Instead, there is a new `NTREE_OUTPUT` depsgrap node, which is only
tagged when the output of the node tree changed (e.g. the Group Output
or Material Output node).
* The copy-on-write relation from node trees to the data block they are
embedded in is now non-flushing. This avoids e.g. triggering a material
update after the shader node tree changed in unrelated ways. Instead
the material has a flushing relation to the new `NTREE_OUTPUT` node now.
* The depsgraph no longer reports data block changes through to cycles
through `Depsgraph.updates` when only the node tree changed in ways
that do not affect the output.
Avoiding unnecessary updates seems to work well for geometry nodes and cycles.
The situation is a bit worse when there are drivers on the node tree, but that
could potentially be improved separately in the future.
Avoiding updates in eevee and the compositor is more tricky, but also less urgent.
* Eevee updates are triggered by calling `DRW_notify_view_update` in
`ED_render_view3d_update` indirectly from `DEG_editors_update`.
* Compositor updates are triggered by `ED_node_composite_job` in `node_area_refresh`.
This is triggered by calling `ED_area_tag_refresh` in `node_area_listener`.
Removing updates always has the risk of breaking some dependency that no
one was aware of. It's not unlikely that this will happen here as well. Adding
back missing updates should be quite a bit easier than getting rid of
unnecessary updates though.
Differential Revision: https://developer.blender.org/D13246
In this commit I changed many loops to range-based for loops.
I also removed some of the redundant iterator variables, using
indexing inside the loop instead. Generally an optimizing compiler
should have no problem doing the smartest thing in that situation,
and this way makes it much easier to tell where data is coming from.
I only changed the loops I was confident about, so there is still more
that could be done in the future.
Differential Revision: https://developer.blender.org/D13637
This moves `MOD_weld.cc` to C++, fixing compiler warnings
coming from the change. It also goes a little bit further and converts
the code to use C++ data structures: `Span`, `Array`, and `Vector`.
This makes the code more shorter and easier to reason about, and
makes memory maneagement more automatic.
Differential Revision: https://developer.blender.org/D13618
The style guide mentions that unsigned integers shouldn't be used to
show that a value won't be negative. Many places don't follow this
properly yet. The modifier used to cast an array of `uint` to `int` in
order to pass it to `BLI_kdtree_3d_calc_duplicates_fast`. That is no
longer necessary.
Differential Revision: https://developer.blender.org/D13613
Using the `MEM_*` API from C++ code was a bit annoying:
* When converting C to C++ code, one often has to add a type cast on
returned `void *`. That leads to having the same type name three times
in the same line. This patch reduces the amount to two and removes the
`sizeof(...)` from the line.
* The existing alternative of using `OBJECT_GUARDED_NEW` looks a out
of place compared to other allocation methods. Sometimes
`MEM_CXX_CLASS_ALLOC_FUNCS` can be used when structs are defined
in C++ code. It doesn't look great but it's definitely better. The downside
is that it makes the name of the allocation less useful. That's because
the same name is used for all allocations of a type, independend of
where it is allocated.
This patch introduces three new functions: `MEM_new`, `MEM_cnew` and
`MEM_delete`. These cover the majority of use cases (array allocation is
not covered).
The `OBJECT_GUARDED_*` macros are removed because they are not
needed anymore.
Differential Revision: https://developer.blender.org/D13502
This patch refactors the instance-realization code and adds new functionality.
* Named and anonymous attributes are propagated from instances to the
realized geometry. If the same attribute exists on the geometry and on an
instance, the attribute on the geometry has precedence.
* The id attribute has special handling to avoid creating the same id on many
output points. This is necessary to make e.g. the Random Value node work
as expected afterwards.
Realizing instance attributes has an effect on existing files, especially due to the
id attribute. To avoid breaking existing files, the Realize Instances node now has
a legacy option that is enabled for all already existing Realize Instances nodes.
Removing this legacy behavior does affect some existing files (although not many).
We can decide whether it's worth to remove the old behavior as a separate step.
This refactor also improves performance when realizing instances. That is mainly
due to multi-threading. See D13446 to get the file used for benchmarking. The
curve code is not as optimized as it could be yet. That's mainly because the storage
for these attributes might change soonish and it wasn't worth optimizing for the
current storage format right now.
```
1,000,000 x mesh vertex: 530 ms -> 130 ms
1,000,000 x simple cube: 1290 ms -> 190 ms
1,000,000 x point: 1000 ms -> 150 ms
1,000,000 x curve spiral: 1740 ms -> 330 ms
1,000,000 x curve line: 1110 ms -> 210 ms
10,000 x subdivided cylinder: 170 ms -> 40 ms
10 x subdivided spiral: 180 ms -> 180 ms
```
Differential Revision: https://developer.blender.org/D13446
This node outputs the current scene time in seconds or in frames.
Use of this node eliminates the need to use drivers to control values
in the node tree that are driven by the scene time.
Frame is a float value to provide for subframe rendering for motion
blur.
Differential Revision: https://developer.blender.org/D13455
The type conversions do not depend on other files in the nodes
module. Furthermore we want to use the conversions in the
geometry module without creating a dependency to the
nodes module there.
Caused by {rB3b6ee8cee708}
Above commit was trying to get the vertexgroup from the mesh that is
passed into `deformVertsEM` (but that can be NULL).
When can it be NULL, when is is non-NULL?
`editbmesh_calc_modifiers` only passes in a non-NULL mesh to
`deformVertsEM` under certain conditions:
- a non-deform-only modifier is handled currently
- a non-deform-only modifier preceeds the current modifier
- a deform-only modifier preceeds the current modifier (and the current
one depends on normals)
So the passed-in mesh cannot be relied on, now get the vertex group from
the context object data (like it was before the culprit commit).
Related commit: rB8f22feefbc20
Maniphest Tasks: T93611
Differential Revision: https://developer.blender.org/D13487
When enabling or disabling a Mesh Sequence Cache modifier of an Object
with a hair particle system, the hair would switch positions. This is
caused because original coordinates in Blender are expected to be
normalized, and toggling the modifier would cause the usage of different
orco layers: one that is normalized, and the other which isn't.
This bug exposes a few related issues:
- if the Alembic file did not have orco data,
`MOD_deform_mesh_eval_get`, used by the particle system modifier, would
add an orco layer without normalization
- `MOD_deform_mesh_eval_get` would also ignore the presence of an orco
layer (e.g. one that could have been read from Alembic)
- if the Alembic file did have orco data, the data would be read
unnormalized
To fix those various issues, original coordinates are normalized when
read from Alembic and unnormalized when written to Alembic; and a new
utility function `BKE_mesh_orco_ensure` is added to add a normalized
orco layer if none exists on the mesh already, this function derives
from the code used in the particle system.
Reviewed By: brecht
Maniphest Tasks: T92561
Differential Revision: https://developer.blender.org/D13306
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
