| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Includes unwanted changes
This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
|
|
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
|
|
Reverted because the commit removes a lot of commits.
This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
|
|
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
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
`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
|
|
It's better to calculate the size of a spline before creating it, and this
should simplify refactoring to a data structure that stores all point
attribute contiguously (see T94193). The mesh to curve conversion is
simplified slightly now, it creates the curve output after gathering all
of the result vertex indices. This should be more efficient too, since
it only grows an index vector for each spline, not a whole spline.
|
|
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
|
|
|
|
|
|
- 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
|
|
|
|
Add the following methods to the CurveEval class:
total_length() : returns the total length of the curve without needing to
allocate a new array
total_control_point_size() : returns the total number of control points without
needing to allocate a new array
|
|
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
|
|
|
|
When Constructing bezier splines from dna, the positions of the
left/right handles were set directly in the internal vectors, by
requesting a reference to them. The problem is that
BezierSpline::handle_positions_left() calls ensure_auto_handles()
before returning the reference. That function does some calculations on
uninitialized memory if the positions array is not yet filled.
Differential Revision: https://developer.blender.org/D13107
|
|
This is a better and more general fix for T92511 and T92508 than
the ones that I committed before.
Previously, we tagged caches dirty when first accessing attributes.
This led to incorrect caches when under some circumstances. Now
cache invalidation is part of `OutputAttribute.save()`.
A nice side benefit of this change is that it may make things more
efficient in some cases, because we don't invalidate caches when
they don't have to be invalidated.
Differential Revision: https://developer.blender.org/D13009
|
|
This commit exposes left and right bezier handles as an attribute.
Interaction basically works like edit mode. If you move an aligned
handle, it also moves the opposite handle of the control point.
The difference is that you can't edit "Auto" or "Vector" handles,
you have to first use the "Set Handle Type" node. That gives the handle
types a bit more meaning in the node tree-- changing them in edit mod
is more like a "UI override".
The attributes are named `handle_start` and `handle_end`,
which is the same name used in the curve RNA API.
A new virtual array implementation is added which handles the case of
splines that don't have these attributes, and it also calls two new
functions on `BezierSpline` to set the handle position accounting
for aligned handles.
The virtual arrays and attribute providers will be refactored
(probably templated) in the future, as a next step after the last
built-in curve attribute provider has landed.
Differential Revision: https://developer.blender.org/D12005
|
|
This node allows sampling positions, tangents, and normals at any
arbitrary point along a curve. The curve can include multiple splines,
all are taken into account. The node does not yet support transferring
generic attributes like radius, because some more general tooling will
make that much more feasible and useful in different scenarios.
This is a field node, so it is evaluated in the context of a data-flow
node like "Set Position". One nice thing about that is it can easily
be used to move an entire geometry like the follow path constraint.
The point along the curve is chosen either with a factor of the total
length of the curve, or a length into the curve, the same choice used
in the curve trim node.
Differential Revision: https://developer.blender.org/D12565
|
|
This moved the spline reversing logic out of the Curve Reverse geometry
node and into the spline class. This allows a spline to reverse itself
with a call to `my_spline.reverse()`
The base class will reverse position, radii & tilt, while specialized
versions are created for Bezier and Nurbs splines to reverse the
additional data that these classes encapsulate.
Differential Revision: https://developer.blender.org/D12501
|
|
It will be useful in the spline type conversion node. Theoretically it
could become protected again if that conversion moves out of a node,
which might be a nice improvement after an initial version.
|
|
The need for this has come up a few times.
|
|
Because these handles are calculated lazily, we need to make sure they
are calculated before switching to a manually positioned mode.
I doubt it would ever be necessary, but theoretically this could happen
on a per-point level, to avoid calculating handles not in the selection.
|
|
This logic is from the curve sundivide node, used to add points with
proper handles in between two existing points. However, the same logic
is used for trimming of Bezier splines, and possibly interactive point
insertion in the future, so it's helpful as a general utility.
The logic is converted to depend on a bezier spline instead of being
static. A temporary segment spline can be used for the latter use case.
|
|
Sometimes the current spline list isn't part of the original curve, like
when using the deformed control points, etc. This will be helpful in
the curve modifier stack.
|
|
* Mark either all or no class methods with override
* Don't use zero sized array since it has a different size in C and C++.
Using a little more memory here is not significant.
* Don't use deprecated mechanism to mark private GSet members in clang
just like we don't for MSVC, it warns even for simple zero initialization.
|
|
Make the virtual functions protected and simpler, so that the logic is
better contained in the base class's implementation. Also introduce a
`copy_without_attributes` method to be used for realizing instances.
|
|
`src` and `dst` are perfectly clear, and avoid repeating unecessary
characters when writing the variables many times, allowing more space
for everything else.
|
|
The names were slightly longer than they needed to be clear,
and when they are shorter they tend to fit on one line better.
|
|
The normals were broken because the normal calculation mode wasn't set.
This patch adds a default normal mode so all code creating a spline does
not necessarily have to set it manually. In the future there should be a
way to change this value in the node tree.
|
|
There is no particular reason these two functions shouldn't be used
outside of the bezier spline implementation since they don't do anything
particularly controversial.
|
|
This helps when adding splines to a new curve in parallel.
|
|
First, expand on the interpolation to evaluated points with a templated
helper function, and a function that takes a GSPan. Next, add a set of
functions to `Spline` for interpolating at arbitrary intervals between
the evaluated points. The code for doing that isn't that complicated
anyway, but it's nice to avoid repeating, and it might make it easier
to unroll the special cases for the first and last points if we require
the index factors to be sorted.
|
|
Often you need to copy a spline to do an operation, but don't want
to manually copy over all of the settings. I've already forgotten to
do it once anyway. These functions copy a spline's "settings" into a
new spline, but not the data. I tried to avoid duplicating any copying
so this is easier to extend in the future.
Differential Revision: https://developer.blender.org/D11463
|
|
We need a pointer to this in DNA, which means it cannot be a class.
|
|
|
|
With this patch you will be able to add and remove attributes from curve
data inside of geometry nodes. The following is currently implemented:
* Adding attributes with any data type to splines or spline points.
* Support for working with multiple splines at the same time.
* Interaction with the three builtin point attributes.
* Resampling attributes in the resample node.
The following is not implemented in this patch:
* Joining attributes when joining splines with the join geometry node.
* Domain interpolation between spline and point domains.
* More efficient ways to call attribute operations once per spline.
Differential Revision: https://developer.blender.org/D11251
|
|
There is no need for a special "copy" method with a copy constructor,
which will be necessary to explicitly copy attributes anyway.
|
|
Since spline data is stored separately for each spline, the data often
needs to be flattened into a separate array. It's helpful to have the
necessarily-sequential part of that split off into a separate method.
I've found myself using functions like these in quite a few places.
|
|
|
|
By rearranging a few variables we can remove redundant specifiers
|
|
Not allowing external direct access to the vector of splines in the
curve will help for things like reallocating custom data when a spline
is added or removed.
|
|
This commit exposes the first spline control point attributes. The
implementation incorporates the attributes into the virtual array
system, providing efficient methods to flatten the data into a
contiguous array and to apply changes from a flattened array. This
is only part of the eventual goal, which includes changes to run
attribute nodes separately for each spline to completely avoid copying.
So far `tilt` and `radius`, the two generic attributes common to
all spline types, are implemented. The more complex `position`
attribute is also added. It requires some special handling for Bezier
splines, where the control point handles need to be moved along with
the control points. To make that work I also added automatic handle
recalculation to the Bezier spline.
Differential Revision: https://developer.blender.org/D11187
|
|
The order was arbitrary, and rearranging the declarations
makes the class look less messy, and makes room for future comments.
|
|
Was giving a warning:
```
BKE_spline.hh:293:35: warning: 'interpolate_to_evaluated_points' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
```
|
|
This node generates a naturally parametarized (even length edge) poly
spline version of every spline in the input. There are two modes,
"Count", and "Length". These are similar to the same options for the
line primitive node in end points mode.
I implemented this instead of a "Sample Points" node, because for this
operation it's trivial to keep the result as a curve, which is nice
since it increases flexibility, and because it can make instancing
simpler, i.e. using the transforms of each evaluated point rather than
requiring the construction of a "rotation" attribute.
Differential Revision: https://developer.blender.org/D11173
|
|
|
|
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
|
