While most modifies don't handle out of memory cases, ocean simulation
could attempt huge allocations: 2048 gb at the maximum resolution.
Resolves T83952.
This is an initial implementation of a USD importer.
This work is comprised of Tangent Animation's open source USD importer,
combined with features @makowalski had implemented.
The design is very similar to the approach taken in the Alembic
importer. The core functionality resides in a collection of "reader"
classes, each of which is responsible for converting an instance of a
USD prim to the corresponding Blender Object representation.
The flow of control for the conversion can be followed in the
`import_startjob()` and `import_endjob()` functions in `usd_capi.cc`.
The `USDStageReader` class is responsible for traversing the USD stage
and instantiating the appropriate readers.
Reviewed By: sybren, HooglyBoogly
Differential Revision: https://developer.blender.org/D10700
This improve the cloth modeling workflow by allowing you to weld only the
edges that are used for the sewing forces.
Reviewed By: mano-wii, weasel
Differential Revision: https://developer.blender.org/D10710
With this commit, node warnings added to nodes during evaluation
(not "Info" warnings) will also draw in the modifier. In the future
there could be a "search for this node" button as well.
Differential Revision: https://developer.blender.org/D11983
Currently the wording is a bit unclear: it doesn't specify //what// the particles will be converted into. This clarifies it by stating what the particles will be converted into: they will either be converted to a mesh or the instances will be made real.
Reviewed By: Blendify
Differential Revision: https://developer.blender.org/D11795
When a vertex group is used to limit the influence of the modifier
to a subset of vertices, binding data for vertices with zero weight
is not needed. This wastes memory, disk space and CPU cycles.
If the vertex group contents is known to be final and constant,
it is reasonable to optimize by only storing data group vertices.
This has to be an option in case the group can change.
Supporting this requires adding a vertex index field and spliting
the vertex count into mesh and bind variants, but both happen to
fit in available padding. The old numverts field is renamed to the
new bound vertex count field to maintain the array length invariant.
Versioning is used to initialize the other new fields.
If a file with sparse binding is opened in an old blender version,
it is corrupted into a non-sparse bind with vertex count mismatch,
preventing the modifier from working until rebind.
Differential Revision: https://developer.blender.org/D11924
Issue would happen when the original, linked data already had 'Disk Cache'
setting enabled. Override would then see no difference with linked data,
and not create any rule for it (as expected).
Root of the issue was that in Cloth modifier copy code, those disk cache
settings were not copied at all, so every time local overrides were
re-generated by copying linked data, those flags would be reset to their
default values.
NOTE: this might exist in other PointCache usages as well, but this code is
in such a bad state that I'd rather do minimal strictly needed changes
there, on a case-by-case basis. Proper recode of that whole system is
wayyyyy out of scope here.
This commit moves the storage of `bDeformGroup` and the active index
to `Mesh`, `Lattice`, and `bGPdata` instead of `Object`. Utility
functions are added to allow easy access to the vertex groups given
an object or an ID.
As explained in T88951, the list of vertex group names is currently
stored separately per object, even though vertex group data is stored
on the geometry. This tends to complicate code and cause bugs,
especially as geometry is created procedurally and tied less closely
to an object.
The "Copy Vertex Groups to Linked" operator is removed, since they
are stored on the geometry anyway.
This patch leaves the object-level python API for vertex groups in
place. Creating a geometry-level RNA API can be a separate step;
the changes in this commit are invasive enough as it is.
Note that opening a file saved in 3.0 in an earlier version means
the vertex groups will not be available.
Differential Revision: https://developer.blender.org/D11689
Confusingly, BKE_scene_frame_get did not match the frame number as expected by
BKE_scene_frame_set. Instead it return the value after time remapping, which
is commonly named "ctime".
* Rename BKE_scene_frame_get to BKE_scene_ctime_get
* Add a new BKE_scene_frame_get that matches BKE_scene_frame_set
* Use int/float depending if fractional frame is expected
The 'collection' property is flagged PROP_ID_REFCOUNT, so the
modifiers foreachIDLink functions should walk with IDWALK_CB_USER
(instead of IDWALK_CB_NOP).
Otherwise the modifier wont be included as a user for the collection
(e.g. on file read); removing the collection from the modifier will
decrement usercount though (which in worst case scenario makes the
collection orphan and will result in data loss)
Maniphest Tasks: T89765
Differential Revision: https://developer.blender.org/D11877
The original assumption that the `modifyMesh` function is only
called when the modifier is applied was wrong. There are still a
couple of other places calling it through `BKE_modifier_modify_mesh`.
Now there is an extra check that makes sure instances are only
realized when the modifier is actually applied.
Many ui features for geometry nodes need access to information generated
during evaluation:
* Node warnings.
* Attribute search.
* Viewer node.
* Socket inspection (not in master yet).
The way we logged the required information before had some disadvantages:
* Viewer node used a completely separate system from node warnings and
attribute search.
* Most of the context of logged information is lost when e.g. the same node
group is used multiple times.
* A global lock was needed every time something is logged.
This new implementation solves these problems:
* All four mentioned ui features use the same underlying logging system.
* All context information for logged values is kept intact.
* Every thread has its own local logger. The logged informatiton is combined
in the end.
Differential Revision: https://developer.blender.org/D11785
This adds a viewer node similar to the one in the compositor.
The icon in the headers of nodes is removed because it served
the same purpose and is not necessary anymore.
Node outputs can be connected to the active viewer using
ctrl+shift+LMB, just like in the compositor. Right now this collides
with the shortcut used in the node wrangler addon, which will
be changed separately.
As of now, the viewed geometry is only visible in the spreadsheet.
Viewport visualization will be added separately.
There are a couple of benefits of using a viewer node compared
to the old approach with the icon in the node header:
* Better support for nodes that have more than one geometry output.
* It's more consistent with the compositor.
* If attributes become decoupled from geometry in the future,
the viewer can have a separate input for the attribute to visualize.
* The viewer node could potentially have visualization settings.
* Allows to keep "visualization points" around by having multiple
viewer nodes.
* Less visual clutter in node headers.
Differential Revision: https://developer.blender.org/D11470
Using BMesh operators through the edit-mesh API created a full copy
of the mesh so it was possible to restore the mesh in case
one of the operators raised an error.
Remove support for automatic backup/restore from the EDBM_op_* API's
as it adds significant overhead and was rarely used.
Operators that need this can use the BMBackup API to backup & restore
the mesh in case of failure.
Add warning levels to BMO_error_raise so operators can report problems
without it being interpreted as a request to cancel the operation.
For high-poly meshes creating and freeing a full copy is an expensive
operation, removing this gives a speedup of ~1.77x for most operators
except for "connect_verts" / "connect_vert_pair"
which still uses this functionality.
* Reduce code duplication.
* Give methods more standardized names (e.g. `move_to_initialized` -> `move_assign`).
* Support wrapping arbitrary C++ types, even those that e.g. are not copyable.
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
This makes the parts where a node is locked more explicit. Also, now the thread
is isolated when the node is locked. This prevents some kinds of deadlocks
(which haven't happened in practice yet).
- BKE_mesh_copy_parameters_for_eval to be used for evaluated meshes only
as it doesn't handle ID user-counts.
- BKE_mesh_copy_parameters is a general function for copying parameters
between meshes.
This namespace groups threading related functions/classes. This avoids
adding more threading related stuff to the blender namespace. Also it
makes naming a bit easier, e.g. the c++ version of BLI_task_isolate could
become blender::threading::isolate_task or something similar.
Differential Revision: https://developer.blender.org/D11624
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
While this preprocessing does take some time upfront,
it avoids longer lookup later on, especially as nodes get
more sockets.
It's probably possible to make this more efficient in some cases
but this is good enough for now.
This node is similar to the mask modifier, but it deletes the elements
of the geometry corresponding to the selection, which is retrieved as
a boolean attribute. The node currently supports both mesh and point
cloud data. For meshes, which elements are deleted depends on the
domain of the input selection attribute, just like how behavior depends
on the selection mode in mesh edit mode.
In the future this node will support curve data, and ideally volume
data in some way.
Differential Revision: https://developer.blender.org/D10748
`bvhtree_from_mesh_edges_create_tree` can actually leave the BVHTree
NULL (e.g. if no edges are present).
Now dont allocate `BVHTreeFromMesh` on the `SurfaceModifierData` at all
in case the tree would be NULL anyways.
Places like `get_effector_data` check for `SurfaceModifierData`-
>`BVHTreeFromMesh` and dont try to stuff like getting a closest point on
surface, which would crash as soon as BVHNodes would need to be accessed
(from the NULL BVHTree).
Maniphest Tasks: T88658
Differential Revision: https://developer.blender.org/D11443
2 sided faces aren't supported and will cause problems in many areas
of Blender's code.
Removing (implied) support for faces with fewer than 3 sides
means the total number of triangles is known ahead of time.
This simplifies adding support for multi-threading and partial updates
to an existing tessellation - as the face and loop indices can be used
to access the range of triangles associated with a face.
Also correct outdated comments.
Not entirely sure why this was not an issue for 16.9
but TBB includes the Windows.h header which by default
will define min and max macro's
These collide with the stl versions in <algorithm>
This patch requests Windows.h not to define the
problematic macro's, resolving the conflict.
