Smoothing vertices with symmetry wasn't recalculating normals
before re-tessellating, meaning the faces would use an incorrect
2D projection for tessellation.
The error was exposed by an assert.
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
The existing behavior of the grid fill operator requires a loop of
boundary or wire edges to be selected. This algorithm tries to fit a
grid of quads into the edge loop. It also works if you select two of the
four 'rails' of an edge loop.
This new behavior allows running grid fill after selecting faces.
If the algorithm sees that a set of faces are selected, it separates
all the faces, and then attempts to grid from their exterior boundary
using the exact same logic it normally uses for interior boundaries.
This all assumes the user has selected a set of faces with an outside
border that works with grid fill. (has one clear exterior loop with an
even number of edges) If not, grid fill will halt, and notify the user
of the error, exactly the way that it already did before.
Once the grid fill is complete and successful,
the existing faces which were replaced get deleted.
UVs (including at UV island boundaries) are interpolated properly,
as are custom-data on verts, edges, faces, and face corners.
At the edges of the selection, the edges/faces/face corners that are
selected contribute, but the custom-data outside the selection does not.
This also resolves non-deterministic behavior.
The previous behavior of `edbm_grid_fill_prepare` found the vertex with
the largest angle, then walked the edge loop until it found one out of
the three best remaining corners. This established one edge of the grid
area, and the second edge was found by symmetry.
However, the direction that the algorithm walked the loop
(and therefore which second corner was found) was essentially arbitrary.
The new behavior first finds the vert with the largest angle,
then finds the vert with the second largest angle,
(after excluding the diagonally opposite corner from the first vert),
and selects the edge between those two verts.
Ref !129318.
When displaying keymaps on the Status Bar we prefer to show Confirm and
then Cancel. We have a few places where these are reversed
accidentally. This just makes these consistent with the rest.
Pull Request: https://projects.blender.org/blender/blender/pulls/133947
Mesh Edit Mode / Mesh Menu / Normals / Point to Target... operator
shows keymap entries on the area header and in the status bar. This PR
removes the area header drawing and improves the Status bar using the
current pattern, including showing statuses with reversed items.
Pull Request: https://projects.blender.org/blender/blender/pulls/131586
- In the context of mesh extrusion, "Fill" means "Fill the rim of an
extruded edge loop" (verb).
- In the context of the file browser, it means select every file
between beginning and end.
- In the context of an image, fill the tile with generated image.
Issue reported by Hoang Duy Tran.
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
Move `CD_CUSTOMLOOPNORMAL` to the newly added
`CD_PROP_INT16_2D` generic attribute type. This is similar to
previous commits moving specific custom data types.
The attribute name is `custom_normal`. When the attribute with
that name is on the face corner domain, the code will interpret it
as stored in the existing deformation-invariant spherical coordinate
space.
The API remains the same, with the additional opportunity to edit
custom normal data as an attribute directly (which admittedly is fairly
unintuitive currently).
See #130484.
Pull Request: https://projects.blender.org/blender/blender/pulls/130689
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
A new parameter, topology influence, is added that causes the
join_triangles operator to prioritize edge joins that create quads with
sensible geometry relative to existing quads, instead of selecting the
'flattest' and 'squarest' next pair and then leaving leftover triangles
with no partners to merge with.
This produces its best results with the face and shape thresholds set to
180 degrees (no hard limits as a restriction against merging) and
topology influence somewhere between 100-130%, depending on the mesh.
Too low and many parallelograms and triangles are left, too high and the
algorithm tries too hard and starts making errors.
Note that both quads already present in the selection, as well as the
quads that are generated during the operator, will influence the
topology around them. This allows the modeler to manually merge a few
quads in key areas of the mesh, as a hint to the algorithm, indicating
what result they way they want to see, and the algorithm will then take
those quads into account and try to build around them according to the
modeler's guidance.
A new checkbox to leave only the remaining triangles selected has also
been added. This helps users visualize what remains to be fixed.
Ref !128610
Bridge could delete all faces & then fail to perform the bridge
operation. In this case the mesh was still modified.
Resolve by tracking the changed state, run updates when any changes are
made.
This reverts commit f3c32a36bc and the two followups.
The commit caused issues with both the operator and the modifier.
The operator could be fixed, for the modifier this needs deeper
investigation (see #124836 for a bit more info on this).
Until a better solution is found it is just better to go back to
previous behavior.
Reintroduces #103562 for now
Pull Request: https://projects.blender.org/blender/blender/pulls/125499
This got superseeded by the "super knife" in 421823e34e 14 years ago
it seems, it cannot be executed atm. (and even if reactivated, it
crashes in multiple places).
Stumbled over this while checking on usages of
#BM_custom_loop_normals_to_vector_layer /
#BM_custom_loop_normals_from_vector_layer (to add this to more tools),
and apparently this outdated piece of code got an update in 93c8955a72
:) -- work on adding this to our "real" Knife is upcoming in another
PR...
Pull Request: https://projects.blender.org/blender/blender/pulls/124970
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
The attribute API defined in `attribute.cc` was dependent on
the assumption that `ID`s are always the "direct" owners of attributes.
For Grease Pencil drawings, this is not the case. The Grease Pencil ID
stores the attributes for layers, and the attributes for drawings are stored
in `CurvesGeometry` on the drawings themselves.
In order to make use of `rna_attribute.cc`, we need that API to handle
other types of attribute owners.
This adds an `AttributeOwner` which is basically just a type and a
pointer. We replace the `ID` pointers and pass `AttributeOwner`s instead.
For cases where we have to do a switch based on the type, all the
types are handled and the `default` statment is left out. This ensures
that we get a compiler warning when a new `AttributeOwnerType`
is added.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122765
`BM_mesh_triangulate` is used in exporters (when the "Triangulate"
option is ON), the `Triangulate` modifier and currently also in the
`Triangulate` geometry node (even though there are plans to change this,
see !112264)
So in practice, exporters (Alembic/FBX/OBJ/Collada) were breaking
custom normals for game pipelines (unless everything was triangulated
beforehand).
This change builds upon 93c8955a72 (uses the use
`BM_custom_loop_normals_to_vector_layer` /
`BM_custom_loop_normals_from_vector_layer` pair of calls).
In the case of the `Triangulate` modifier, this had its own try at
preserving custom normals in 7d0fcaa69a -- doing very similar
things but as an option -- this is now removed (so it is always done,
which fits into "interpolate custom data if it's there" design that we have
nowadays).
NOTE: the "Triangulate Faces" operator already did the same
Pull Request: https://projects.blender.org/blender/blender/pulls/121871
`Weight` & `Threshold` sliders should **not** show in case of `Type` :
`Custom Normal` and **should** show for both `Type` : `Face Area` &
`Type` : `Corner Angle`
In code, it looks like we are gathering `loop_weight` with `val`.
- this is always 1.0 for `EDBM_CLNOR_AVERAGE_LOOP`
- this is taken from `BM_face_calc_area` for
`EDBM_CLNOR_AVERAGE_FACE_AREA`
- this is taken from `BM_loop_calc_face_angle` for
`EDBM_CLNOR_AVERAGE_ANGLE`
Code then compares not equal those values with given threshold, but for
`EDBM_CLNOR_AVERAGE_LOOP` this will never trigger (since all values are
the same), thus `count` is always zero which makes the effective
`n_weight` always 1. So all loop split normals are averaged for a vertex
with the same weight (seems to make sense to me -- at is just plain
average)
Long story short: the condition to show `Weight` & `Threshold` sliders
is just flipped (these only apply for the methods that take neighbor
faces into account).
Pull Request: https://projects.blender.org/blender/blender/pulls/121864
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
- "Log Encoding with Chroma inset and rotation": add "of primaries" in
the description of the AgX Log color space to better explain the
operation, based on wording in !106355.
- Remove a few double spaces.
- Make Line Art title case everywhere, to convey it's the system /
brand / product name and not the generic concept.
- "Copy Absolute coordinates or Normal vector" -> "of Normal Vector":
typo.
- "Makes a link between selected output in input sockets" ->
"Make...", "output and input": typo.
- "Purge Unused Data From This File" -> "from this": title case as per
HIGs.
- GPencil -> Grease Pencil: no reason to use an abbreviation here.
- "Around Current Frame" -> "Around Frame": actual name of the
onion-skinning method.
- "... (layer height for layer tool, i.e.)" -> "(i.e. the layer height
for the layer tool)": put "i.e." at the start of the sentence.
- Expand description of toe-in stereo camera option.
- "Children collections their parent-collection-specific settings" ->
"Children collections with their...": typo.
- "Generate vertex weights base on..." -> "based on" : typo, lower
case.
- Expand description of GP modifier properties, based on their mesh
counterparts.
- "AEnvelope" -> "Envelope": typo.
- "Falloff type the feather" -> "of the feather": typo.
- "usually make transition as long as effect strip": rephrase.
- "When disabled a users extensions directory is created" -> "a
user's": typo.
- "successfull" -> "successful": typo.
- "Remove all attributes... a single wildcard (*).": remove trailing
".".
- "..., use "Save Preferences."": remove trailing ".".
Some issues reported by Marina Veselkova and Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/120649
A couple of edit mesh operators are still using "VCols" terminology,
which should be Color Attributes now. This just renames text seen
in redo panels. Internally it's still called VCols.
Pull Request: https://projects.blender.org/blender/blender/pulls/120075
Move the public functions from the editors/object (`ED_object.hh`)
header to the `blender::ed::object` namespace, and move all of the
implementation files to the namespace too. This provides better code
completion, makes it easier to use other C++ code, removes unnecessary
redundancy and verbosity from local uses of public functions, and more
cleanly separates different modules.
See the diff in `ED_object.hh` for the main renaming changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119947
Fix the "Merge Vertices" report, replacing "vertice(s)" with either
"vertex" or "vertices". The singular "vertice" is not a word in English,
and thus the regular "append (s)" approach is incorrect.
Pull Request: https://projects.blender.org/blender/blender/pulls/119863
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
The main simplification is using return values rather than return
arguments, and the additional semantic clarity from std::optional.
Also use `fmt` for formatting and use lambdas instead of macros
as helpers in a few modal keymap formatting functions.
Similar commits:
- a1792e98a4
- f04bc75f8c
- 6abf43cef5
- 7ca4dcac5a
Pull Request: https://projects.blender.org/blender/blender/pulls/117785
Although the information displayed in the status bar is strictly
speaking reports, it makes sense to translate them using the Interface
setting instead of Reports, as the tool names and stats terms are
also translated in other UI places (toolbar, menus).
This change includes status bars statistics and keymaps, and viewport
statistics.
The change is quite extensive as it is all or nothing. Translating
keymaps using Interface means some status messages will include them
indirectly, and thus cannot use Reports without having a weird mix of
original and translated words. In turn, having only some messages
translated would be even more confusing.
The result is that all messages related to input are now translated with
Interface, which I think also makes sense.
Discussed as a followup to !116804.
-----
cc. @gtitaev
Pull Request: https://projects.blender.org/blender/blender/pulls/117234
This simplifies code using these functions because of RAII,
range based for loops, and the lack of output arguments.
Also pass object pointer array as a span in more cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/117482
