Move the `ME_SHARP` flag for mesh edges to a generic boolean
attribute. This will help allow changing mesh edges to just a pair
of integers, giving performance improvements. In the future it could
also give benefits for normal calculation, which could more easily
check if all or no edges are marked sharp, which is helpful considering
the plans in T93551.
The attribute is generally only allocated when it's necessary. When
leaving edit mode, it will only be created if an edge is marked sharp.
The data can be edited with geometry nodes just like a regular edge
domain boolean attribute.
The attribute is named `sharp_edge`, aiming to reflect the similar
`select_edge` naming and to allow a future `sharp_face` name in
a separate commit.
Ref T95966
Differential Revision: https://developer.blender.org/D16921
An apostrophe should not be used because it is not a mark of plural,
even for initialisms. This involves mostly comments, but a few UI
messages are affected as well.
Differential Revision: https://developer.blender.org/D16749
This property was intended to keep the snap elements synchronized with the scene.
But another solution exists.
And this property is not even working correctly.
This patch is a response to T101313.
Adds a selection to the Store Named Attribute node.
If the attribute does not exist unselected parts
are filled with zero values. Otherwise, only the
selected parts are filled.
Differential Revision: https://developer.blender.org/D16237
It was introduced in commit https://developer.blender.org/rB0fb12a9c2ebc
The problem was that the tool uses the same values for all modes,
but the new calculation must be only for Draw mode.
Now the mode is checked.
This is a mere "get this to compile in C++", didn't do changes like
using `MEM_cnew()` instead of `MEM_calloc()`.
Needed for the blender-project-basics branch, so I don't have to write C
wrappers for a single call from this file.
Caused by NULL dereference in strip overlap handling (expand to fit),
because `time_dependent_strips` strip collection is not created.
Check if strip collection is provided in `query_right_side_strips()`.
Updates the add and search menu of the node editor to use the new "All"
asset library introduced in the previous commit. This simplifies code by
removing redundant logic to merge contents of multiple asset libraries.
Adds a new built-in asset library that contains all other asset
libraries visible in the asset library selector menu. This also means
all their asset catalogs will be displayed as a single merged tree. The
asset catalogs are not editable, since this would require support for
writing multiple catalog definition files, which isn't there yet.
Often it's not relevant where an asset comes from. Users just want to be
able to get an asset quickly, comparable to how people use a search
engine to browse images or the web itself, instead of first going to a
dedicated platform. They don't want to bother with first choosing where
they want the result to come from.
This especially is needed for the Asset Shelf (T102879) that is being
developed for the brush assets project (T101895). With this, users will
have access to all their brushes efficiently from the 3D view, without
much browsing.
Did an informal review of the asset system bits with Sybren.
This patch uses the recorded drawing speed to rebuild the strokes. This results in a way more
natural feel of the animation.
Here's a short summary of existing data used:
- gps->points->time: This is a timestamp in seconds of when the point was created
since the creation of the stroke. It's quite often 0 (I added a sanitization routine).
- gpf->inittime: This is a timestamp in seconds when a stroke was drawn measured
since some unknown point in time. I only ever use the difference between two strokes,
so the absolute value is not relevant.
Reviewed By: frogstomp, antoniov, mendio
Differential Revision: https://developer.blender.org/D16759
When adding a new layer from the viewport, the newly created layer
is set as active, which is visible in the properties panel,
but the selection in the dopesheet was not updated accordingly,
due to a missing notifier which is added in this patch.
OpenGL is deprecated by Apple and triggers a warning when used. The goal
is that OpenGL is replaced by Metal backend, but we are not there yet.
To improve tracability of new warnings we hide deprecation warnings
when the GHOST_ContextCGL.h file is included.
NOTE: This change silences other deprecation warnings as well.
Using run-time members in the surface modifier complicated code-review
and caused an unnecessary renaming in `dna_rename_defs.h`.
Also rename:
- `x` -> `vert_positions_prev`.
- `v` -> `vert_velocities`.
- `cfra` -> `cfra_prev`.
The mesh positions are now a span, but the convex hull didn't copy
the custom data layout to the new mesh since it assumed it didn't
need to. Moving UV maps to a generic attribute triggers this difference
in the test results.
It doesn't really make sense for the convex hull node to copy the
source mesh custom data layout at all anyway, but do it anyway
to avoid having to change the tests right now.
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
Edit-mesh duplicator logic used a struct member vert_coords which read
as an alternative (and inconsistent) naming to vert_positions.
Rename to `vert_positions_deform` as the purpose of this value is to
assign when modifiers deform an edit-mesh.
Add `_deform` suffix to normals as well.
Use font's OS/2 table code page range bits to help differentiate
between Korean, Japanese, Simplified & Traditional Chinese fonts.
See D16484 for details.
Differential Revision: https://developer.blender.org/D16484
Reviewed by Brecht Van Lommel
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
Since internal links are only runtime data, we have the flexibility to
allocating every link individually. Instead we can store links directly
in the node runtime vector. This allows avoiding many small allocations
when copying and changing node trees.
In the future we could use a smaller type like a pair of sockets
instead of `bNodeLink` to save memory.
Differential Revision: https://developer.blender.org/D16960
activeSnap --> transform_snap_is_active
activeSnap_SnappingIndividual --> transform_snap_project_individual_is_active
activeSnap_SnappingAsGroup --> transform_snap_mixed_is_active
applySnappingIndividual --> transform_snap_project_individual_apply
applySnappingAsGroup --> transform_snap_mixed_apply
Also rearrange functions to be close to where they are used.
And use static when possible.
- Avoid calling node interface items "sockets"
- Use "active" instead of "current" to be more correct
- Avoid using the same word in description and name
- A couple grammar fixes
- Matrix normalize overloads needs to have the vector normalize redefined.
- double underscore (anywhere in symbol name) are reserved.
- Some operation yield different result due to float imprecision. Increasing
epsilon threshold for the failing tests.
Incorrect offset was calculated when strip was implicitly retimed (movie
FPS does not match scene FPS). This is because strip playback rate was
not used for offset calculation at all.
Since hold offset is specifying numbers of frames to skip, but at frame
rate of the source, this could result in gap when splitting the strip.
If that occurs, gap is compensated by moving handle to frame where strip
is split.
Happens, for example, when the object has animation, and disabled for
render, and animation render is performed.
The regression has been uncovered by f12f7800c2 which made it so
the dependency graph relies on runtime visibility tracking and
updates (without updating relations).
The optimization from a while ago in the ff60dd8b18 got in a way
of the visibilit updates because it removed relation between two
no-op nodes which belong to different IDs, which make the visibility
tracking impossible.
This change makes it so only relations which belong to the same
component are removed. This matches the expectations of the visibility
tracking (which, actually, also needed to happen at the moment of the
initial optimization commit). Technically, this change could introduce
some performance regression, but with the current design design of the
graph it is not really avoidable.
The idea to gain the best performance is to separate relations which
actually define the execution flow, and which are only needed to
define things like visibility dependencies.
When drawing using the option `Outline` the result stroke
was not using the Vertex Color option and always was converted
using material.
Now the vertex color option is used.
Crash only occured when textures was stored in a gray scale GPU
texture and was scaled down to fit inside the given limitation.
In this case the original number of pixels were packed into the
GPU buffer, not taken into account the scaled down image. This
resulted in a buffer overflow.
The bug is caused by rBb66b3f547c43e841a7d5da0ecb2c911628339f56.
From what I can see, that fix was intended to enable manual lens shift for
panorama cameras, but it appears that it also unintentionally applies
interocular shift.
This fix disables the multiview shift for panorama cameras, that way manual lens
shift still works but we get the 2.x behavior for stereoscopic renders back.
Differential Revision: https://developer.blender.org/D16950
Do not clear all the font's glyph caches with single-step zoom
operators if the area does not change font size when doing so.
See D16785 for more details.
Differential Revision: https://developer.blender.org/D16785
Reviewed by Campbell Barton
