When adding a shape key, set its blend value to 1.0 / 100%.
There is no practical use case where user wants to add shape key but
not work on it. New shape keys at value 0 have no purpose. Adding
shape key should be interpreted by Blender as user wanting to
sculpt/model on it. Also, being at 1.0 initially doesn't change
anything visually, because key isn't edited yet and it doesn't deform
mesh.
The default value of the shape key is also set to 1.0. When using
right-click to reset values, user most often wants to return to 1
(which is "correct" state of deformation without multiplication)
rather than 0 (which is no deformation at all).
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/133399
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135870
The general idea is to store an array of (type, data) pointers of all
PointerRNA ancestors of the current one.
This will help solving cases in our code where the owner (or sometimes
even the owner of the owner) of a random PointerRNA needs to be
accessed. Current solution mainly relies on linear search from the owner
ID, which is sub-optimal at best, and may not even be possible in case a
same data is shared between different owners.
This lead to refactoring quite a bit of existing PointerRNA creation code.
At a high level (i.e. expected usages outside of RNA internals):
* Add `RNA_pointer_create_with_parent` and
`RNA_pointer_create_id_subdata` to create RNA pointers with
ancestors info.
* `RNA_id_pointer_create` and `RNA_main_pointer_create` remain
unchanged, as they should never have ancestors currently.
* Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer
from the nth ancestor of another PointerRNA.
* Add basic python API to access this new ancestors data.
* Update internal RNA/bpy code to handle ancestors generation in most
common generic cases.
- The most verbose change here is for collection code, as the owner of the
collection property is now passed around, to allow collection items to get
a valid ancestors chain.
Internally:
* `PointerRNA` now has an array of `AncestorPointerRNA` data to store
the ancestors.
* `PointerRNA` now has constructors that take care of setting its data for
most usual cases, including handling of the ancestor array data.
* Pointer type refining has been fully factorized into a small utils,
`rna_pointer_refine`, that is now used from all code doing that operation.
* `rna_pointer_inherit_refine` has been replaced by
`rna_pointer_create_with_ancestors` as the core function taking care of
creating pointers with valid ancestors info.
- Its usage outside of `rna_access` has been essentially reduced to custom
collection lookup callbacks.
Implements #122431.
--------------
Some notes:
* The goal of this commit is _not_ to fully cover all cases creating
PointerRNA that should also store the ancestors' chain info. It only
tackles the most generic code paths (in bpyrna and RNA itself mainly).
The remaining 'missing cases' can be tackle later, as needs be.
* Performances seem to be only marginally affected currently.
* Currently `AncestorPointerRNA` only stores PointerRNA-like data.
This will help `StructPathFunc` callbacks to more efficiently generate
an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will
not be enough info to build these paths without these callbacks. And some
cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA`
pointer, and for RNA collection ones, an index and string identifier, to store
a complete unambiguous 'RNA path' info. This is probably not needed, nor
worth the extra processing and memory footprint, for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122427
This commit mainly replaces a lot of `memset(0)` by empty value
initialization of `PointerRNA` and related data.
It also moves a few remaining areas from C alloc/free to C++ new/delete
memory hanlding.
Part of the effort to make PointerRNA non-trivial (#122431).
We are now wanting tooltip descriptions to not include a terminal
period unless they are multi-sentence (so internally containing a
period). #125460 removed the automatic addition of the terminal period,
but now we have to manually add them back where needed. This PR removes
the error message shown if these items end in period, and then adds one
for all RNA descriptions that are multi-sentence.
Pull Request: https://projects.blender.org/blender/blender/pulls/125507
- "can not" -> "cannot" in many places (ambiguous, also see
Writing Style guide).
- "Bezier" -> "Bézier": proper spelling of the eponym.
- Tool keymaps: make "Uv" all caps.
- "FFMPEG" -> "FFmpeg" (official spelling)
- Use MULTIPLICATION SIGN U+00D7 instead of MULTIPLICATION X U+2715.
- "LClick" -> "LMB", "RClick" -> "RMB": this convention is used
everywhere else.
- "Save rendered the image..." -> "Save the rendered image...": typo.
- "Preserve Current retiming": title case for property.
- Bend status message: punctuation.
- "... class used to define the panel" -> "header": copy-paste error.
- "... class used to define the menu" -> "asset": copy-paste error.
- "Lights user to display objects..." -> "Lights used...": typo.
- "-setaudio require one argument" -> "requires": typo.
Some issues reported by Joan Pujolar and Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/117856
Use an optional string instead of a manually allocated char pointer.
Optional is used because sometimes `nullptr` was returned. It's
still inconsistent though, because often "" or ".." was returned
instead.
Mesh shape key data elements are always of the `ShapeKeyPoint` type and
only have a `.co` property which is stored contiguously. However, the
`.data` collection property's elements are dynamically typed because
Legacy Curve shape key data elements use a mix of `ShapeKeyCurvePoint`
and `ShapeKeyBezierPoint` elements. The necessary support for handling
the dynamic/mixed typing of the shape key data elements disables raw
access to the collection and its elements which makes `foreach_get`/
`foreach_set` slower.
`ShapeKey.points` is a new collection property whose element type is
fixed as `ShapeKeyPoint` and uses the `#rna_iterator_array_next` and
`#rna_iterator_array_get` collection functions which enable raw access
to the collection.
To complete the raw access to Mesh shape key data, the `.co` property of
`ShapeKeyPoint` also needs raw access. To accomplish this, the RNA
definition for `ShapeKeyPoint` now uses the `#vec3f` DNA struct and its
`.co` property is set to start from the `x` field of the `#vec3f` DNA
struct.
Lattice shape keys also use `ShapeKeyPoint` and also benefit from using
`.points` instead of `.data`, though Lattice objects typically have far
fewer data, such that performance is of minimal concern.
On shape keys belonging to Legacy Curves (`bpy.types.Curve`/
`bpy.types.SurfaceCurve`), `.points` will simply always be empty because
they do not have `ShapeKeyPoint` elements.
---
**Performance**
The increase in performance is specifically for foreach_get/foreach_set,
there is no noticeable performance difference to iterating through or
accessing individual elements of `.points` directly through Python, e.g.
`.points[0].co` vs `.data[0].co`.
`foreach_get` with a Python list is about 2.8 times faster.
`foreach_get` with an incompatible buffer (NumPy ndarray with np.double
dtype) is about 1.4 times faster.
`foreach_get` with a compatible buffer now scales better with larger
collections, so it is about 11.7 times faster at 100 elements and about
200.0 times faster at 100000 elements, dropping off to about 65 times faster for much larger collections.
The increase in `foreach_set` performance is slightly better than in
each `foreach_get` case, but scales the same overall.
`foreach_set` with a Python list is about 3.8 times faster.
`foreach_set` with an incompatible buffer (NumPy ndarray with np.double
dtype) is about 1.45 times faster.
`foreach_set` with a compatible buffer now scales better with larger
collections, so it is about 13.4 times faster at 100 elements and about
220.0 times faster at 100000 elements, dropping off to about 70 times faster for much larger collections.
The performance drop-off might be to do with hardware/OS specifics of `memcpy`. The drop-off occurs for me on Windows 10 with my AMD Ryzen 7 3800X at just above 1.5MiB of data copied (1572888B copied -> 200x faster, 1572900B copied -> 75x faster).
Pull Request: https://projects.blender.org/blender/blender/pulls/116637
It is very common for graphical editors with layers to support
locking individual layers to protect them from accidental edits due
to misclicks. Blender itself already supports locking vertex groups.
This adds lock toggles for shape keys, with lock/unlock all operators.
The flags are checked by sculpt brushes, edit mode transform tools,
and Smooth, Propagate and Blend From Shape operators. This selection
aims to cover operations that only deform the mesh, where the shape
key selection matters.
Topology changing operations always apply to all keys, and thus
incorrect shape key selection is less impactful. Excluding them
from the new feature greatly reduces the patch size.
Pull Request: https://projects.blender.org/blender/blender/pulls/104463
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Use const arguments for array input arguments as there
is no reason for them to be modified.
Using non-const arguments meant some functions
(uiTemplateNodeSocket for e.g.) couldn't use 'const' qualifier so the
generated type signature would match.
Also use suffix "_num" instead of "_len" for array lengths, ordering
these arguments after the array (in keeping with Blender's conventions).
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
