The main motivation for this is that it's part of a fix for #113377,
where I want to propagate the edit mesh pointers through copied
meshes in modifiers and geometry nodes, instead of just setting the
edit mesh pointer at the end of the modifier stack. That would have
two main benefits:
1. We avoid the need to write to the evaluated mesh, after evaluation
which means it can be shared directly among evaluated objects.
2. When an object's mesh is completely replaced by the mesh from another
object during evaluation (with the object info node), the final edit
mesh pointer will not be "wrong", allowing us to skip index-mapped
GPU data extraction.
Beyond that, using a shared pointer just makes things more automatic.
Handling of edit mesh data is already complicated enough, this way some
of the worry and complexity can be handled by RAII.
One thing to keep in mind is that the edit mesh's BMesh is still freed
manually with `EDBM_mesh_free_data` when leaving edit mode. I figured
that was a more conservative approach for now. Maybe eventually that
could be handled automatically with RAII too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120276
For example, creating the "position" attribute with the wrong name or type
could crash Blender when exiting edit mode. This is because some data isn't
stored as attributes in Blender, and the attribute API doesn't work very well
with BMesh.
Two parts to the solution:
- Remove builtin attributes with incorrect domains or names when
converting from BMesh to Mesh.
- Add error messages when creating builtin attributes in edit mode. It's still
possible to create name-convention attributes, because Blender should be
able to handle different types and domains for them.
Pull Request: https://projects.blender.org/blender/blender/pulls/119110
- "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
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.
Simplifies the code in this area, makes it work better with other C++
code. The max length argument isn't used anymore. But at that point we
wouldn't necessarily have a unique name anyway, which opens up for other
failures.
Remove most includes of this header inside other headers, to remove unnecessary
indirect includes which can have a impact on compile times. In the future we may
want more dedicated "_fwd.hh" headers, but until then, this sticks with the
solution in existing code.
Unfortunately it isn't yet possible to remove the include from `BKE_geometry_set.hh`.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
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
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
Problem here is that `BKE_id_attribute_to_index` [which
`BKE_id_attributes_active_set` uses] does not match
`BKE_id_attribute_from_index` which can lead to "wrong" indices (there
are "wrong" layers included while iterating such as ".corner_vert" or
".corner_edge" for faces).
Deeper reason is that `get_domains_types` swaps `ATTR_DOMAIN_FACE` and
`ATTR_DOMAIN_CORNER` (originally introduced in eae36be372 -- but unclear
at this point why this was done). Historically, this was used for operators
[vertex color rotate/inverse] introduced in c75e1598dd & 771a4dee0b,
assumption is that eae36be372 was trying to make this more generic and make
it work for other domains as well (ATTR_DOMAIN_MASK_COLOR -- the tootip
was also changed from "Rotate vertex colors inside faces" to "Rotate color
attributes inside faces"), however, at this point in time the tools clearly only work
for the corner domain (and this was made more specific in ee18b625ca as well).
So now, remove the swapping all together and make
`BKE_id_attribute_from_index` & `BKE_id_attribute_to_index` in sync.
Also change the tooltip of said operators to use "face corner color attribute".
Pull Request: https://projects.blender.org/blender/blender/pulls/114797
Extract:
- "Attribute", when creating a new attribute with
`GEOMETRY_OT_attribute_add()`: make the default name in the operator
a null string, and set it to "Attribute" translated inside an invoke
method instead.
- Also for new attributes, from `BKE_id_attribute_calc_unique_name()`,
for instance to create a default vertex color layer when going into
Vertex Paint mode: use `DATA_()` instead of `IFACE_()`, since it
represents user data.
Disambiguate:
- "Weight" can be the thickness of font glyphs.
- "Mark as Asset" and "Clear Asset" are operator names already
extracted using the Operator context. They were recently added to a
manual translation in the UI, but the existing one can be reused.
- "Second" as a time unit in the context of frame snapping.
Some messages reported by Satoshi Yamasaki in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/114159
When retrieving a color attribute to paint it, the layer data needs to
be unshared so that it doesn't modify data from separate meshes.
In the past I think we've unknowingly avoided this problem by porting
code to the new attribute API. I've been refactoring `PBVH` and
`SculptSession` to make that possible (removing the long-lived
layer pointers in the two structs). But that wouldn't fit as a bug fix.
In the meantime, make sure the color attribute data is un-shared
and separate "for read" and "for write" versions of the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114119
Their return value was only used in one place.
Change it to comparison with a stored name, and make the functions
to return void instead.
Removing the return boolean makes it possible to change underlying
functions to work with std::string and return unique name by value.
Pull Request: https://projects.blender.org/blender/blender/pulls/113934
We had a short discussion on this change. "Grease Pencil Layer" is
just a bit too long, especially in the UI. Even though "Layer" might be
ambiguous, it shouldn't be in the context of geometry nodes. There are
currently no other "Layers" and if there were, using the same domain
name could be fine (just like we reuse the point domain for e.g. vertices
in meshes and control points in curves).
This also renames the internal enum to `ATTR_DOMAIN_LAYER`
Pull Request: https://projects.blender.org/blender/blender/pulls/113589
This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
This was discussed in #112022 and on devtalk:
https://devtalk.blender.org/t/vertex-groups-generic-attributes-and-name-clashing/31073
While vertex groups with the same name as attributes should be avoided, since
it can cause ambiguities when using attributes, it's something we can handle
gracefully for now. Enforcing unique names for vertex groups resulted in breaking
other functionality under some circumstances.
This effectively reverts 12ef20990b, except for
the bug fix in `BKE_id_attribute_new`.
#112891 adds a warning to avoid make users aware of duplicate names so that they
can be avoided in practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/112889
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.
After 12ef20990b, attributes and vertex group names were checked
simultaneously to fix the name collision. But this results in crash when
new attribute is added to curve object (it searches for vertex group
list). To avoid the crash, check for supported id types in new function
`BKE_id_supports_vertex_groups`.
Pull Request: https://projects.blender.org/blender/blender/pulls/111036
These name collisions should be avoided with attributes, all sorts of
issues can arise from those. We already warned in the attributes
(but not the vertex groups) list if those were found.
Previously, creating a vertex group with the same name as an already
existing attribute would allow this (and give said warning), and creating
an attribute with the same name as an already existing vertex group
would silently fail (as in: not return a layer) -- and then due to an oversight
in 101d04f41f (which assumed a valid layer would always be returned
by `BKE_id_attribute_new`) would even crash.
Now name collisions between vertex groups and attributes are avoided,
unique names will be found across attributes and vertex groups if either
`BKE_id_attribute_calc_unique_name` or `BKE_object_defgroup_unique_name`
is called.
This is done by unifying the checks and callbacks for both into a single.
Pull Request: https://projects.blender.org/blender/blender/pulls/109910
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
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
Make it harder to retrieve a mutable attribute from const a const mesh,
and use the attribute search function to check multiple domains and
colors at once.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
A NULL defname would early exit (doing nothing) this isn't good behavior
as this function should always make the name unique and a NULL defname
is likely an error in the code which would allow duplicate names.
This is also inconsistent with BLI_uniquename_cb which always
wrote the defname into the name if it was empty.
Mark this argument as never-NULL.
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
