| Age | Commit message (Collapse) | Author |
|---|
|
This adds a Mesh To Volume Node T86838 based on the existing modifier.
The mesh to volume conversion is implemented in the geometry module,
and shared between the node and the modifier.
Currently the node outputs a grid with the name "density". This may
change in the future depending on the decisions made in T91668.
The original patch was by Kris (@Metricity), further implementation
by Geramy Loveless (@GeramyLoveless), then finished by Erik Abrahamsson
(@erik85).
Differential Revision: https://developer.blender.org/D10895
|
|
Avoid the conversion to and from the old type, which could
be a substantial improvement in somce cases.
|
|
- CustomDataType -> eCustomDataType
- CustomDataMask -> eCustomDataMask
- AttributeDomain -> eAttrDomain
- NamedAttributeUsage -> eNamedAttrUsage
|
|
Replace tot/amount & size with num, in keeping with T85728.
|
|
The large call stack can be slightly annoying, and it's possible that
invoking TBB in this case corresponds to some overhead like
e1309030603980c6b.
|
|
|
|
This commit moves declarations that depend on `FN_field.hh` out of
`BKE_geometry_set.hh` into `BKE_geometry_fields.hh`. This helps to
reduce the number of areas that need to depend on the functions module,
which recently came in in review of D11591.
In the future we may have a library of standard field inputs in order to
make composing algorithms easier, so it makes sense to have a header
that could contain them and some basic related utilities relating the
concepts of geometry and fields.
Reducing use of unnecessary headers may also reduce compilation time.
Differential Revision: https://developer.blender.org/D14517
|
|
Similar to 245722866d6977c8b, just another function I missed before.
|
|
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
|
|
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
|
|
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 commit moves the normal field input to `BKE_geometry_set.hh`
from the node file so that normals can be used as an implicit input to
other nodes.
Differential Revision: https://developer.blender.org/D13779
|
|
`GeometrySet::compute_boundbox_without_instances` may not initialize min
max in some cases such as meshes without vertices.
This can result in a Bounding Box with impossible dimensions
(min=FLT_MAX, max=-FLT_MAX).
So repeat the same solution seen in `BKE_object_boundbox_calc_from_mesh`
and set boundbox values to zero.
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D13664
|
|
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
|
|
In the `replace_mesh`/`replace_curve` etc. methods, the component
was retrieved with write access. Retrieving with write access will
duplicate the data if the component has another user. This means that
the replaced geometry data was often duplicated just to be deleted
a moment later.
I expect this would have a large impact in performance in some specific
situations when dealing with large geometry. In a scene with many small
meshes though, I didn't observe a significant difference.
This also makes replacing a geometry set's data with the same data
that's already in the set safe. It would be valid to assert for that
case instead, but this seems safer.
Differential Revision: https://developer.blender.org/D13530
|
|
I'm planning to make these functions slightly more complicated,
and it makes sense to return early when checking one of the parameters
for null anyway.
|
|
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
|
|
`GeometrySet` contains at most one component of each type.
Previously, a map was used to make sure that each component
type only exists once. The overhead of a map (especially with
inline storage) is rather large though. Since all component types
are known at compile time and the number of types is low,
a simple `std::array` works as well.
Some benefits of using `std::array` here:
* Looking up the component of a specific type is a bit faster.
* The size of `GeometrySet` becomes much smaller from 192 to 40 bytes.
* Debugging a `GeometrySet` in many tools becomes simpler because
one can easily see which components exists and which don't
|
|
The improves playback speed in my instance heavy scene from ~3.7 fps to ~3.9 fps.
|
|
Previously, every node had to create warnings for unsupported input
geometry manually. Now this is automated. Nodes just have to specify
the geometry types they support in the node declaration.
Differential Revision: https://developer.blender.org/D12899
|
|
Add a higher level check that can be used instead of checking whether
the attribute ID is anonymous and checking whether it has any strong
references.
|
|
The previous code did not take into account that they geometry
component may not be mutable because it is shared between
multiple geometry sets.
|
|
Avoiding creating empty components can be a hassle for code that
interacts with a geometry set. One easy way to do that was calling
the functions that retrieved mutable access to geometry data directly,
like get_mesh_for_write. This commit makes it so that sort of direct
function does not create an empty component if there is no data.
Another way to create an empty component was calling the replace_*
methods with a null pointer. It's more convenient to have a nice API
that handles those cases without creating an empty component.
It's still convenient that the regular get_component_for_write adds
the component if it doesn't exist, because that's often a nice way to
add data to the geometry set.
Differential Revision: https://developer.blender.org/D12862
|
|
This reduces the compile time, because fewer symbols have to be generated
in translation units using geometry sets.
|
|
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
|
|
|
|
Differential Revision: https://developer.blender.org/D12652
|
|
This adds a new `GeometrySet::modify_geometry_sets` method that can be
used to update each sub-geometry-set separately without making any
instances real.
Differential Revision: https://developer.blender.org/D12650
|
|
This adds a new Instance on Points node that is a replacement
for the old Point Instance node. Contrary to the old node,
it does not have a mode to instance objects or collections
directly. Instead, the node has to be used with an Object/
Collection Info to achieve the same effect.
Rotation and scale of the instances can be adjusted in the node
directly or can be controlled with a field to get some variation
between instances.
The node supports placing different instances on different points.
The user has control over which instance is placed on which point
using an Instance Index input. If that functionality is used, the
Instance Geometry has to contain multiple instances that can are
instanced separately.
Differential Revision: https://developer.blender.org/D12478
|
|
This adds three new methods:
* `InstancesComponent::foreach_reference_as_geometry(...)`
* `GeometrySet::attribute_foreach(...)`
* `GeometrySet::gather_attributes_for_propagation(...)`
The goal is that these iteration primitives can be used in places
where we use more specialized iterators currently.
Differential Revision: https://developer.blender.org/D12613
|
|
With this commit, curve objects support the geometry nodes modifier.
Curves objects now evaluate to `CurveEval` unless there was a previous
implicit conversion (tessellating modifiers, mesh modifiers, or the
settings in the curve "Geometry" panel). In the new code, curves are
only considered to be the wire edges-- any generated surface is a mesh
instead, stored in the evaluated geometry set.
The consolidation of concepts mentioned above allows remove a lot of
code that had to do with maintaining the `DispList` type temporarily
for modifiers and rendering. Instead, render engines see a separate
object for the mesh from the mesh geometry component, and when the
curve object evaluates to a curve, the `CurveEval` is always used for
drawing wire edges.
However, currently the `DispList` type is still maintained and used as
an intermediate step in implicit mesh conversion. In the future, more
uses of it could be changed to use `CurveEval` and `Mesh` instead.
This is mostly not changed behavior, it is just a formalization of
existing logic after recent fixes for 2.8 versions last year and two
years ago. Also, in the future more functionality can be converted
to nodes, removing cases of implicit conversions. For more discussion
on that topic, see T89676.
The `use_fill_deform` option is removed. It has not worked properly
since 2.62, and the choice for filling a curve before or after
deformation will work much better and be clearer with a node system.
Applying the geometry nodes modifier to generate a curve is not
implemented with this commit, so applying the modifier won't work
at all. This is a separate technical challenge, and should be solved
in a separate step.
Differential Revision: https://developer.blender.org/D11597
|
|
Previously, the Point Instance node in geometry nodes could only instance
existing objects or collections. The reason was that large parts of Blender
worked under the assumption that objects are the main unit of instancing.
Now we also want to instance geometry within an object, so a slightly larger
refactor was necessary.
This should not affect files that do not use the new kind of instances.
The main change is a redefinition of what "instanced data" is. Now, an
instances is a cow-object + object-data (the geometry). This can be nicely
seen in `struct DupliObject`. This allows the same object to generate
multiple geometries of different types which can be instanced individually.
A nice side effect of this refactor is that having multiple geometry components
is not a special case in the depsgraph object iterator anymore, because those
components are integrated with the `DupliObject` system.
Unfortunately, different systems that work with instances in Blender (e.g.
render engines and exporters) often work under the assumption that objects are
the main unit of instancing. So those have to be updated as well to be able to
handle the new instances. This patch updates Cycles, EEVEE and other viewport
engines. Exporters have not been updated yet. Some minimal (not master-ready)
changes to update the obj and alembic exporters can be found in P2336 and P2335.
Different file formats may want to handle these new instances in different ways.
For users, the only thing that changed is that the Point Instance node now
has a geometry mode.
This also fixes T88454.
Differential Revision: https://developer.blender.org/D11841
|
|
* 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 adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
|
|
This allows us to remove a callback from the modifier type info struct.
In the future the these modifiers might just be replaced by nodes
internally anyway, but in the meantime it's nice to unify the handling
of evaluated geometry a bit.
Differential Revision: https://developer.blender.org/D11080
|
|
Where possible, nodes in the "Geometry" category should support all
geometry component types. This adds support for volumes in the
recently added bounding box node, based on functions added in the
previous two commits.
Differential Revision: https://developer.blender.org/D10906
|
|
Previously, the spreadsheet editor could only show data of the original
and of the final evaluated object. Now it is possible to show the data
at some intermediate stages too.
For that the mode has to be set to "Node" in the spreadsheet editor.
Furthermore, the preview of a specific node has to be activated by
clicking the new icon in the header of geometry nodes.
The exact ui of this feature might be refined in upcoming commits.
It is already very useful for debugging node groups in it's current
state though.
Differential Revision: https://developer.blender.org/D10875
|
|
This removes a lot of unnecessary code that is generated by
the compiler automatically.
In very few cases, a defaulted destructor in a .cc file is
still necessary, because of forward declarations in the header.
I removed some defaulted virtual destructors, because they are not
necessary, when the parent class has a virtual destructor already.
Defaulted constructors are only necessary when there is another
constructor, but the class should still be default constructible.
Differential Revision: https://developer.blender.org/D10911
|
|
Now that object_dupli.cc is a C++ file, we don't have to have a specific
function to retrieve the instance data from the geometry set.
|
|
Previously this was only supported within nested node groups.
Now it is also supported for the root node group that is referenced
by the modifier.
|
|
|
|
This allows us to use it in rna for the spreadsheet editor.
|
|
This was meant to be part of rB9ce950daabbf, but the change dropped from
the set at some point in the process of updating and committing.
Sorry for the noise.
|
|
Previously, functions would have to ask for every geometry type explicitely.
Using a vector is return type is fine. In practice this will probably never
allocate because of the small buffer optimization in vector.
|
|
In an upcoming commit I'll also move the make-instances-real functionality
to this file. This code is not essential to working with geometry sets in general,
so it makes sense to move it to a separate header.
|
|
|
|
This commit makes the geometry output of the collection info usable.
The output is the geometry of a collection instance, but this commit
adds a utility to convert the instances to real geometry, used in the
background whenever it is needed, like copy on write.
The recursive nature of the "realize instances" code is essential,
because collection instances in the `InstancesComponent`, might have no
geometry sets of their own containing even more collection instances,
which might then contain object instances, etc.
Another consideration is that currently, every single instance contains
a reference to its data. This is inefficient since most of the time
there are many locations and only a few sets of unique data. So this
commit adds a `GeometryInstanceGroup` to support this future optimization.
The API for instances returns a vector of `GeometryInstanceGroup`.
This may be less efficient when there are many instances, but it makes
more complicated operations like point distribution that need to iterate
over input geometry multiple times much simpler.
Any code that needs to change data, like most of the attribute nodes,
can simply call `geometry_set_realize_instances(geometry_set)`,
which will move any geometry in the `InstancesComponent` to new "real"
geometry components.
Many nodes can support read-only access to instances in order to avoid
making them real, this will be addressed where needed in the near future.
Instances from the existing "dupli" system are not supported yet.
Differential Revision: https://developer.blender.org/D10327
|
|
|
|
Ids stored in the `id` attribute cannot be assumed to be unique. While they
might be unique in some cases, this is not something that can be guaranteed
in general. For some use cases (e.g. generating "stable randomness" on points)
uniqueness is not important. To support features like motion blur, unique ids
are important though.
This patch implements a simple algorithm that turns non-unique ids into
unique ones. It might fail to do so under very unlikely circumstances, in
which it returns non-unique ids instead of possibly going into an endless
loop.
Here are some requirements I set for the algorithm:
* Ids that are unique already, must not be changed.
* The same input should generate the same output.
* Handle cases when all ids are different and when all ids are the same
equally well (in expected linear time).
* Small changes in the input id array should ideally only have a small
impact on the output id array.
The reported bug happened because cycles found multiple objects with
the same id and thought that it was a single object that moved on every
check.
Differential Revision: https://developer.blender.org/D10402
|
