| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Previously, curves sculpt tools only worked on original data. This was
very limiting, because one could effectively only sculpt the curves when
all procedural effects were turned off. This patch adds support for curves
sculpting while looking the result of procedural effects (like deformation
based on the surface mesh). This functionality is also known as "crazy space"
support in Blender.
For more details see D15407.
Differential Revision: https://developer.blender.org/D15407
|
|
Testing if components or virtual arrays are null in the same line they
are retrieved can make this boilerplate code a bit easier to read.
|
|
Similar to e9f82d3dc7eebadcc52, but for point clouds instead.
Differential Revision: https://developer.blender.org/D15487
|
|
Fundamental issue is that the attribute api returns none, because
the custom data api returns null for a layer when the size of 0.
This should be improved separately.
|
|
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
|
|
Mistake in df8d96ab66adf46603b36
|
|
Replace tot/amount & size with num, in keeping with T85728.
|
|
Addressing the TODO from the comment isn't a priority at the moment,
and should be solved a bit more generally anyway.
|
|
This is mostly a cleanup to avoid hardcoding the eager calculation of
normals it isn't necessary, by reducing calls to `BKE_mesh_calc_normals`
and by removing calls to `BKE_mesh_normals_tag_dirty` when the mesh
is newly created and already has dirty normals anyway. This reduces
boilerplate code and makes the "dirty by default" state more clear.
Any regressions from this commit should be easy to fix, though the
lazy calculation is solid enough that none are expected.
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D14443
|
|
|
|
A follow-up to e253f9f66d6f. Follow the policy from T85728
completely (using "num" as a prefix) and rename another function.
|
|
This uses the evaluated positions calculations from 8538c69921662164677.
|
|
Ref T95355
|
|
This commit changes `CurveComponent` to store the new curve
type by adding conversions to and from `CurveEval` in most nodes.
This will temporarily make performance of curves in geometry nodes
much worse, but as functionality is implemented for the new type
and it is used in more places, performance will become better than
before.
We still use `CurveEval` for drawing curves, because the new `Curves`
data-block has no evaluated points yet. So the `Curve` ID is still
generated for rendering in the same way as before. It's also still
needed for drawing curve object edit mode overlays.
The old curve component isn't removed yet, because it is still used
to implement the conversions to and from `CurveEval`.
A few more attributes are added to make this possible:
- `nurbs_weight`: The weight for each control point on NURBS curves.
- `nurbs_order`: The order of the NURBS curve
- `knots_mode`: Necessary for conversion, not defined yet.
- `handle_type_{left/right}`: An 8 bit integer attribute.
Differential Revision: https://developer.blender.org/D14145
|
|
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 flag is only used a few small cases, so instead
of setting the flag for every node only set the
required flag for the nodes that require it.
Mostly the flag is used to set `ntype.flag = NODE_PREVIEW`
For nodes that should have previews by default which
is only some compositor nodes and some texture nodes.
The frame node also sets the `NODE_BACKGROUND` flag.
All other nodes were setting a flag of 0 which has no purpose.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D13699
|
|
Differential Revision: https://developer.blender.org/D13384
|
|
With this commit, we no longer use the prefixes for every node type
function like `geo_node_translate_instances_`. They just added more
places to change when adding a new node, for no real benefit.
Differential Revision: https://developer.blender.org/D13337
|
|
This puts all static functions in geometry node files into a new
namespace. This allows using unity build which can improve
compile times significantly (P2578).
* The name space name is derived from the file name. That makes
it possible to write some tooling that checks the names later on.
The file name extension (`cc`) is added to the namespace name as
well. This also possibly simplifies tooling but also makes it more
obvious that this namespace is specific to a file.
* In the register function of every node, I added a namespace alias
`namespace file_ns = blender::nodes::node_geo_*_cc;`. This avoids
some duplication of the file name and may also simplify tooling,
because this line is easy to detect. The name `file_ns` stands for "file
namespace" and also indicates that this namespace corresponds to
the current file. In the beginning I used `node_ns` but `file_ns` is more
generic which may make it more suitable when we want to use unity
builds outside of the nodes modules in the future.
* Some node files contain code that is actually shared between
different nodes. For now I left that code in the `blender::nodes`
namespace and moved it to the top of the file (couldn't move it to
the bottom in all cases, so I just moved it to the top everywhere).
As a separate cleanup step, this shared code should actually be
moved to a separate file.
Differential Revision: https://developer.blender.org/D13330
|
|
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
|
|
As part of the refactor to the node declaration builders, we had hoped
to add a regular expression specifically for these socket names, but
recent discussions have revealed that using the translation marker
macros is the preferred solution.
If the names and descriptions were exposed to RNA, these would not
be necessary. However, that may be quite complicated, since sockets
are all instances of the same RNA types.
Differential Revision: https://developer.blender.org/D13033
|
|
As described in T91672, often it can be much more efficient to run each
node only on the unique geometry of the instances, rather than realizing
all instances and potentially processing redundant data. Sometimes the
performance difference can be completely smooth vs. completely unusable.
Geometry nodes used to hide that choice from users by always realizing
instances, but recently we have decided to expose it. So this commit
makes nodes run once per unique reference in the entire tree of nested
instances in their input geometries, continuing the work started in
rB0559971ab377 and rBf94164d89629f0d2. For the old behavior, a realize
instances node can be added before the nodes, which is done in the
versioning code.
Differential Revision: https://developer.blender.org/D12656
|
|
The new API introduced in rB1e69a25043120c provides a shorted, more
flexibly way to declare node socket inputs and outputs. This commit
updates all geometry nodes to use the `NodeSocketBuilder` API, except
the four nodes that need `SOCK_HIDE_VALUE` or `SOCK_MULTI_INPUT`.
Differential Revisions: D12377, D12376, D12374, D12373, D12372
|
|
These were added in other places but were overlooked here.
|
|
Because mesh vertex and face normals are just derived data, they can
be calculated lazily instead of eagerly. Often normal calculation is
a relatively expensive task, and the calculation is often redundant
if the mesh is deformed afterwards anyway.
Instead, normals should be calculated only when they are needed. This
commit moves in that direction by adding a new function to tag a mesh's
normals dirty and replacing normal calculation with it in some places.
Differential Revision: https://developer.blender.org/D12107
|
|
This shows the text as part of the assertion message.
|
|
This commit adds a node to output the convex hull of any input geometry
as a mesh, which is an enclosing geometry around a set of points.
All geometry types are supported, besides volumes.
The code supports operating on instances to avoid copying all input
geometry before the operation. The implementation uses the same backend
as the operation in edit mode, but uses Mesh directly instead of BMesh.
Attribute transfer is not supported currently, but would be a point of
improvement for the future if it can work in a predictable way on
different geometry input types.
Differential Revision: https://developer.blender.org/D10925
|
