| Age | Commit message (Collapse) | Author |
|---|
|
Some minor improvements to doc-strings too.
Ref T92709
|
|
Correct assert for edit-mesh normal calculation.
|
|
The first loop was left out when finding the split edge boundary.
Error from f2138686d9d8c105ebf8884774fd7e4d8ff239a1.
|
|
|
|
Use a counter for loop indices as they're being iterated in order.
|
|
|
|
Storing and restoring custom normals was broken by
39b2a7bb7e815e051348bf5c5ec777d091324164
This also caused "Sharp Edge" option for Weld by Distance to fail,
reported as T92875.
|
|
|
|
Ensure the layers from the source mesh are used instead of the
object referenced by the boolean modifier.
|
|
Reference struct members by name instead relying on their order.
This also simplifies moving back to named members when all compilers
we use support them.
|
|
|
|
In rare cases disolving faces would crash, caused by iterator
variable reuse in b29a8a5dfe3d6eb2fbbdecd0d5dffb3d709b9b91.
|
|
|
|
|
|
|
|
A previous commit, c56526d8b68ab, which sometimes didn't drop offsets
into 'in plane' faces, as a fix to T71329, was overly aggressive.
If all the intermediate edges are in the same plane then it is fine
to just put the meeting point on the plane of the start and end edges.
|
|
|
|
`v_other` -> `v_step`
|
|
Sometimes the `use_partial_connect` option could trigger the assert:
```
BLI_assert(!BM_elem_flag_test(l_iter->v, VERT_NOT_IN_STACK));
```
This can happen when `v_delimit->e` is not part of edgenet, so `v_other` will not have the flag.
|
|
|
|
Creating some primitives allows for a scale value (via python) that will
scale the object accordingly. For objects with a radius parameter
(like cylinders, spheres, etc.) passing a scale different to (1,1,1)
would result in unexpected behavior.
For example:
`>>> bpy.ops.mesh.primitive_uv_sphere_add(radius=2, scale=(1,1,2))`
We would expect this to create a sphere with a radius of 2
(dimensions 4,4,4) and then be scaled *2 along the z-axis
(dimensions 4,4,8). But this would previously create a scaled sphere
with dimensions (2,2,4).
The scale was simply divided by two. Maybe because the "radius"
parameter for creating the primitives was confusingly named "diameter"
(but used as the radius).
The fix adds a scale parameter to `ED_object_new_primitive_matrix`
and also renames the wrongly named "diameter" parameters to "radius".
Reviewed By: campbellbarton
Maniphest Tasks: T84638
Ref D10093
|
|
This changes the search for unprocessed faces to only search
from the previously found face. Local testing on 1.5 million
triangle meshes gives a 75x speedup
(of the code affected, which is the first half of the work).
The former code would traverse all faces of a mesh until a face was
found that had not been processed. This ended up being slow mainly
because it had to load face-data to determine the state of the flag.
Secondarily, the way it iterated and marked the mesh, it would end up
traversing all previously processed faces to find and unprocessed one.
The same optimization has been made for edge-group calculation.
Reviewed By: campbellbarton
Ref D12379
|
|
|
|
Use an assert since this should never happen.
|
|
This reverts commit 41e650981861c2f18ab0548e18851d1d761066ff.
This broke "CubeMaskFirst" test.
Any value even slightly outside the [-1.0..1.0] range
caused the result to be nan, which can happen when calculating
the dot-product between two unit length vectors.
|
|
The clamped version of acos isn't needed as degenerate (nan) coordinates
result in zeroed vectors which don't need clamping.
|
|
Caused by fix for T90256 and a misunderstanding in D11928.
Don't skip tagging edges when the auto-smooth angle is 180 degrees
since this skips topology checks which are needed for properly
calculating edge loop normals.
|
|
Follow the same logic already used by the modifier.
|
|
Also remove redundant fabsf on the area of a quad/tri &
reduce indentation using continue in for loop.
|
|
Only vertex indices were ensured to be correct.
|
|
Vertices with no connected faces would attempt to divide by the combined
face area causing a divide by zero.
Use the same weight for wire vertices as vertices connected
to zero area faces.
|
|
Regression in 39b2a7bb7e815e051348bf5c5ec777d091324164.
|
|
This makes the internal naming consistent with the public API. And also gives
us a visibility_flag rather than restrictflag that can be extended with more
flags.
|
|
Error in 39b2a7bb7e815e051348bf5c5ec777d091324164
which failed to set edge flags with single threaded calculation,
used for low poly models.
|
|
|
|
|
|
Regression in 39b2a7bb7e815e051348bf5c5ec777d091324164
that meant non-manifold edges were not being tagged
when they should have been.
|
|
This BMesh iterator hadn't been used in C++ code yet, and needed
a macro for a proper cast. The parameter structs need to be initialized
when declared without designated initializers.
|
|
|
|
|
|
Six years ago, Bug T44961 about unwanted spikes had me not do a loop
slide if the angle was too extreme, to avoid unwanted spikes.
The current bug showed that that angle was much too big, and limited
desired behavior in many cases. Changing the angle from 0.25 radians
to 0.0001 radians (about 0.006 degrees) still fixes the original bug
and seems very unlikely to be limiting desired behavior now.
|
|
|
|
Share functionality for single and multi-threaded edge-split tagging.
Remove logic that ensured vert & loop indices in bm_mesh_edges_sharp_tag
(missing from fd9fc809b76d625a1ead6e1fbe5e486cc012f5f3).
|
|
The only difference with BM_loops_calc_normal_vcos was passing in
custom coordinates which may be NULL.
|
|
bm_mesh_edges_sharp_tag was called with setting sharp edges enabled.
Error in 39b2a7bb7e815e051348bf5c5ec777d091324164.
|
|
This was added in 0b7f5813973c515b84cd7c18ef6d7d1e59374237
but seems not to be needed as the assignment was never correct
since only one corner on either side of the smooth edge had the
vertex normal written to it.
|
|
Merge the sharp edge tagging into bm_mesh_loops_calc_normals,
this has the advantage that edge tagging can be performed as part of
walking over each vertices edges - instead of tagging in a separate loop.
Even though this will tag edges twice (once for each vertex),
the computation isn't heavy as it's only calculating a dot-product
between the two face users to compare the angle.
This change combined with 4ba06ad0a8cdec66d9a9cb06f982736d46c40f4c
makes BM_loops_calc_normal_vcos around 5.68x faster,
with an overall speedup over 2.6x when transforming a high poly mesh.
(tested on a system with 32 cores).
Reviewed By: mont29
Ref D11970
|
|
Supported multi-threading for bm_mesh_loops_calc_normals.
This is done by operating on vertex-loops instead of face-loops.
Single threaded operation still loops over faces since iterating
over vertices adds some overhead in the case of custom-normals
as the order used for accessing loops must be the same as iterating
of a faces loops.
From isolated timing tests of bm_mesh_loops_calc_normals on high
poly models, this gives between 3.5x to 10x speedup,
with larger gains for meshes with custom-normals.
NOTE: this is part one of two patches for multi-threaded auto-smooth,
tagging edges as sharp is still single threaded.
Reviewed By: mont29
Ref D11928
|
|
While doxygen supports both, conform to our style guide.
Note that single back-tick's are already used in a majority of comments.
|
|
|
