| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These functions provided little benefit compared to simply setting
the function pointers directly.
|
|
Currently there are both "EDGERENDER" and "EDGEDRAW" flags, which are
almost always used together. Both are runtime data and not exposed to
RNA, used to skip drawing some edges after the subdivision surface
modifier. The render flag is a relic of the Blender internal renderer.
This commit removes the render flag and replaces its uses with the
draw flag.
|
|
|
|
Attribute copying often uses identical logic for copying selected
elements or copying with an index map. Instead of reimplementing
this in each file, use the common implementation in the array_utils
namespace. This makes the commonality more obvious, gives improved
performance (this implementation is multithreaded), reduces binary
size (I observed a 173KB reduction), and probably reduces compile time.
|
|
String attributes are intentionally not fully supported in geometry nodes
yet because more design work is necessary to decide how they should behave.
For now just disable handling string attributes to avoid crashes.
|
|
|
|
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
|
|
|
|
Previously, all implicit inputs where stored in a centralized place.
Now the information which nodes have which implicit inputs is
stored in the nodes directly.
|
|
https://wiki.blender.org/wiki/Style_Guide/C_Cpp#C.2B.2B_Type_Cast
This was discussed in https://devtalk.blender.org/t/rfc-style-guide-for-type-casts-in-c-code/25907.
|
|
refactor-mesh-position-generic
|
|
Using the attribute name semantics from T97452, this patch moves the
selection status of mesh elements from the `SELECT` of vertices, and
edges, and the `ME_FACE_SEL` of faces to generic boolean attribute
Storing this data as generic attributes can significantly simplify and
improve code, as described in T95965.
The attributes are called `.select_vert`, `.select_edge`, and
`.select_poly`. The `.` prefix means they are "UI attributes",so they
still contain original data edited by users, but they aren't meant to
be accessed procedurally by the user in arbitrary situations. They are
also be hidden in the spreadsheet and the attribute list.
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when selection is used. When the flags are removed
completely, requirements will decrease.
Further notes:
* The `MVert` flag is empty at runtime now, so it can be ignored.
* `BMesh` is unchanged, otherwise the change would be much larger.
* Many tests have slightly different results, since the selection
attribute uses more generic propagation. Previously you couldn't
really rely on edit mode selections being propagated procedurally.
Now it mostly works as expected.
Similar to 2480b55f216c
Ref T95965
Differential Revision: https://developer.blender.org/D15795
|
|
|
|
This is very similar to D14077. There are two differences though.
First is that vertex creases are already stored in a separate layer,
and second is that we can now completely remove use of `Mesh.cd_flag`,
since that information is now inherent to whether the layers exist.
There are two functional differences here:
* Operators are used to add and remove layers instead of a property.
* The "crease" attribute can be created and removed by geometry nodes.
The second change should make various geometry nodes slightly faster,
since the "crease" attribute was always processed before. Creases are
now interpolated generically in the CustomData API too, which should
help maintain the values across edits better.
Meshes get an `edge_creases` RNA property like the existing vertex
property, to provide more efficient access to the data in Cycles.
One test failure is expected, where different rounding between float
the old char storage means that 5 additional points are scattered in
a geometry nodes test.
Differential Revision: https://developer.blender.org/D15927
|
|
refactor-mesh-position-generic
|
|
|
|
The extrude node must set the original indices for new faces to "None"
in edge mode as well. Same for new edges in vertex mode.
|
|
|
|
|
|
|
|
|
|
When resizing mesh and curves attribute storage, avoid initializing the
new memory for basic types. Also, avoid skipping "no free" layers; all
layers should be reallocated to the new size since they may be accessed.
The semantics introduced in 25237d2625078c6d1 are essential for this
change, because otherwise we don't have a way to construct non-trivial
types in the new memory.
In a basic test of the extrude node, I observed a performance
improvement of about 30%, from 55ms to 42ms.
Differential Revision: https://developer.blender.org/D15818
|
|
|
|
Now this is done by `Mesh::verts_for_write()`
|
|
Replace `mesh_attributes`, `mesh_attributes_for_write` and the point
cloud versions with methods on the `Mesh` and `PointCloud` types.
This makes them friendlier to use and improves readability.
Differential Revision: https://developer.blender.org/D15907
|
|
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d33eeb50. This aligns better with
existing naming where the shorter names are much more common.
|
|
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
|
|
Using the same `GeometryComponentFieldContext` for all situations,
even when only one geometry type is supported is misleading, and mixes
too many different abstraction levels into code that could be simpler.
With the attribute API moved out of geometry components recently,
the "component" system is just getting in the way here.
This commit adds specific field contexts for geometry types: meshes,
curves, point clouds, and instances. There are also separate field input
helper classes, to help reduce boilerplate for fields that only support
specific geometry types.
Another benefit of this change is that it separates geometry components
from fields, which makes it easier to see the purpose of the two concepts,
and how they relate.
Because we want to be able to evaluate a field on just `CurvesGeometry`
rather than the full `Curves` data-block, the generic "geometry context"
had to be changed to avoid using `GeometryComponent`, since there is
no corresponding geometry component type. The resulting void pointer
is ugly, but only turns up in three places in practice. When Apple clang
supports `std::variant`, that could be used instead.
Differential Revision: https://developer.blender.org/D15519
|
|
Fixes the typo in the struct `DefaultPropatationMixerStruct`.
|
|
Remove the boilerplate of using a local geometry component just to use
the attribute API that was necessary before b876ce2a4a4638142439.
|
|
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
|
|
This is clearer about what is actually happening (VArray is small
enough to be a by-value type and is constructed on demand, while
only the generic virtual array is stored).
|
|
|
|
|
|
The original index layer was not initialized properly.
Supporting original indices properly for this node is
doable, but for now it is better to simply initialize them
to the "none" value to fix the crash.
Differential Revision: https://developer.blender.org/D15105
|
|
- CustomDataType -> eCustomDataType
- CustomDataMask -> eCustomDataMask
- AttributeDomain -> eAttrDomain
- NamedAttributeUsage -> eNamedAttrUsage
|
|
Also add missing task-ID reference & remove colon after \note as it
doesn't render properly in doxygen.
|
|
Goals:
* Better high level control over where devirtualization occurs. There is always
a trade-off between performance and compile-time/binary-size.
* Simplify using array devirtualization.
* Better performance for cases where devirtualization wasn't used before.
Many geometry nodes accept fields as inputs. Internally, that means that the
execution functions have to accept so called "virtual arrays" as inputs. Those
can be e.g. actual arrays, just single values, or lazily computed arrays.
Due to these different possible virtual arrays implementations, access to
individual elements is slower than it would be if everything was just a normal
array (access does through a virtual function call). For more complex execution
functions, this overhead does not matter, but for small functions (like a simple
addition) it very much does. The virtual function call also prevents the compiler
from doing some optimizations (e.g. loop unrolling and inserting simd instructions).
The solution is to "devirtualize" the virtual arrays for small functions where the
overhead is measurable. Essentially, the function is generated many times with
different array types as input. Then there is a run-time dispatch that calls the
best implementation. We have been doing devirtualization in e.g. math nodes
for a long time already. This patch just generalizes the concept and makes it
easier to control. It also makes it easier to investigate the different trade-offs
when it comes to devirtualization.
Nodes that we've optimized using devirtualization before didn't get a speedup.
However, a couple of nodes are using devirtualization now, that didn't before.
Those got a 2-4x speedup in common cases.
* Map Range
* Random Value
* Switch
* Combine XYZ
Differential Revision: https://developer.blender.org/D14628
|
|
|
|
Extusion with a negative offset is possible and expected.
|
|
|
|
Currently, when normals are calculated for a const mesh, a custom data
layer might be added if it doesn't already exist. Adding a custom data
layer to a mesh is not thread-safe, so this can be a problem in some
situations.
This commit moves derived mesh normals for polygons and
vertices out of `CustomData` to `Mesh_Runtime`. Most of the
hard work for this was already done by rBcfa53e0fbeed7178.
Some changes to logic elsewhere are necessary/helpful:
- No need to call both `BKE_mesh_runtime_clear_cache` and
`BKE_mesh_normals_tag_dirty`, since the former also does the latter.
- Cleanup/simplify mesh conversion and copying since normals are
handled with other runtime data.
Storing these normals like other runtime data clarifies their status
as derived data, meaning custom data moves more towards storing
original/editable data. This means normals won't automatically benefit
from the planned copy-on-write refactor (T95845), so it will have to be
added manually like for the other runtime data.
Differential Revision: https://developer.blender.org/D14154
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
This patch introduces an extrude node with three modes. The vertex mode
is quite simple, and just attaches new edges to the selected vertices.
The edge mode attaches new faces to the selected edges. The faces mode
extrudes patches of selected faces, or each selected face individually,
depending on the "Individual" boolean input.
The default value of the "Offset" input is the mesh's normals, which
can be scaled with the "Offset Scale" input.
**Attribute Propagation**
Attributes are transferred to the new elements with specific rules.
Attributes will never change domains for interpolations. Generally
boolean attributes are propagated with "or", meaning any connected
"true" value that is mixed in for other types will cause the new value
to be "true" as well. The `"id"` attribute does not have any special
handling currently.
Vertex Mode
- Vertex: Copied values of selected vertices.
- Edge: Averaged values of selected edges. For booleans, edges are
selected if any connected edges are selected.
Edge Mode
- Vertex: Copied values of extruded vertices.
- Connecting edges (vertical): Average values of connected extruded
edges. For booleans, the edges are selected if any connected
extruded edges are selected.
- Duplicate edges: Copied values of selected edges.
- Face: Averaged values of all faces connected to the selected edge.
For booleans, faces are selected if any connected original faces
are selected.
- Corner: Averaged values of corresponding corners in all faces
connected to selected edges. For booleans, corners are selected
if one of those corners are selected.
Face Mode
- Vertex: Copied values of extruded vertices.
- Connecting edges (vertical): Average values of connected selected
edges, not including the edges "on top" of extruded regions.
For booleans, edges are selected when any connected extruded edges
were selected.
- Duplicate edges: Copied values of extruded edges.
- Face: Copied values of the corresponding selected faces.
- Corner: Copied values of corresponding corners in selected faces.
Individual Face Mode
- Vertex: Copied values of extruded vertices.
- Connecting edges (vertical): Average values of the two neighboring
edges on each extruded face. For booleans, edges are selected
when at least one neighbor on the extruded face was selected.
- Duplicate edges: Copied values of extruded edges.
- Face: Copied values of the corresponding selected faces.
- Corner: Copied values of corresponding corners in selected faces.
**Differences from edit mode**
In face mode (non-individual), the behavior can be different than the
extrude tools in edit mode-- this node doesn't handle keeping the back-
faces around in the cases that the edit mode tools do. The planned
"Solidify" node will handle that use case instead. Keeping this node
simpler and faster is preferable at this point, especially because that
sort of "smart" behavior is not that predictable and makes less sense
in a procedural context.
In the future, an "Even Offset" option could be added to this node
hopefully fairly simply. For now it is left out in order to keep
the patch simpler.
**Implementation**
For the implementation, the `Mesh` data structure is used directly
rather than converting to `BMesh` and back like D12224. This optimizes
for large extrusion operations rather than many sequential extrusions.
While this is potentially more verbose, it has some important benefits:
First, there is no conversion to and from `BMesh`. The code only has
to fill arrays and it can do that all at once, making each component of
the algorithm much easier to optimize. It also makes the attribute
interpolation more explicit, and likely faster. Only limited topology
maps must be created in most cases.
While there are some necessary loops and allocations with the size of
the entire mesh, I tried to keep everything I could on the order of the
size of the selection rather than the size of the mesh. In that respect,
the individual faces mode is the best, since there is no topology
information necessary, and the amount of work just depends on the size
of the selection.
Modifying an existing mesh instead of generating a new one was a bit
of a toss-up, but has a few potential benefits:
- Avoids manually copying over attribute data for original elements.
- Avoids some overhead of creating a new mesh.
- Can potentially take advantage of future ammortized mesh growth.
This could be changed easily if it turns out to be the wrong choice.
Differential Revision: https://developer.blender.org/D13709
|
