| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is not the case though, the modifier act explicitly on mesh edges,
if no tesselated mesh is provided, it would simpy early out and do
nothing.
Now always disable the "Apply on Spline" option with a tip that this
modifier can only smooth the tesselated curve (not the underlying curve
control points). Similar to rB1a6b51e17502.
Fixes T102060.
Maniphest Tasks: T102060
Differential Revision: https://developer.blender.org/D16386
|
|
|
|
`CurveEval` was added for the first iteration of geometry nodes curve
support. Since then, it has been replaced by the new `Curves` type
which is designed to be much faster for many curves and better
integrated with the rest of Blender. Now that all curve nodes have
been moved to use `Curves` (T95443), the type can be removed,
along with the corresponding geometry component.
|
|
Added by mistake in 6718afdc8a32.
|
|
|
|
With the ultimate goal of simplifying drawing and evaluation,
this patch makes the following changes and removes code:
- Use `Mesh` instead of `DispList` for evaluated basis metaballs.
- Remove all `DispList` drawing code, which is now unused.
- Simplify code that converts evaluated metaballs to meshes.
- Store the evaluated mesh in the evaluated geometry set.
This has the following indirect benefits:
- Evaluated meshes from metaball objects can be used in geometry nodes.
- Renderers can ignore evaluated metaball objects completely
- Cycles rendering no longer has to convert to mesh from `DispList`.
- We get closer to removing `DispList` completely.
- Optimizations to mesh rendering will also apply to metaball objects.
The vertex normals on the evaluated mesh are technically invalid;
the regular calculation wouldn't reproduce them. Metaball objects
don't support modifiers though, so it shouldn't be a problem.
Eventually we can support per-vertex custom normals (T93551).
Differential Revision: https://developer.blender.org/D14593
|
|
|
|
|
|
Currently when converting from the legacy curve type to the new type,
which happens during evaluation of every legacy curve object, the
`CurveEval` type is used as an intermediate step. This involves
copying all data twice, and allocating a bunch of temporary arrays.
It's also another use of `CurveEval` that has to be removed before
we remove the type.
The main user difference besides the subtlety described below
will be improved performance.
**Invalid Handles and Types**
One important note is that there are two cases (that I know of)
where handles and handle types can be invalid in the old curve
type. The first is animation, where animated handle positions don't
necessary respect the types. The second is control points with a
single aligned handle that didn't necessarily align with the other.
In master (partially on purpose) the code corrects the first situation
(which caused T98965). But it doesn't correct the second situation.
It's trivial to correct for the second case with this patch (because of the
eager calculation decided on in D14464), but this patch makes the choice
not to correct for //either//.
Though not correcting the handle types puts curves in an invalid state,
it also adds flexibility by allowing that option. Users must understand
that any deformation may correct invalid handles.
Fixes T98965
Differential Revision: https://developer.blender.org/D15290
|
|
The original mistake I made in b9febb54a492ac6c938 was thinking
that the input curve object data to `BKE_displist_make_curveTypes`
was already copied from the original. I think I misread some of its
`ID` flags. This commit places the result of curves evaluation in a
duplicated curve instead, and copies the edit mode pointers
necessary for drawing overlays. `Curve` needs to know not to
free those pointers.
I still don't have a full understanding of why some of the tactics I've
used work and others don't. I've probably tried around 8 different
solutions at this point, and this is the best I came up with.
The dependency graph seems to have some handling of edit mode
pointers that make the edit mode overlays work if the evaluated
result is only an empty curve created by the evaluated geometry set.
This doesn't work with the current method and I need to set the
edit mode pointers at the end of evaluation explicitly.
We're constrained by the confusing duality of the old curves system
combined with the new design using the evaluated geometry set.
Older areas of Blender expect the evaluated `Curve` to be a copy
of the original, even if it was replaced by some arbitrary evaluated mesh.
Differential Revision: https://developer.blender.org/D14561
|
|
This is mostly a cleanup to avoid hardcoding the eager calculation of
normals it isn't necessary, by reducing calls to `BKE_mesh_calc_normals`
and by removing calls to `BKE_mesh_normals_tag_dirty` when the mesh
is newly created and already has dirty normals anyway. This reduces
boilerplate code and makes the "dirty by default" state more clear.
Any regressions from this commit should be easy to fix, though the
lazy calculation is solid enough that none are expected.
|
|
Instead of using `CurveEval` to draw the curve wire edges, use
the new `Curves` data-block, which is already built as part of
an object's evaluated geometry set whenever there is a
`CurveComponent`.
This means that we can remove `Curve`'s temporary ownership
of `CurveEval` for drawing (added in 9ec12c26f16ea3da1e),
which caused a memory leak as described in T96498.
In my testing this improved performance by around 1.5x during
viewport playback, back to the performance of 3.1 before the
curve data structure transition started.
The next step of using the GPU to do the final curve evaluation
for the viewport is described in T96455, but is unrelated.
Differential Revision: https://developer.blender.org/D14551
|
|
This commit furthers some of the changes that were started in
rBb9febb54a492 and subsequent commits by changing the way surface
objects are presented to render engines and other users of evaluated
objects in the same way. Instead of presenting evaluated surface objects
as an `OB_SURF` object with an evaluated mesh, `OB_SURF` objects
can now have an evaluated geometry set, which uses the same system
as other object types to deal with multi-type evaluated data.
This clarification makes it more obvious that lots of code that dealt
with the `DispList` type isn't used. It wasn't before either, now it's
just *by design*. Over 1100 lines can be removed. The legacy curve
draw cache code is much simpler now too. The idea behind the further
removal of `DispList` is that it's better to focus optimization efforts
on a single mesh data structure.
One expected functional change is that the evaluated mesh from surface
objects can now be used in geometry nodes with the object info node.
Cycles and the OBJ IO tests had to be tweaked to avoid using evaluated
surface objects instead of the newly exposed mesh objects.
Differential Revision: https://developer.blender.org/D14550
|
|
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
|
|
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
|
|
API added in rBa3ad5abf2fe85d623f9e78fefc34e27bdc14632e
|
|
This broke "test_undo.view3d_multi_mode_select" test in
"lib/tests/ui_simulate" and is likely exposed by recent changes to
bounding box calculation.
The missing check for DL_INDEX4 dates back to code from 2002 which
intended to check this but was checking for DL_INDEX3 twice
which got removed as part of a cleaned up.
This could be hidden from memory checking tools as meta-balls
over-allocate vertex arrays.
|
|
- 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
|
|
These existing names were unhelpful at best, actively confusing at
worst. This patch renames them to be consistent with the terms
used to refer to the values in the UI.
- `width` -> `offset`
- `ext1` -> `extrude`
- `ext2` -> `bevel_radius`
Differential Revision: https://developer.blender.org/D9627
|
|
Regression since 3.93 caused by 752c6d668bcb.
Follow the code from 2.93 which was always leaving curve modifiers
evaluation with a valid and clean state of the bounding box.
This is also what was proposed and agreed on in the following
design task: T92206: Bounding Box: compute during depsgraph evaluation
Tested with files from T90808 and T93384.
For the 3.0 going with the safest and minimal change. The rest of
the bounding box un-entanglement is to happen outside of the stable
branch.
Thanks The patch is based on the code from Philipp Oeser and
investigation by Germano Cavalcante and Dr. Sybren A. Stüvel,
thanks!
Differential Revision: https://developer.blender.org/D13409
|
|
There are two functions that recalculate the boundbox of an object:
- One that considers the evaluated geometry
- Another that only considers the object's `data`.
Most of the time, the bound box is calculated on the final object
(with modifiers), so it doesn't seem right to just rely on `ob->data`
to recalculate the `ob->runtime.bb`.
Be sure to calculate the BoundBox based on the final geometry and
only use `ob->data` as a fallback
Differential Revision: https://developer.blender.org/D12282
|
|
Evaluated meshes from curves are presented to render engines as
separate instance objects now, just like evaluated meshes from other
object types like point clouds and volumes. For that reason, cycles
should not consider curve objects as geometry (previously it did,
meaning it retrieved a second mesh from the curve object as well
as the temporary evaluated mesh geometry).
Further, avoid adding a curve object's evaluated mesh as data_eval,
since that is special behavior for meshes that is arbitrary. Adding an
evaluated mesh there but not an evalauted pointcloud is arbitrary,
for example. Retrieve the evaluated mesh in from the geometry set
in BKE_object_get_evaluated_mesh now, to support that change.
This gets us closer to a place where all of an object's evaluated data
is stored in geometry_set_eval, and we just have helper functions
to access specific geometry components.
Differential Revision: https://developer.blender.org/D13118
|
|
Match API naming prefix (BKE_vfont_*) and DNA_vfont_types.h.
|
|
|
|
This patch simplifies the curve object to mesh conversion
used by the object convert operator and exporters.
The existing code had a convoluted model of ownership, and did quite
a bit of unnecessary work. It also assumed that curve objects always
evaluated to a mesh, which is not the case anymore.
Now the code checks if the object it receives is evaluated. If so,
it can simply return a copy of the evaluated mesh (or convert the
evaluated curve wire edges to a mesh if there was no evaluated mesh).
If the object isn't evaluated, it uses a temporary copy of the object
with modifiers removed to create the mesh in the same way.
This follows up on the recent changes to curve evaluation,
namely that the result is always either a mesh or a wire curve.
Differential Revision: https://developer.blender.org/D12533
|
|
Also remove unnecessary parantheses.
|
|
|
|
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
|
|
|
|
Use BKE_mesh_calc_normals instead of
BKE_mesh_calc_normals_mapping_simple for curve modifier calculation.
This only made sense for derived-mesh which is no longer used.
|
|
Caused by {rB8cbff7093d65}.
Since above commit only one modifier would get calculated and the
displaylist boundingbox was calculated wrong.
Maniphest Tasks: T90154
Differential Revision: https://developer.blender.org/D12037
|
|
Generally the evaluated mesh should not be changed, since that is the
job of the modifier stack. Current code is far from const correct in
that regard. This commit uses a const variable for the reult of
`BKE_object_get_evaluated_mesh` in some cases. The most common
remaining case is retrieving a BVH tree from the mesh.
|
|
This is simpler, more consistent, and takes up less space.
|
|
This commit avoids duplicating the deformed control point
list twice by modifying the list in the object curve cache directly.
For curves, the original control point data was duplicated into a
local listbase, deformed, used to create the "bevel list" data, and
then duplicated again for the object-level storage of deformed
control points. Text objects and surface objects had a similar
unnecessary duplication.
|
|
The curve bevel list was freed, and then freed again in a call to the
function that recalulates it. The curve "anim path" data was freed
only to be freed again in its calculation function as well. Also move
the anim_path calculation directly after the bevel list creation to
make its requirements more explicit.
|
|
Surface objects were already handled by an early return in the main
"curve types" function. This commit splits them, renames the funtions
to match (and be more consistent with other names), and sanitizes the
checking of object types.
|
|
|
|
Every call to `BKE_displist_make_curveTypes` already checks the object
type beforehand, there is no need to check it again. Also removed an
outdated comment.
|
|
`BKE_displist_make_curveTypes` had a `for_orco` argument that was
always false in calls to the function. Removing it allows the curve
displist and modifier evaluation code to become simpler. There are
some related cleanups in rBdf4299465279 and rB93aecd2b8107.
|
|
|
|
|
|
|
|
rB8cbff7093d65 neglected to move the "pre-tesselation" modifier to the
next before calculating the second part of the curve modifier stack.
|
|
|
|
Also use Curve as an argument instead of Object, since the object was
only used to retrieve the curve, and the calling code is already working
with curve data.
|
