8e967cfeaf only meant to tag the "verts no face" cache
calculated eagerly if both loose edges and loose verts were already
calculated. Instead it caused the calculation of one of the caches.
Similar to the cache of loose edges added in 1ea169d90e,
cache the number of loose vertices and which are loose in a bit map.
This can save significant time when drawing large meshes in the
viewport, because recalculations can be avoided when the data doesn't
change, and because many geometry nodes set the loose geometry
caches eagerly when the meshes contain no loose elements.
There are two types of loose vertices:
1. Vertices not used by any edges or faces
`Mesh.loose_verts()`
2. Vertices not used by any faces (may be used by loose edges)
`Mesh.verts_no_face()`
Because both are used by Blender in various places, because the cost
is only a bit per vertex (or constant at best) and for design consistency,
we cache both types of loose elements. The bit maps will only be
allocated when they're actually used, but they are already accessed
in a few important places:
- Attribute domain interpolation
- Subdivision surface modifier
- Viewport drawing
Just skipping viewport drawing calculation after certain geometry
nodes setups can have a large impact. Here is the time taken by
viewport loose geometry extraction before and after the change:
- 4 million vertex grid node: 28 ms to 0 ms
- Large molecular nodes setup (curve to mesh node): 104 ms to 0 ms
- Realize instances with 1 million cubes: 131 ms to 0 ms
Pull Request: https://projects.blender.org/blender/blender/pulls/105567
The node outputs the index of the closest element to itself. See #102387
for the original design.
This is different from the Sample Nearest node in two important ways:
* It does not have a geometry input, instead the geometry is taken from the
field evaluation context.
* The node can exclude the "current" element from the search.
* The group id input can be used to build subsets of elements that only
consider each other as neighbors and ignore elements with other ids.
Pull Request: https://projects.blender.org/blender/blender/pulls/104619
An operator to allow interactive text selection for 3D Text Objects.
This is from the code of Yash Dabhade (yashdabhade) for GSoC 2022
with corrections and simplifications. Also includes double-click for
word selection.
Pull Request: https://projects.blender.org/blender/blender/pulls/106915
This patch contains changes needed for retiming sound strips.
`BKE_sound_set_scene_sound_pitch()` is replaced by
`BKE_sound_set_scene_sound_pitch_constant_range()` which uses new
Audaspace interface to set pitch in bulk.
This is done in `SEQ_retiming_sound_animation_data_set()` where retimed
sections are created for each strip. When strip is inside of meta
strip(s), the retimed sections of meta and actual strip are split where
they intersect and pitch is multiplied where they overlap. Each section
will have pitch value that is provided to audaspace.
Waveform overlay now represents retimed audio accurately.
Ref: #100337
Pull Request: https://projects.blender.org/blender/blender/pulls/105072
The result of detecting if a quad should flip the default 0-2 split
when tessellated only used a pre-calculated normal when available,
since the method of detecting the flip was different, the check for a
concave face could change depending on the existence of polygon-normals.
In practice this meant cycles render preview could use a different
tessellation than the GPU display.
While [0] exposed the bug, it's an inherent problem with having 2
methods of detecting concave quads.
Remove is_quad_flip_v3_first_third_fast_with_normal(..) and always
use is_quad_flip_v3_first_third_fast(..), because having to calculate
the normal inline has significant overhead.
Note that "bow-tie" quads may now render with a subdivision in a
different direction although they must be very distorted with both
triangles along the 0-2 split pointing away from each other.
Thanks to @HooglyBoogly for investigating the issue.
[0]: 16fbadde36.
Generally, one does not know if the sharing info is currently shared
and should therefore be const. Better keep it const almost all the
time and only remove the constness when absolutely necessary
and the code has checked that it is valid.
This patch adds several tools and options to the weight paint mode of Grease Pencil.
* Blur tool: smooths out vertex weights, by calculating a gaussian blur of adjacent vertices.
* Average tool: painting the average weight from all weights under the brush.
* Smear tool: smudges weights by grabbing the weights under the brush and 'dragging' them.
* With the + and - icons in the toolbar, the user can easily switch between adding and subtracting weight while drawing weights.
* With shortcut `D` you can toggle between these two.
* The auto-normalize options ensures that all bone-deforming vertex groups add up to 1.0 while weight painting.
* With `Ctrl-F` a radial control for weight is invoked (in addition to the radial controls for brush size and strength).
* With `Ctrl-RMB` the user can sample the weight. This sets the brush Weight from the weight under the cursor.
* When painting weights in vertex groups for bones, the user can quickly switch to another vertex group by clicking on a bone with `Ctrl-LMB`.
For this to work, follow these steps:
* Select the armature and switch to Pose Mode.
* Select your Grease Pencil object and switch immediately to Weight Paint Mode.
* Select a bone in the armature with `Ctrl-LMB`. The corresponding vertex group is automatically activated.
Pull Request: https://projects.blender.org/blender/blender/pulls/106663
The comment didn't really make sense, since the removed code did the
same thing as the CustomData function anyway, and that's already done
in `mesh_init_data`.
The file extension was copied into a buffer without checking it's size.
While large extensions aren't typical, some callers used small fixed
size buffers so an unusually named file could crash.
Runtime this information is stored in the active_color_attribute and
default_color_attribute strings on the mesh, however when saving it
is still saved in the old format with flags on the CustomData layers.
When converting from the strings to the layers not all flags were
properly cleared from the CustomData layers, leading to multiple
layers having the CD_FLAG_COLOR_ACTIVE/RENDER flag.
Implicit sharing means attribute ownership is shared between geometry
data-blocks, and the sharing happens automatically. So it's unnecessary
to choose whether to enable it when copying a mesh.
The typical order is vertex, edge, face(polygon), corner(loop), but in
these three functions polys and loops were reversed. Also use more
typical "num" variable names rather than "len"
Before the add node search refactor and link-drag-search, nodes were
filtered out based on whether they worked with the active render
engine. For example, the Principled Hair BSDF node doesn't work with
EEVEE, so it isn't displayed in the UI. While we might want to relax
this in the future, we have no better way to show that they don't work
right now, so it's best to keep that behavior.
The filtering is implemented with a new node type callback, mainly
to reduce the boilerplate of implementing many node search callbacks
otherwise. It's also relatively clear this way I think. The only
downside is that now there are three poll functions.
I didn't port the "eevee_cycles_shader_nodes_poll" to the new
searches, since I don't understand the purpose of it.
Pull Request: https://projects.blender.org/blender/blender/pulls/106829
Change the "displist to mesh" conversion to use the edge calculation
function used everywhere else, to allow removing the old code. This
changes edge vertex and corner edge indices, requiring a test update,
but the visual result should be the same.
Add the ability to retrieve implicit sharing info directly from the
C++ attribute API, which simplifies memory usage and performance
optimizations making use of it. This commit uses the additions to
the API to avoid copies in a few places:
- The "rest_position" attribute in the mesh modifier stack
- Instance on Points node
- Instances to points node
- Mesh to points node
- Points to vertices node
Many files are affected because in order to include the new information
in the API's returned data, I had to switch a bunch of types from
`VArray` to `AttributeReader`. This generally makes sense anyway, since
it allows retrieving the domain, which wasn't possible before in some
cases. I overloaded the `*` deference operator for some syntactic sugar
to avoid the (very ugly) `.varray` that would be necessary otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/107059
We don't use the callbacks that create virtual arrays from the custom data
anymore, they just add extra indirection. The only non-obvious case was
the crease attribute which had a setter function. Replace that with an
attribute validator like the other similar attributes.
Pull Request: https://projects.blender.org/blender/blender/pulls/107088
While embedded IDs are usually considered as private local data of their
owner ID, some areas of code, like the depsgraph, can consider them as
regular IDs in some aspects.
So when swapping IDs, also properly 'counter-swap' their potential
embedded IDs, such that the pointers to the embedded IDs remain as before
swapping, even though the data of the embedded IDs is swapped.
The main target of this change is memfile undo code. There, newly read
IDs are swapped with their oldder version, so that the old address
contains the new data. This allows to avoid rebuilding some of the
depsgraph. Doing the same thing for embedded IDs should reduce even
further the needs for depsgrah rebuilds on undo steps.
This commit also gives more control over the remapping of 'self' ID
pointers inside themselves.
Pull Request: https://projects.blender.org/blender/blender/pulls/107044
This is the first step for refactoring the lightcache system.
Each probe instance (as in `Object`) will now store its own baked data.
The data is currently stored in uncompressed readable format.
This introduces two new operators for baking to avoid confusion with
the previous light baking pipeline. These do nothing other than
creating empty caches that will be populated by EEVEE later on.
The DNA storage is made to be able to include multiple caches
in case of baked simulation over time but it isn't yet supported.
I prefer to keep the implementation simple for now as the long term
goals for this feature are uncertain.
There is still a type flag (`LightProbeObjectCache.cache_type`) that
will be used for versioning.
The naming convention of structs is a bit weird but that's all I
found in order to avoid interfering with the old scene light cache
that is still used by (old) EEVEE.
Related task #106449.
Pull Request: https://projects.blender.org/blender/blender/pulls/106808
This should not have much effective consequences with current code, but
fixes potential missed remappings for e.g. some nodetree pointers in the
node editor, or the `parent` pointer of collections to a scene's master
collection.
