This refactors the geometry nodes evaluation system. No changes for the
user are expected. At a high level the goals are:
* Support using geometry nodes outside of the geometry nodes modifier.
* Support using the evaluator infrastructure for other purposes like field evaluation.
* Support more nodes, especially when many of them are disabled behind switch nodes.
* Support doing preprocessing on node groups.
For more details see T98492.
There are fairly detailed comments in the code, but here is a high level overview
for how it works now:
* There is a new "lazy-function" system. It is similar in spirit to the multi-function
system but with different goals. Instead of optimizing throughput for highly
parallelizable work, this system is designed to compute only the data that is actually
necessary. What data is necessary can be determined dynamically during evaluation.
Many lazy-functions can be composed in a graph to form a new lazy-function, which can
again be used in a graph etc.
* Each geometry node group is converted into a lazy-function graph prior to evaluation.
To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are
no longer inlined into their parents.
Next steps for the evaluation system is to reduce the use of threads in some situations
to avoid overhead. Many small node groups don't benefit from multi-threading at all.
This is much easier to do now because not everything has to be inlined in one huge
node tree anymore.
Differential Revision: https://developer.blender.org/D15914
After becb1530b1 the new curves object type isn't hidden
behind an experimental flag anymore, and other areas depend on this,
so disabling curves at compile time doesn't make sense anymore.
The modifier is supposed to create a Curves data block soon, which
helps with the transition to the new Curves object in drawing code.
Utilities for the new Curves object are mostly in C++.
This moves `MOD_meshsequencecache.c` to C++ and fixes compile warnings
introduced from the change. This uses C++ style casts, as well as
`nullptr` instead of `NULL`.
This will allow to output `GeometrySets` from the modifier, which is C++.
Differential Revision: https://developer.blender.org/D13662
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3db we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
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
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
Previously, macros were ifdefed using the cmake option `WITH_INTERNATIONAL`
However, the is unnecessary as withen the functions themselves have checks for building without internationalization.
This also means that many `add_definitions(-DWITH_INTERNATIONAL)` are also unnecessary.
Reviewed By: mont29, LazyDodo
Differential Revision: https://developer.blender.org/D13929
Previously it was only part of experimental features in beta, however now
renderers can render point clouds generated by geometry nodes. Adding or
converting a point cloud object directly is still hidden by default, since
there is no good way to edit it.
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
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 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
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.
Before, any usage of tbb wrappers used in modifier code would
just fall back to the non-threaded non-tbb version.
We ran into this issue a couple of times in patches.
This is a first step towards T87620.
It should not have any functional changes.
Goals of this refactor:
* Move the evaluator out of `MOD_nodes.cc`. That makes it easier to
improve it in isolation.
* Extract core input/out parameter management out of `GeoNodeExecParams`.
Managing this is the responsibility of the evaluator. This separation of
concerns will be useful once we have lazy evaluation of certain inputs/outputs.
Differential Revision: https://developer.blender.org/D11085
The main goal here is to remove the need for a C API to the code in
`mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c`
to C++ and making the necessary changes for it to compile. On top of
that there are some other slight simplifications possible to the
direct mesh boolean code: it doesn't need to copy the material
remaps, and the modifier code can use some other C++ types directly.
The geometry-nodes features no longer depend on the point cloud object.
Therefore the point cloud object, although important in the future, can
be postponed until we have render and edit mode fully working.
This reverts commits:
* ea74ed5a7a.
* dc614c68ef.
This is the initial merge from the geometry-nodes branch.
Nodes:
* Attribute Math
* Boolean
* Edge Split
* Float Compare
* Object Info
* Point Distribute
* Point Instance
* Random Attribute
* Random Float
* Subdivision Surface
* Transform
* Triangulate
It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier.
Notes on the Generic attribute access API
The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).
Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.
It includes commits from:
* Dalai Felinto
* Hans Goudey
* Jacques Lucke
* Léo Depoix
Those two features are not directly related and one might be activated
in master earlier than the other.
WITH_PARTICLE_NODES was removed, because we continue the project
under the name "Geometry Nodes".
This modifier is the opposite of the recently added Mesh to Volume modifier.
It converts the "surface" of a volume into a mesh. The "surface" is defined
by a threshold value. All voxels with a density higher than the threshold
are considered to be inside the volume, while all others will be outside.
By default, the resolution of the generated mesh depends on the voxel
size of the volume grid. The resolution can be customized. It should be
noted that a lower resolution might not make this modifier faster. This
is because we have to downsample the openvdb grid, which isn't a cheap
operation.
Converting a mesh to a volume and then back to a mesh is possible,
but it does require two separate mesh objects for now.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D9141
This modifier uses a 3D texture to displace a volume.
For now, this can only use the previously existing texture system,
because we do not have a better alternative yet. Still, the results
can be quite good and interesting. See D9075 for some examples.
Reviewers: brecht, simonthommes
Differential Revision: https://developer.blender.org/D9075
As noted in T80164, there are quite a few area of Blender where the
"Reset to Default Value" operator in button context menus doesn't work.
Modifiers are one of them, because the DNA defaults system was never
set up for them.
Additionally, this should make modifier versioning easier. Whenever a
new field is added it should be automatically initialized to the
default value.
I had to make some ordering changes in the following modifiers to work
around an error with `-Wsign-conversion` in the macros:
- Solidify Modifier
- Corrective Smooth Modifier
- Screw Modifier
Some modifiers are special cases and are skipped in this commit:
- Data Transfer Modifier
- Cloth Modifier
- Fluid Modifier
- Softbody Modifier
Differential Revision: https://developer.blender.org/D8747
This modifier can only be added to Volume objects. It takes a mesh
as input and generates a "density" grid near the surface or in
the enclosed volume.
Ref T73201.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D9032
This reduces the number of places that have to be modified
when a new modifier is added.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D9000
The animated objects was not updated for each internal substep for the rigidbody sim.
This would lead to unstable simulations or very annoying clipping artifacts.
Updated the code to use explicit substeps and tie it to the scene frame rate.
Fix T47402: Properly updating the animated objects fixes the reported issue.
Reviewed By: Brecht, Jacques
Differential Revision: http://developer.blender.org/D8762
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
Some of the files were (indirectly) using dna_type_offsets.h without
adding dependency from bf_dna (which is needed to ensure the file is
generated prior to library compilation).
This patch implements the list panel system D7490 for modifiers.
It also moves modifier drawing to a callback in ModifierTypeInfo
in line with the extensible architecture refactoring goal T75724.
This adds a PanelRegister callback and utilities for registering
panels and subpanels. It also adds the callbacks for expansion saving
and drag and drop reordering described in D7490.
These utilities, callbacks, and other common UI elements shared
between modifiers live in MOD_ui_common.c.
Because modifier buttons are now in panels, we can make use of
subpanels for organization. The UI layouts also use the single
column layout style consistently used elsewhere in Blender.
Additionally, the mode-setting buttons are aligned and ordered
consistently with the outliner.
However, the large number of UI changes in this patch may mean
that additional polishing is required in master.
Thanks to William Reynish (@billreynish) who did a fair amount of the
layout work and to Julian Eisel (@Severin) for consistent help.
Differential Revision: https://developer.blender.org/D7498
For now the "Simulation" modifier only exists for point cloud objects, because
we need this for the particle system. Right now, the modifier is doing nothing.
There is a new `DEG_add_simulation_relation` function that is used
by the modifier to make sure that the simulation is evaluated before
the modifier is executed.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D7549
This moves the `alembic`, `avi`, `collada`, and `usd` modules into a common
`io` directory.
This also cleans up some `#include "../../{somedir}/{somefile}.h"` by
adding `../../io/{somedir}` to `CMakeLists.txt` and then just using
`#include "{somefile}.h"`.
No functional changes.
The functionality of the mask modifier remains unchanged.
This patch updates the mask modifier so that it uses C++.
The manual memory management has been replaced with proper containers.
The large `applyModifier` function has been splitup into multiple smaller functions.
A large speedup is achieved by using simple arrays instead of hash tables in multiple places.
In my performance test file the playback speed increased from 1.1 to 5.1 fps on my laptop.
Reviewers: campbellbarton, brecht
Differential Revision: https://developer.blender.org/D6779
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
Part of T70240
This is the initial implementation of Weld Modifier.
New features will be added later.
ToDo:
- Seams: restrict welding to vertices along boundary edges.
- Edge Collapse: collapse edges below the length threshold.
- New icon.
- Some customdata are not being correctly interpolated.
Differential Revision: https://developer.blender.org/D6383
