This way they can be tested individually in the Python console
without needing the `Array` class at all. In the future these
methods could be moved to `DraftGeomUtils` or to `draftfunctions`.
Since the `Array` class handles three different types, they
have different sets of properties. We add them to specific functions
so that they are clearly identified.
This class was created by realthunder during the `LinkMerge`,
in 8cd9339b8c, to demonstrate how to use the `App::Link`
objects to create Link aware arrays.
It is used by `draftobject.array` (ortho, polar, circular)
and `draftobject.patharray` to create respective Link arrays.
This class is a bit mysterious. We need more documentation
on how the properties are being set, and how the code interacts
with the arrays that use it.
Avoid `Draft.py` in the `make_circular_array` function because
it creates a circular dependency.
Use function to find the object in `make_circular_array`.
Now the make function accepts as input a `"String"` which must be
the `Label` of an object in the document, so it is easier to create
arrays interactively from the Python console.
Clean up the GuiCommand and task panel code, and avoid printing
messages to the terminal, as this is already done
by the make function.
Avoid `Draft.py` in the `make_polar_array` function because
it creates a circular dependency.
Use function to find the object in `make_polar_rarray`.
Now the make function accepts as input a `"String"` which must be
the `Label` of an object in the document, so it is easier to create
arrays interactively from the Python console.
Clean up the GuiCommand and task panel code, and avoid printing
messages to the terminal, as this is already done
by the make function.
Avoid `Draft.py` in the `make_ortho_array` function because
it creates a circular dependency.
Use internal functions to abstract the orthogonal arrays.
The `_make_ortho_array` is a simple wrapper over the general
`make_array` function.
The result is four variants:
- `make_ortho_array`
- `make_ortho_array2d`, without the Z component
- `make_rect_array`, strictly rectangular components
- `make_rect_array2d`, strictly rectangular without the Z component
Also use functions to perform checking of the inputs,
whether these are vectors, numbers (integer and floats)
or integers.
Now the make function accepts as input a `"String"` which must be
the `Label` of an object in the document, so it is easier to create
arrays quickly from the Python console.
Clean up the GuiCommand and task panel code, and avoid printing
messages to the terminal, as this is already done
by the make function.
The displacement is added to the position already defined by
the point, in order to impart an additional shift in the copy.
The rotation is also added to the original shape's rotation
by multiplying the quaternions.
Implement `onDocumentRestore` to add the new property
to older objects.
Test the inputs to the `make_point_array` function
and return `None` if there is a problem.
Now the make function accepts as input a `"String"` which must be
the `Label` of an object in the document, so it is easier to create
arrays quickly from the Python console.
Add a message deprecating the older call `makePointArray`.
Adjust the GuiCommand accordingly. Now it uses the commit
mechanism of the parent `Modifier` class so that the executed
functions are recorded in the Python console.
Clean up the `PointArray` class as well.
Meshing tolerance settings for 3d surface operations were ignored since
switching to directly using facets from the view tesselation. On complex
3d shapes, this could cause serious meshing artifacts in the generated
paths, serious enough to show up even in path previews.
Additionally, there were occasionally segfaults when a model was not
viewed and thus implicitly tessellated before starting an OCL operation.
This patch switches from using view tessellations to explicitly calling
`tessellate()`. While this is usually more expensive than using the
existing view tessellation, recent changes to parallelize tessellation
have reduced this additional cost significantly.
Note that this diff only restores the use of LinearDeflection, since
that is the main thing we care about in OCL use cases. Angular
deflection is still ignored, but I think this is a good thing for this
case since a highly refined mesh in tiny but heavily curved areas below
the linear deflection threshold just adds unnecessary cost. If there is
agreement on this point, then we can remove the preference for
AngularDeflection from the UI in a follow-up.
=======================================================
fixes#4295
PointOnObject autoconstraint for BSplines is currently not supported, this
commit prevents malformed autoconstraint creation.
