Some uses of delaunay_2d_calc don't need to know the original verts,
edges, and faces that correspond to output elements.
This change adds a "need_ids" value to the CDT input spec, default true,
which tracks the input ids only when true.
The python api mathutils.geometry.delaunay_2d_cdt gets an optional
final bool argument that is the value of need_ids. If the argument
is not supplied, it is true by default, so this won't break old uses
of the API.
On a sample text test, not tracking ids save about 30% of the runtime.
For most inputs the difference will not be so dramatic: it only really
kicks in if there are a lot of holes.
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
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.
Event though in practice this wasn't causing problems as the fixed size
buffers are generally large enough not to truncate text.
Using the result from `snprint` or `BLI_snprintf` to step over a fixed
size buffer allows for buffer overruns as the returned value is the size
needed to copy the entire string, not the number of bytes copied.
Building strings using this convention with multiple calls:
ofs += BLI_snprintf(str + ofs, str_len_max - ofs);
.. caused the size argument to become negative,
wrapping it to a large value when cast to the unsigned argument.
Combining location, rotation and scale channels into a matrix is
a standard task, so while it is easily accomplished by constructing
and multiplying 3 matrices, having a standard utility allows for
more clear code.
The new constructor builds a 4x4 matrix from separate location,
rotation and scale values. Rotation can be represented as a 3x3
Matrix, Quaternion or Euler value, while the other two inputs
are vectors. Unneeded inputs can be replaced with None.
Differential Revision: https://developer.blender.org/D11264
While `tp_print` was deprecated, Python 3.8+ uses this for
'tp_vectorcall_offset' which wasn't stated in the comment from
efd71aad4f.
Instead of suppressing clang-tidy, use preprocessor a check since
this properly represents the difference between Python versions.
Use common prefix as this collided with existing API's (eg BLI_voronoi).
Also expand some non-obvious abbreviations:
- 'g' -> 'generic'
- 'vl' -> 'variable_lacunarity'
- 'V' -> 'v3'
We have our own assert implementation, `BLI_assert()` that is prefered over the
C standard library one. Its output is more consistent across compilers and
makes termination on assert failure optional (through `WITH_ASSERT_ABORT`).
In many places we'd include the C library header without ever accessing it.
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
Functions `mesh_create_eval_final_view()` and
`mesh_create_eval_final_render()` were doing the exact same thing,
except for a hack introduced in d3eb9dddd6 (2012-10-08, Better fix for
T32846: dupligroup messes up particle instancing on rendering) that
appears to be no longer necessary. Besides that, these functions had
confusing names. Their functionality changed over time, and whether to
do for-render or for-viewport evaluation is now actually determined by
the depsgraph evaluation mode. This means that the `..._render` function
could evaluate a mesh with viewport settings, and vice versa.
The functions are now merged into `mesh_create_eval_final()`, and the
hack has been removed. The `OB_NO_PSYS_UPDATE` flag has been removed
entirely (instead of keeping it around as deprecated flag), because it
was always only temporarily set on objects during mesh evaluation and
thus not saved to the blend file.
No expected functional changes as far as users are concerned.
