When use smooth tool in a cyclic stroke, the smoothing algorithm was not using the adjacent points if these are the end or start of stroke.
Now, the smooth uses the other extreme of the stroke to compute smoothness.
This change will ensure at least one 'local' collection can host the new
'local' override of all objects (indirectly) overridden by this
operation, such that no new override of object ends up in master
collection (which can become extremely messy in production files).
In practice, it means often at least one of the linked collection owning
those objects also has to be overridden.
NOTE: This only affect cases where root overridden linked object has
some dependencies outside of its own root linked collection. While this
situation should be avoided, it cannot always be, so we try to support
it as best as we can.
Those were missing proper (explicit) object cache clear, and DEG
tagging.
Note that this was most likely not an common issue in practice (Collection
object cache clearing recursively goes into all parents, so master
collection would only miss it in case they had no child collections at
all, and tagging of those happens almost always at other steps on
remapping). But better to be explicit and consistent here in any case.
This reverts commit rB3a48147b8ab92, and fixes the issues with linking
etc.
Change compared to previous buggy commit (rBf8d219dfd4c31) is that
new `BlendFileReadReports` reports are now passed to the lowest level
function generating the `FileData` (`filedata_new()`), which ensures
(and asserts) that all code using it does have a valid non-NULL pointer
to a `BlendFileReadReport` data.
Sorry for the noise, it's always when you think a change is trivial and
do not test it well enough that you end up doing those kind of
mistakes...
When cut a stroke of 1 point, the clean up done to avoid keep 1 point strokes removes the memory, but the pointer to the first stroke was not set to NULL. As this pointer is invalid now, any use of this produces a segment fault because the pointer is corrupted..
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
This problem has surprisingly been there for quite a few months.
For point clouds all attributes were handled the same, even "position",
which should be transformed when combining source points into the
destination.
Previously the code assumed that curve instances had no attributes.
This is true when the data came from curve objects, which don't support
attributes currently, but it isn't necessarily true when retrieving curves
from evaluated geometry sets.
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.
Add direct user feedback (as a warning report) to user when recursive
resync of overrides was needed.
And some timing (as CLOG logs) about main readfile process steps.
This is essentially adding a new BlendFileReadReport structure that wraps
BKE_reports list, and adds some extra info (some timing, some info about
overrides and (recursive) resync, etc.).
`src` and `dst` are perfectly clear, and avoid repeating unecessary
characters when writing the variables many times, allowing more space
for everything else.
The depth cache (located in `RegionView3D::depths`) is used for quick
and simple occlusion testing in:
- particle selection,
- "Draw Curve" operator and
- "Interactive Light Track to Cursor" operator,
However, keeping a texture buffer in cache is not a recommended practice.
For displays with high resolution like 8k this represents something
around 132MB.
Also, currently, each call to `ED_view3d_depth_override` invalidates
the depth cache. So that depth is never reused in multiple calls from
an operator (this was not the case in blender 2.79).
This commit allows to create a depth cache and release it in the same
operator. Thus, the buffer is kept in cache for a short time, freeing
up space.
No functional changes.
A different data structure / implementation is used for curves in the
node tree currently. Converting from the DNA `Curve` structure to this
wasn't slow, but it's nice to decrease overhead. In a test of 14000
splines with 128000 points, this halves the runtime from about 5ms
to about 2.5ms.
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.
- Multi-thread BKE_mesh_recalc_looptri.
- Add BKE_mesh_recalc_looptri_with_normals,
this skips having to calculate normals for ngons.
Exact performance depends on number of faces, size of ngons and
available CPU cores.
For high poly meshes the isolated improvement to BKE_mesh_recalc_looptri
in my tests was between 6.7x .. 25.0x, with the largest gains seen in
meshes containing ngons with many sides.
The overall speedup for high poly meshes containing quads and triangles
is only ~20% although ngon heavy meshes can be much faster.
This patch adds support for filtering rows based on rules and values.
Filters will work for any attribute data source, they are a property
of the spreadsheet rather than of the attribute system. The properties
displayed in the row filter can depend on data type of the currently
visible column with that name. If the name is no longer visible, the
row filter filter is grayed out, but it will remember the value until
a column with its name is visible again.
Note: The comments in `screen.c` combined with tagging the sidebar
for redraw after the main region point to a lack of understanding
or technical debt, that is a point to improve in the future.
**Future Improvements**
* T89272: A search menu for visible columns when adding a new filter.
* T89273: Possibly a "Range" operation.
Differential Revision: https://developer.blender.org/D10959
Currently B-Bone scaling can only be controlled via their
properties, thus requiring up to 8 drivers per joint between
B-Bones to transfer scaling factors from the handle bone.
A Scale Easing option is added to multiply the easing value
by the Y scale channels to synchronize them - this produces a
natural scaling effect where both the shape of the curve and
the scale is affected.
In addition, four toggles are added for each handle, which
multiply each of the X, Y, Z and Ease values by the matching
Local Scale channel of the handle bone, thus replacing trivial
drivers. The Scale Easing option has no effect on this process
since it's easy to just enable both Length and Ease buttons.
Differential Revision: https://developer.blender.org/D9870
Implement actual behavior for the B-Bone Y Scale channels added
to DNA and UI in the previous commit in addition to the existing
X and Z Scale inputs.
The two length scale inputs control the ratio between the lengths
of the start and end segments of the bone: although for convenience
two inputs are provided, the whole chain is still uniformly scaled
to fit the curve.
Differential Revision: https://developer.blender.org/D9870
In addition to the base bone transformation itself, B-Bones have
controls that affect transformation of its segments. For rotation
the features are quite complete, allowing to both reorient the
Bezier handles via properties, and to control them using custom
handle bones. However for scaling there are two deficiencies.
First, there are only X and Y scale factors (actually X and Z),
while lengthwise all segments have the same scaling. The ease
option merely affects the shape of the curve, and does not cause
actual scaling.
Second, scaling can only be controlled via properties, thus
requiring up to 6 drivers per joint between B-Bones to transfer
scaling factors from the handle bone. This is very inefficient.
Finally, the Z channels are confusingly called Y.
This commit adds a B-Bone Y Scale channel and extra B-Bone flag
fields to DNA with appropriate versioning (including for F-Curves
and drivers) in preparation to addressing these limitations.
Functionality is not changed, so the new fields are not used
until the following commits.
Differential Revision: https://developer.blender.org/D9870
When an object, whose mesh gets loaded from Alembic, gets animated in
Blender and the Alembic CacheFile datablock also gets animated, editing
keyframes causes both datablock to be re-copied for evaluation. This
caused a threading issue and a double-free of some memory. This is fixed
by expanding the scope of the spin lock in
`BKE_cachefile_reader_free()`.
This matches BMesh which also has tessellation in it's own file.
Using a separate file helps with organization when
extracting code into smaller functions.
The //Raycast// node intersects rays from one geometry onto another.
It computes hit points on the target mesh and returns normals, distances
and any surface attribute specified by the user.
A ray starts on each point of the input //Geometry//. Rays continue
in the //Ray Direction// until they either hit the //Target Geometry//
or reach the //Ray Length// limit. If the target is hit, the value of the
//Is Hit// attribute in the output mesh will be true. //Hit Position//,
//Hit Normal//, //Hit Distance// and //Hit Index// are the properties of the
target mesh at the intersection point. In addition, a //Target Attribute//
can be specified that is interpolated at the hit point and the result
stored in //Hit Attribute//.
Docs: D11620
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D11619
This node creates splines with more control points in between the
existing control points. The point is to give the splines more
definition for further tweaking like randomization with white noise,
instead of deforming a resampled poly spline with a noise texture.
For poly splines and NURBS, the node simply interpolates new values
between the existing control points. However, for Bezier splines,
the result follows the existing evaluated shape of the curve, changing
the handle positions and handle types to make that possible.
The number of "cuts" can be controlled by an integer input, or an
attribute can be used. Both spline and point domain attributes are
supported, so the number of cuts can vary using the value from the
point at the start of each segment.
Dynamic curve attributes are interpolated to the result with linear
interpolation.
Differential Revision: https://developer.blender.org/D11421
The minimum twist mode is important because it allows creating
normals without sudden changes in direction. The disadvantage
of minimum twist normals is that the normals depend on all control
points. So changing one control point can change the normals
everywhere. The computed normals do not match the existing
code exactly, although they do match quite well on non-cyclic and
on some cyclic curves. I also noticed that the existing implementation
has some fairly simple failure cases that I haven't found in the new
implementation so far.
Differential Revision: https://developer.blender.org/D11621
