Eager bounds calculation for cylindrical and spherical primitive nodes,
implemented in constant time rather than as a loop over all positions.
Takes into account the segments count of the circle from which they
are constructed. Solution of the task #105551.
Pull Request: blender/blender#105743
Geometry Nodes: SDF Volume nodes milestone 1
Adds initial support for SDF volume creation and manipulation.
`SDF volume` is Blender's name of an OpenVDB grid of type Level Set.
See the discussion about naming in #91668.
The new nodes are:
- Mesh to SDF Volume: Converts a mesh to an SDF Volume
- Points to SDF Volume: Converts points to an SDF Volume
- Mean Filter SDF Volume: Applies a Mean Filter to an SDF
- Offset SDF Volume: Applies an offset to an SDF
- SDF Volume Sphere: Creates an SDF Volume in the shape of a sphere
For now an experimental option `New Volume Nodes` needs to be
enabled in Blender preferences for the nodes to be visible.
See the current work plan for Volume Nodes in #103248.
Pull Request: blender/blender#105090
Straightforward port. I took the oportunity to remove some C vector
functions (ex: copy_v2_v2).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
Straightforward port. I took the oportunity to remove some C vector
functions (ex: `copy_v2_v2`).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
Previously, the lifetimes of anonymous attributes were determined by
reference counts which were non-deterministic when multiple threads
are used. Now the lifetimes of anonymous attributes are handled
more explicitly and deterministically. This is a prerequisite for any kind
of caching, because caching the output of nodes that do things
non-deterministically and have "invisible inputs" (reference counts)
doesn't really work.
For more details for how deterministic lifetimes are achieved, see D16858.
No functional changes are expected. Small performance changes are expected
as well (within few percent, anything larger regressions should be reported as
bugs).
Differential Revision: https://developer.blender.org/D16858
This is essentially a left-over from the initial transition to fields where this was
forgotten. The mesh primitive nodes used to create a named uv map attribute
with a hard-coded name. The standard way to deal with that in geometry nodes
now is to output the attribute as a socket instead. The user can then decide
to store it as a named attribute or not.
The benefits of not always storing the named attribute in the node are:
* Improved performance and lower memory usage when the uv map is not
used.
* It's more obvious that there actually is a uv map.
* The hard-coded name was inconsistent.
The versioning code inserts a new Store Named Attribute node that
stores the uv map immediatly. In many cases, users can probably just
remove this node without affecting their final result, but we can't
detect that.
There is one behavior change which is that the stored uv map will be
a 3d vector instead of a 2d vector which is what the nodes originally created.
We could store the uv map as 2d vector inthe Store Named Attribute node,
but that has the problem that older Blender versions don't support this
and would crash immediately. Users can just change this to 2d vector
manually if they don't care about forward compatibility.
There is a plan to support 2d vectors more natively in geometry nodes: T92765.
This change breaks forward compatibility in the case when the uv map
was used.
Differential Revision: https://developer.blender.org/D16637
The main goal here is to move towards more self contained node
definitions. Previously, one would have to change `blenkernel` to
add a new node which is not necessary anymore. There is no need
for all these register functions to "leak out" of the nodes module.
Differential Revision: https://developer.blender.org/D16612
This patch contains an initial set of nodes to access basic
mesh topology information, as explored in T100020.
The nodes allow six direct topology mappings for meshes:
- **Corner -> Face** The face a corner is in, the index in the face
- **Vertex -> Edge** Choose an edge attached to the vertex
- **Vertex -> Corner** Choose a corner attached to the vertex
- **Corner -> Edge** The next and previous edge at each face corner
- **Corner -> Vertex** The vertex associated with a corner
- **Corner -> Corner** Offset a corner index within a face
And two new topology mappings for curves:
- **Curve -> Points** Choose a point within a curve
- **Point -> Curve** The curve a point is in, the index in the curve
The idea is that some of the 16 possible mesh mappings are more
important, and that this is a useful set of nodes to start exploring
this area. For mappings with an arbitrary number of connections, we
must sort them and use an index to choose a single element, because
geometry nodes does not support list fields. Note that the sort
index has repeating behavior as it goes over the "Total" number of
connections, and negative sort indices choose from the end.
Currently which of the "start" elements is used is determined by the
field context, so the "Field at Index" and "Interpolate Domain" nodes
will be quite important. Also, currently the "Sort Index" inputs are
clamped to the number of connections.
One important feature that isn't implemented here is using the winding
order for the output elements. This can be a separate mode for some
of these nodes. It will be optional because of the performance impact.
There are several todos for separate commits after this:
- Rename "Control Point Neighbors" to be consistent with this naming
- Version away the "Vertex Neighbors" node which is fully redundant now
- Implement a special case for when no weights are used for performance
- De-duplicating some of the sorting logic between the nodes
- Improve performance and memory use of topology mappings
- Look into caching some of the mappings on meshes
Differential Revision: https://developer.blender.org/D16029
This patch replaces the existing transfer attribute node with three
nodes, "Sample Nearest Surface", "Sample Index", and "Sample Nearest".
This follows the design in T100010, allowing for new nodes like UV
sampling in the future. There is versioning so the new nodes replace
the old ones and are relinked as necessary.
The "Sample Nearest Surface" node is meant for the more complex
sampling algorithms that only work on meshes and interpolate
values inside of faces.
The new "Sample Index" just retrieves attributes from a geometry at
specific indices. It doesn't have implicit behavior like the old
transfer mode, which should make it more predictable. In order to not
change the behavior from existing files, the node has a has a "Clamp",
which is off by default for consistency with the "Field at Index" node.
The "Sample Nearest" node returns the index of the nearest element
on a geometry. It can be combined with the "Sample Index" node for
the same functionality as the old transfer node. This node can support
curves in the future.
Backwards compatibility is handled by versioning, but old versions can
not understand these nodes. The warning from 680fa8a523 should make
this explicit in 3.3 and earlier.
Differential Revision: https://developer.blender.org/D15909
The purpose of `NodeTreeRef` was to speed up various queries on a read-only
`bNodeTree`. Not that we have runtime data in nodes and sockets, we can also
store the result of some queries there. This has some benefits:
* No need for a read-only separate node tree data structure which increased
complexity.
* Makes it easier to reuse cached queries in more parts of Blender that can
benefit from it.
A downside is that we loose some type safety that we got by having different
types for input and output sockets, as well as internal and non-internal links.
This patch also refactors `DerivedNodeTree` so that it does not use
`NodeTreeRef` anymore, but uses `bNodeTree` directly instead.
To provide a convenient API (that is also close to what `NodeTreeRef` has), a
new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink`
now have C++ methods declared in `DNA_node_types.h` which are implemented in
`BKE_node_runtime.hh`. To make this work, `makesdna` now skips c++ sections when
parsing dna header files.
No user visible changes are expected.
Differential Revision: https://developer.blender.org/D15491
OpenVDB crashes when the determinant of the grid transformation is
too small. The solution is too detect when the determinant is too small
and to replace the grid with an empty one. If possible the translation
and rotation of the grid remains unchanged.
Differential Revision: https://developer.blender.org/D15806
The separate geometry and delete geometry nodes often invert the
selection so that deleting elements from a geometry can be implemented
as copying the opposite selection of elements. This should make the two
nodes faster in some cases, since the generic versions of selection
creation functions (i.e. from d3a1e9cbb9) are used instead
of the single threaded code that was used for this node.
The change also makes the deletion/separation code easier to
understand because it doesn't have to pass around the inversion.
This commit re-implements the resample curve node to use the new curves
type instead of CurveEval. The largest changes come from the need to
keep track of offsets into the point attribute arrays, and the fact
that the attributes for all curves are stored in a flat array.
Another difference is that a bit more of the logic is handled by
building of the field network inputs. The idea is to let the field
evaluator handle potential optimizations while making the rest of the
code simpler.
When resampling 1 million small poly curves,the node is about 6
times faster compared to 3.1 on my hardware (500ms to 80ms).
This also adds support for Catmull Rom curve inputs.
Differential Revision: https://developer.blender.org/D14435
This commit removes the implementations of legacy nodes,
their type definitions, and related code that becomes unused.
Now that we have two releases that included the legacy nodes,
there is not much reason to include them still. Removing the
code means refactoring will be easier, and old code doesn't
have to be tested and maintained.
After this commit, the legacy nodes will be undefined in the UI,
so 3.0 or 3.1 should be used to convert files to the fields system.
The net change is 12184 lines removed!
The tooltip for legacy nodes mentioned that we would remove
them before 4.0, which was purposefully a bit vague to allow
us this flexibility. In a poll in a devtalk post showed that the
majority of people were okay with removing the nodes.
https://devtalk.blender.org/t/geometry-nodes-backward-compatibility-poll/20199
Differential Revision: https://developer.blender.org/D14353
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 implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
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
This commit adds a search menu when links are dragged above empty
space. When releasing the drag, a menu displays all compatible
sockets with the source link. The "main" sockets (usually the first)
are weighted above other sockets in the search, so they appear first
when you type the name of the node.
A few special operators for creating a reroute or a group input node
are also added to the search.
Translation is started after choosing a node so it can be placed
quickly, since users would likely adjust the position after anyway.
A small "+" is displayed next to the cursor to give a hint about this.
Further improvements are possible after this first iteration:
- Support custom node trees.
- Better drawing of items in the search menu.
- Potential tweaks to filtering of items, depending on user feedback.
Thanks to Juanfran Matheu for developing an initial patch.
Differential Revision: https://developer.blender.org/D8286
This cleans up part of the code that still set the flag manually. Also, this
change helps with D13246 because it makes it easier to tag the node
tree as changed when the availability of a socket changed.
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
The object info node output an instance as a performance optimization.
Before that optimization was (almost) invisible to the user, but now
that we aren't automatically realizing instances, it isn't intuitive
for a single object to become an instance.
I refactored the transform node so its ability to translate/transform
an entire geometry set was more usable from elsewhere and exposed the
function to get a geometry set from an object.
Differential Revision: https://developer.blender.org/D12833
Delete Geometry:
This adds a copy of the old node in the legacy folder and updates the
node to work with fields. The invert option is removed, because it is
something that should be very easy with fields, and to be consistent
with other nodes which have a selection. There is also a dropdown to
select the domain, because the domain can't be determined from the
field input. When the domain does not belong on any of the components
an info message is displayed.
Separate Geometry:
A more general version of the old Point Separate node. The "inverted"
output is the same as using the delete geometry node.
Differential Revision: https://developer.blender.org/D12574
This commit extends the 'Cone' and 'Cylinder' mesh primitive nodes,
with two inputs to control the segments along the side and in the fill.
This makes the nodes more flexible and brings them more in line with
the improved cube node.
Differential Revision: https://developer.blender.org/D12463
This implements the initial core framework for fields and anonymous
attributes (also see T91274).
The new functionality is hidden behind the "Geometry Nodes Fields"
feature flag. When enabled in the user preferences, the following
new nodes become available: `Position`, `Index`, `Normal`,
`Set Position` and `Attribute Capture`.
Socket inspection has not been updated to work with fields yet.
Besides these changes at the user level, this patch contains the
ground work for:
* building and evaluating fields at run-time (`FN_fields.hh`) and
* creating and accessing anonymous attributes on geometry
(`BKE_anonymous_attribute.h`).
For evaluating fields we use a new so called multi-function procedure
(`FN_multi_function_procedure.hh`). It allows composing multi-functions
in arbitrary ways and supports efficient evaluation as is required by
fields. See `FN_multi_function_procedure.hh` for more details on how
this evaluation mechanism can be used.
A new `AttributeIDRef` has been added which allows handling named
and anonymous attributes in the same way in many places.
Hans and I worked on this patch together.
Differential Revision: https://developer.blender.org/D12414
Previously, built-in nodes had to implement "socket templates"
(`bNodeSocketTemplate`) to tell Blender which sockets they have.
It was nice that this was declarative, but this approach was way
too rigid and was cumbersome to use in many cases.
This commit starts to move us away from this rigid structure
by letting nodes implement a function that declares the sockets
the node has. Right now this is used as a direct replacement
of the "socket template" approach to keep the refactor smaller.
It's just a bit easier to read and write.
In the future we want to support more complex features like
dynamic numbers of sockets and type inferencing. Those features
will be easier to build on this new approach.
This new approach can live side by side with `bNodeSocketTemplate`
for a while. That makes it easier to update nodes one by one.
Note: In `bNodeSocketTemplate` socket identifiers were made
unique automatically. In this new approach, one has to specify
unique identifiers manually (unless the name is unique already).
Differential Revision: https://developer.blender.org/D12335
This mesh primitive enhances the Cube mesh primitive and allows the
creation of a cuboid with a configurable size and number of vertices
in all 3 directions. The Cube primitive is now similar to the Grid
primitive except that it works in 3 dimensions.
Previously it was possible to create a cube and scale it arbitrarily
along each axis. You could also subdivide the mesh, but the number of
subdivisions was equal along all axes. This meant that making the basic
frame for something like modular buildings wasn't trivial.
Inspired by tutorials and files for modular building creation.
The cuboid is created as a `Mesh` so that large meshes with millions of
faces are created quickly. Though edge calculation could be faster if
implemented here, edges are calculated using `BKE_mesh_calc_edges`
to reduce complexity, and in hopes that they may be calculated lazily
for `Mesh` in the future like vertex normals.
See the differential revision for more information.
Differential Revision: https://developer.blender.org/D11810
This node is quite similar to the curve to points node, but creates
points for only the start and end of each spline. This is a separate
node because the sampling from the curve to points node don't apply,
and just for ease of use.
All attributes from the curves are copied, including the data for
instancing: tangents, normals, and the derived rotations. One simple
use case is to make round caps on curves by instancinghalves of a
sphere on each end of the splines.
Differential Revision: https://developer.blender.org/D11719
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
This is especially useful when trying to add a node group instance, e.g. via
drag & drop from the Outliner or Asset Browser.
Previously this would just silently fail, with no information why. This is a
source of confusion, e.g. earlier, it took me a moment to realize I was
dragging a node group into itself, which failed of course.
Blender should always try to help the user with useful error messages.
Adds error messages like: "Nesting a node group inside of itself is not
allowed", "Not a compositor node tree", etc.
Adds a disabled hint return argument to node and node tree polling functions.
On error the hint is reported, or could even be shown in advance (e.g. if
checked via an operator poll option).
Differential Revision: https://developer.blender.org/D10422
Reviewed by: Jacques Lucke
This commit adds a simple node to output the min and max of an
axis-aligned bounding box for the input geometry, as well a rectangular
prism mesh created from these values for convenience.
The initial use case for this node is a "bounding box boolean", where
doing the boolean with just a bounding box could be signigicantly
faster, for cases like cutting a hole in a wall for a window. But it's
easy to imagine other cases where it could be useful.
This node supports mesh and point cloud data right now, volume support
will come as a separate patch. Also note that there is plenty of room
to improve the performance of this node through parallelization.
Differential Revision: https://developer.blender.org/D10420
Following some discussion among the geometry nodes team, it was decided
that keeping the primitive nodes simpler and requiring a separate
transform node to move the generated geometry from the origin would
be better.
- It's more consistent with the current general idea of "building
block nodes"
- It makes more sense for the future when it will be possible to
use instancing to control the transforms.
- It reduces UI clutter when the controls are not necessary.
This commit includes nodes to build the following primitives:
- Cone
- Cylinder
- Circle
- Cube
- UV Sphere
- Ico Sphere
- Line
- Plane/Grid
In general the inputs are the same as the corresponding operators
in the 3D view.
**Line Primitive**
The line primitive has two modes-- adding vertices between two end
points, or adding vertices each at an offset from the start point.
For the former mode, there is a choice between a vertex count
and a distance between each point.
**Plane Primitive**
This commit includes the "Plane" and "Grid" primitives as one node.
Generally primitives are named after the simpler form of the shape they
create (i.e. "Cone" can make some more complex shapes). Also, generally
you want to tweak the number of subdivisions anyway, so defaulting to
plane is not an inconvenience. And generally having fewer redundant
base primitives is better.
**Future Improvements**
A following patch proposes to improve the speed of the cylinder, cone,
and sphere primitives: D10730. Additional possible future improvements
would be adding subdivisions to the cube node and rings to the cone
and cylinder nodes.
Differential Revision: https://developer.blender.org/D10715
