This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
This patch uses threading to flush selection from verts to edges and
from edges to faces. The solution is lockless and should scale well on
modern CPU architectures.
Master:{F10185359}
Patch:{F10185361}
End user performance went from 3.9 to 4.6 FPS (Stanford Dragon) but that
was measured on a Intel Core i7-6700 CPU and AMD RX480 Gpu. The more
cores the better improvements you get.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D11644
During selections the total selection is refreshed at the end. This
process was done single threaded. This patch will do a parallel iter
approach.
Master: 0.043612s Threaded 0.017964s.
Master: {F10179586}
This patch: {F10179587}
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D11622
This patch ensures that selection mode flushing updates total selection
counts internally. This reduces recounting when we are sure that the
input total selection counts were up to date.
For example for circle selection the total selection counts were
correct. But during flushing the selection could have been changed and
therefore the selection was always recounted.
This increased the performance on selected system from 6.90 FPS to 8.25
FPS during circle selection operations.
Before: {F10179981}
After: {F10179982}
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D11647
This matches BMesh which also has tessellation in it's own file.
Using a separate file helps with organization when
extracting code into smaller functions.
Support calculating face normals when tessellating. When this is done
before updating vertex normals it gives ~20% performance improvement.
Now vertex normal calculation only needs to perform a single pass on the
mesh vertices when called after tessellation.
Extended versions of normal & looptri update functions have been added:
- BM_mesh_calc_tessellation_ex
- BM_mesh_normals_update_ex
Most callers don't need to be aware of this detail by using:
- BKE_editmesh_looptri_and_normals_calc
- BKE_editmesh_looptri_and_normals_calc_with_partial
- EDBM_update also takes advantage of this,
where calling EDBM_update with calc_looptri & calc_normals
enabled uses the faster normal updating logic.
Bypass stored edge-vectors for ~16% performance gains.
While this increases unit-length edge-vector calculations by around ~4x
the overhead of a parallel loop over all edges makes it worthwhile.
Note that caching edge-vectors per-vertex performs better and may be
worth investigating further, although in my tests this increases code
complexity with barley measurable benefits over not using cache at all.
Details about performance and possible optimizations are noted in
bm_vert_calc_normals_impl.
Use BM_iter_parallel for face tessellation, this gives around
6.5x speedup for BM_mesh_calc_tessellation on high poly meshes in my
tests, although exact speedup depends on available cores.
Support thread local storage for BLI_task_parallel_mempool,
as well as support for the reduce and free callbacks.
mempool_iter_threadsafe_* functions have been moved into a private
header thats only shared between task_iterator.c and BLI_mempool.c
so the TLS can be made part of the iterator array without having to
rely on passing in struct offsets.
Add test task.MempoolIterTLS that ensures reduce and free
are working as expected.
Reviewed By: mont29
Ref D11548
Simplify vertex normal calculation by moving the main normal
accumulation function to operate on vertices instead of faces.
Using faces had the down side that it needed to zero, accumulate and
normalize the vertex normals in 3 separate passes, accumulating also
needed a spin-lock for thread since the face would write it's normal
to all of it's vertices which could be shared with other faces.
Now a single loop over vertices is performed without locking.
This gives 5-6% speedup calculating all normals.
This also simplifies partial updates, fixing a problem where
all connected faces were being read from when calculating normals.
While this could have been resolved separately,
it's simpler to operate on vertices directly.
This patch exposes functionality for performing partial mesh updates
for normal calculation and face tessellation while transforming a mesh.
The partial update data only needs to be generated once,
afterwards the cached connectivity information can be reused
(with the exception of changing proportional editing radius).
Currently this is only used for transform, in the future it could be
used for other operators as well as the transform panel.
The best-case overall speedup while transforming geometry is about
1.45x since the time to update a small number of normals and faces is
negligible.
For an additional speedup partial face tessellation is multi-threaded,
this gives ~15x speedup on my system (timing tessellation alone).
Exact results depend on the number of CPU cores available.
Ref D11494
Reviewed By: mano-wii
This was kept since these blocks are easier to follow.
Remove as the overall result wasn't so readable
(especially with nested ifdef's).
Replace disabled code with comment on the indices used for quads/tris.
2 sided faces aren't supported and will cause problems in many areas
of Blender's code.
Removing (implied) support for faces with fewer than 3 sides
means the total number of triangles is known ahead of time.
This simplifies adding support for multi-threading and partial updates
to an existing tessellation - as the face and loop indices can be used
to access the range of triangles associated with a face.
Also correct outdated comments.
bf_bmesh historically always build with the /WX flag
on windows making all warnings errors, somewhere along
the way this has broken for msbuild, ninja still exhibits
the expected behaviour.
The flags are still passed to the target, and I've validated
they are there when the add_library call fires, but they
somehow never make it to the generated msbuild project files.
I suspect this is a cmake bug but I'm seemingly unable
to extract a repro case to file a bug upstream.
Setting the same options target_compile_options seems to work,
I'm not happy about the unexplained nature of the breakage
but this will have to do for now.
BMesh intersect could leave invalid items in the selection list,
causing a crash. The list is now cleared since boolean is such a
destructive operation, it's unlikely the selection order would be useful.
Thanks to @lukastoenne for finding the root cause.
The main goal here is to remove the need for a C API to the code in
`mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c`
to C++ and making the necessary changes for it to compile. On top of
that there are some other slight simplifications possible to the
direct mesh boolean code: it doesn't need to copy the material
remaps, and the modifier code can use some other C++ types directly.
Changes to increase subdivision by one along both axis (X and Y)
For example with x_segment = 3 and y_segment = 3.
There should be 16 vertices ((3 + 1) * (3 + 1)) for correct
number of subdivisions. Currently they are 3 * 3 = 9 vertices.
Ref D10699
The commit rB6f63417b500d that made exact boolean work on meshes
with holes (like Suzanne) unfortunately dramatically slowed things
down on other non-manifold meshes that don't have holes and didn't
need the per-triangle insideness test.
This adds a hole_tolerant parameter, false by default, that the user
can enable to get good results on non-manifold meshes with holes.
Using false for this parameter speeds up the time from 90 seconds
to 10 seconds on an example with 1.2M triangles.
