e8f4010611 unified the bounds computation for the new curves
object type and the rest of the curves system used by geometry nodes.
In the process, it made bounds affected by the control point radius.
In theory that makes sense; the bounds are supposed to be the extents
of the visible geometry. But in practice the change wasn't expected,
for a few reasons:
- The radius has never affected the bounds for the legacy curve type
- The default radius of legacy curve objects is absurdly large at 1.0m
- Only the new curve object has visible radius, and only in "strip"
mode or when rendering with Cycles
Currently the bounds are only used for the "Bounding Box" geometry node
and the panel in the 3D viewport sidebar, so there isn't any incentive
to choose less intuitive behavior yet.
Long term, the correct behavior is probably to include the radius in
the bounds, but this commit postpones that change to when it works
better with the rest of the curves system.
Pull Request #105154
Writing to a bitmap from multiple threads causes races when writing to
bits within the same integer. Instead, write to a separate boolean
array while subdividing, then move that to the final mesh bit vector.
Notes:
- The final copy to the bit vector could be replaced by a generic
`copy_from(Span<bool>)` call in the future.
- Theoretically we could entirely replace the `BitVector` with an
`Array<bool>`, but 1/8 the memory use for edges is likely worth it.
Pull Request #105156
The initial subdivision context counting ended up using unnecessarily
complicated logic to count the number of final vertices. In a first pass
it added vertices for every coarse edge. Then it added the same number
of vertices for every loose edge. That adds up to the same number of
vertices for the edges, so the separation is redundant and can be
replaced with a single multiplication.
The bitmap doesn't need to be cleared then, since it isn't used now.
In a test of a mesh with 2 million faces and 3 million vertices, this
saved 2.8ms (though the whole subdivision process takes around 700ms).
Pull Request #105159
This might've been a merge error, the result of color mixing
was being overwritten by a simple copy of source to destination
inside of layerCopyValue_propcol.
Blender currently has 2 algorithms for merging vertices:
- `BKE_mesh_merge_verts`;
- `blender::geometry::create_merged_mesh`
`BKE_mesh_merge_verts` has a simplified algorithm to work with Array,
Mirror and Screw modifiers. It doesn't support merge results that would
create new faces. However it has shortcuts to be more efficient in
these modifiers.
`blender::geometry::create_merged_mesh` tries to predict all possible
outcomes. So it's a more complex. But it loses in performance to
`BKE_mesh_merge_verts` in some cases.
The performance comparison between these two depends on many factors.
`blender::geometry::create_merged_mesh` works with a context that has
only the affected geometry. Thus a smaller region of the mesh is read
for duplicate checking. Therefore, the smaller the affected geometry,
the more efficient the operation.
By my tests `blender::geometry::create_merged_mesh` beats
`BKE_mesh_merge_verts` when less than 20% of the geometry is affected
in worst case `MESH_MERGE_VERTS_DUMP_IF_EQUAL` or 17% in case of
`MESH_MERGE_VERTS_DUMP_IF_MAPPED` .
For cases where the entire geometry is affected, a 30% loss was noticed,
largely due to the creation of a context that represents the entire mesh.
Co-authored-by: Germano Cavalcante <germano.costa@ig.com.br>
Pull Request #105136
Using spans instead of raw pointers helps to differentiate ararys from
pointers to single elements, gives bounds checking in debug builds, and
conveniently stores the number of elements in the same variable.
Also make variable naming consistent. For example, use `loops` instead
of `mloop`. The plural helps to clarify that the variable is an array.
I didn't change positions because there is a type mismatch between
C and C++ code that is ugly to manage. All remaining code can be
converted to C++, then that change will be simpler.
Pull Request #105138
This code seems to be left over from before edges, polys, and loops were
stored in CustomData. They are already copied by the CustomData copy
calls directly above, which already deal with every other layer.
This might've been a merge error, the result of color mixing
was being overwritten by a simple copy of source to destination
inside of layerCopyValue_propcol.
Originally caused by 6514bb05ea
More cases where the active/default color attributes were not set
correctly:
[1] Using the old Python vertex_colors API (vertex_colors.new)
[2] OBJ importer
[3] Collada importer
[4] Data Transfer layout (both standalone operator and "Generate Data
Layers" from the modifier)
Similar to 101d04f41f.
Brought over from https://archive.blender.org/developer/D16977, see
discussion there why some of the code for data transfer is not for the
genereal attribute API.
Pull Request #105020
Drawing code `paint_draw_smooth_cursor` would be called correctly, it
was just the color not being initialized.
This is usually done with `BKE_paint_init`, but in the case of curves
sculpting brushes this would create an additional (unnamed) brush which
should be avoided since the workspace toolsystem creates the "right"
brush anyways.
So this patch just does the minimal work to get the Stabilize Stroke
indicator line to draw (which is initializing the color).
Brought over from https://archive.blender.org/developer/D16793
(cherry picked from commit 612a4382c443bcd02e0bb5ffd1b1fdbb251f6e7b)
Pull Request #105021
Arrays for curve handle types were allocated even when there were no
Bezier curves. This saves 0.5ms of the total 0.9ms spent creating the
evaluated curve offsets, which happens every time the topology
of non-poly curves change.
Mandatory change for the Brush Assets project, from quick test does not
seem to break anything (more) in existing 'old' brushes...
Re. #101908.
Pull Request #105016
Simplify modifier sample mode didn't transfer UV parameters, now fixed.
(This is the corrected commit, previous one has multiple other commits merged.)
Pull Request #104964
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
In the first loop is safe to remove the current element.
The second loop can remove any element, potentially the next.
This triggers a read after freed.
Pull Request #104897
When the new UV to legacy format conversion happens, the mesh is in
the middle of being written and is an at best "complicated", at worst
invalid state. The attribute API looks at other domains and is a bit
less forgiving in that respect, and shouldn't really be used here. Use
the CustomData API instead. Also sort the layers the same way as
b642dc7bc7.
This reverts commit 68181c2560.
I merged 3.6 into 3.5 by mistake. Basically I had a PR against main,
then changed it in the last minute to be against 3.5 via the
web-interface unaware that I shouldn't do it without updating the
patch.
Original Pull Request: #104889
Note that the node group has its sockets names
translated, while the built-in nodes don't.
So we need to use data_ for the built-in nodes names,
and the sockets of the created node groups.
Pull Request #104889
This was broken even before 0649e63716 and was always expanding the
`Image`, not the movie clip (even if the source was set to
`CAM_BGIMG_SOURCE_MOVIE`)
Now the rule here seems to be to always expand unconditionally, so
remove checking the source and always expand image and movie clip.
Co-authored-by: Philipp Oeser <philipp@blender.org>
Pull Request #104815
The evaluated positions cache can live longer than a specific
`CurvesGeometry`, but for only-poly curves, it pointed to the positions,
which are freed when the curves are. Instead, use the same pattern
as the evaluated offsets and don't store the positions span, just return
it when retrieving evaluated positions.
The default import method for an asset library can now be determined in
the Preferences. The Asset Browser has a new "Follow Preferences" option
for the importing. The essentials asset library still only uses "Append
(Reuse Data)".
This is part of #104686, which aims at improving the import method
selection, especially for the introduction of the new essentials library
(which doesn't support certain import methods). Further changes are
coming to improve the UI, see #104686.
Pull Request: #104688
This adds a new `Curve Falloff` popover to the comb brush tool settings.
The curve control allows changing the brush weight along the curve to
e.g. affect the tip more than the root. This is a relative way to get
something like stiffness for short hair.
This functionality could potentially be added to some other brushes,
but the comb brush is the most important one, so that is added first.
I did add the buttons add the buttons to choose a curve map preset.
However, I did not add the preset dropdown, because that just adds
some unnecessary complexity in the code now and is redundant.
Pull Request #104589
The existing logic to copy `BMesh` custom data layers to `Mesh`
attribute arrays was quite complicated, and incorrect in some cases
when the source and destinations didn't have the same layers.
The functions leave a lot to be desired in general, since they have
a lot of redundant complexity that ends up doing the same thing for
every element.
The problem in #104154 was that the "rest_position" attribute overwrote
the mesh positions since it has the same type and the positions weren't
copied. This same problem has shown up in boolean attribute conversion
in the past. Other changes fixed some specific cases but I think a
larger change is the only proper solution.
This patch adds preprocessing before looping over all elements to
find the basic information for copying the relevant layers, taking
layer names into account. The preprocessing makes the hot loops
simpler.
In a simple file with a 1 million vertex grid, I observed a 6%
improvement animation playback framerate in edit mode with a simple
geometry nodes modifier, from 5 to 5.3 FPS.
Fixes#104154, #104348
Pull Request #104421
The issue was caused by rather recent refactor in 7dea18b3aa.
The root of the issue lies within the fact that the optical center was updated
on the Blender side after the solution was run. There was a mistake in the code
which double-corrected for the pixel aspect ratio.
Added a comment in the code about this, so that it does not look suspicious.
Pull Request #104711
## Cleanup: Refactor NLATrack / NLAStrip Remove
This PR adds 3 new methods:
* BKE_nlatrack_remove_strip
* BKE_nlastrip_remove
* BKE_nlastrip_remove_and_free
These named BKE methods are really just replacements for BLI_remlink, but with some added checks, and enhanced readability.
Co-authored-by: Nate Rupsis <nrupsis@gmail.com>
Pull Request #104437
Don't create caps when using cyclic profile splines with two or fewer
points.
This case wasn't handled, yet, leading to invalid meshes or crashes.
Co-authored-by: Leon Schittek <leon.schittek@gmx.net>
Pull Request #104594
