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
- BKE_mesh_copy_parameters_for_eval to be used for evaluated meshes only
as it doesn't handle ID user-counts.
- BKE_mesh_copy_parameters is a general function for copying parameters
between meshes.
This allows line art to run only once for each modifier stacks,
with an option to toggle a specific line art modifier should
use cache or re-do their own calculations.
Reviewed By: Sebastian Parborg (zeddb), Hans Goudey (HooglyBoogly)
Differential Revision: https://developer.blender.org/D11291
This makes it easier to use task isolation in c++ code.
Previously, one either had to check `WITH_TBB` (possibly indirectly
through `WITH_OPENVDB`) or one had to use the C function which
is less convenient.
This namespace groups threading related functions/classes. This avoids
adding more threading related stuff to the blender namespace. Also it
makes naming a bit easier, e.g. the c++ version of BLI_task_isolate could
become blender::threading::isolate_task or something similar.
Differential Revision: https://developer.blender.org/D11624
Used to detect if a shaderfx is purely local, or comes from linked data,
in case of a liboverride.
Not actually used yet since we do not currently support adding
shaderfx's to overrides, but will be in the future, and matches
constraints and modifiers code.
