I have had nothing but trouble with conda. Everytime I have to reconfigure my machine I basically have to take a day to get conda working. Is there a possibility to move away from it and just starting using pypi?

This PR will eventually resolve #276, #20

What's left

• [x] ~~Exact jacobian~~ , finite diff jacobian by hand
• [x] Finalize solver choice -> BFGS it is
• [x] Implement parameters handling (e.g. specific angle or distance constraint)
• [x] Visually attractive example in docs/README

Closes #105.

Seems to be working almost fine:

https://peertube.social/videos/watch/b922711c-b6d1-45d9-b44b-897b489e2781

Do not merge yet, just for discussion/impressions/feedback...

• https://github.com/Peque/sphinxcadquery/issues/4
• https://github.com/Peque/sphinxcadquery/issues/5

Current approach is based on x3dom functionality of python-occ. It will probably be not available in the future but it would be good to keep the simple ipython visuaization capabilities. One way to achieve this woulde be to use VTK and some additional tools. Relevant materials

• https://lorensen.github.io/VTKExamples/site/Python/DataManipulation/Cube.py
• https://k3d-jupyter.org/index.html
• https://docs.pyvista.org/index.html

Note that OCCT has (in some versions) VTK related functionalities:

• https://www.opencascade.com/doc/occt-7.0.0/refman/html/toolkit_tkivtk.html --> has it been removed in 7.4 ?

Somehow the installation of ipython kills cadquery:

I use miniconda as base with conda 4.5.2

1. Install conda environment and cadquery-occ

$ conda create -n py3occ python=3.6
$ source activate py3occ
$ conda install -c pythonocc -c oce -c conda-forge -c dlr-sc -c CadQuery cadquery-occ

2. Test

$ python

Python 3.6.6 | packaged by conda-forge | (default, Jul 26 2018, 09:55:02)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cadquery
>>>

3. Install ipython

$ conda install ipython

Solving environment: done

## Package Plan ##

  environment location: /opt/miniconda/envs/py3occ

  added / updated specs:
    - ipython


The following NEW packages will be INSTALLED:

    appnope:          0.1.0-py36hf537a9a_0
    backcall:         0.1.0-py36_0
    decorator:        4.3.0-py36_0
    ipython:          7.2.0-py36h39e3cac_0
    ipython_genutils: 0.2.0-py36h241746c_0
    jedi:             0.13.2-py36_0
    parso:            0.3.1-py36_0
    pexpect:          4.6.0-py36_0
    pickleshare:      0.7.5-py36_0
    prompt_toolkit:   2.0.7-py36_0
    ptyprocess:       0.6.0-py36_0
    pygments:         2.3.1-py36_0
    six:              1.12.0-py36_0
    traitlets:        4.3.2-py36h65bd3ce_0
    wcwidth:          0.1.7-py36h8c6ec74_0

The following packages will be UPDATED:

    openssl:          1.0.2p-h470a237_2     conda-forge --> 1.1.1a-h1de35cc_0
    python:           3.6.6-h5001a0f_0      conda-forge --> 3.6.8-haf84260_0

The following packages will be DOWNGRADED:

    ca-certificates:  2018.11.29-ha4d7672_0 conda-forge --> 2018.03.07-0
    certifi:          2018.11.29-py36_1000  conda-forge --> 2018.11.29-py36_0

4. Test

$ ipython
Python 3.6.8 |Anaconda, Inc.| (default, Dec 29 2018, 19:04:46)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.2.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import cadquery as cq
Fatal Python error: PyThreadState_Get: no current thread

Abort trap: 6

I have found a way to create self-contained OCP wheels on Linux, allowing cadquery and all its dependencies to be installed via pip. I am sharing it here in the hopes that others may find it helpful, either for personal pip workflows or as a step towards official PyPI wheels.

I note that https://github.com/CadQuery/cadquery/issues/153#issuecomment-1033053777 requests a working pipeline, presumably Azure pipelines for all platforms. This is NOT that yet; this is only a way to build a wheel, and has only been tested on Linux.

The wheel is created from a conda environment with OCP installed. The OCP and vtk files in the python import path are blindly copied into a wheel. This wheel is of course unusable, but then we simply use auditwheel to bundle external libraries and produce a working manylinux_2_31_x86_64 wheel. This wheel is 160 MB, which is large but probably can be accommodated by PyPI.

A working cadquery venv can be created by pip installing this wheel along with git+https://github.com/CadQuery/cadquery, ezdxf, ipython, multimethod, nlopt, and nptyping<2. Thanks to @roipoussiere who has also tested this.

The code is available in this gist; see the docstring of setup.py for details. Testers on macOS and Windows will have to replace the use of auditwheel with delocate and delvewheel respectively. The created wheels may not be distributed until the requisite license files have been added into the wheel.

I made an implementation of BRepOffsetAPI_MakeFilling into CadQuery in order to produce a plate surface with a thickness, enclosed by edge points, and going through interpolation points. To this end I added these 2 functions to shapes.py:

from OCC.Core.GeomAbs import GeomAbs_C0 
from OCC.Extend.TopologyUtils import TopologyExplorer, WireExplorer 
from OCC.GeomAbs import GeomAbs_Intersection 
from OCC.BRepOffsetAPI import BRepOffsetAPI_MakeFilling 
from OCC.BRepOffset import BRepOffset_MakeOffset, BRepOffset_Skin

class Face(Shape):
    @classmethod
    def makeNSidedSurface(cls, edges, points, continuity=GeomAbs_C0, Degree=2, NbPtsOnCur=20, NbIter=2, Anisotropie=False, Tol2d=0.00001, Tol3d=0.0001, TolAng=0.01, TolCurv=0.1, MaxDeg=8, MaxSegments=9):
        """
        makeNSidedSurface() creates a surface enclosed by a closed polygon defined by 'edges' and going through 'points'.
        """
        n_sided = BRepOffsetAPI_MakeFilling(Degree, NbPtsOnCur, NbIter, Anisotropie, Tol2d, Tol3d, TolAng, TolCurv, MaxDeg, MaxSegments)
        for edg in edges:
            n_sided.Add(edg, continuity)
        for pt in points:
            n_sided.Add(pt)
        n_sided.Build()
        face = n_sided.Shape()
        return cls.cast(face).fix()

class Solid(Shape, Mixin3D):
    @classmethod
    def interpPlate(cls, surf_pts, surf_edge_pts, thickness, Degree=2, NbPtsOnCur=20, NbIter=2, Anisotropie=False, Tol2d=0.00001, Tol3d=0.0001, TolAng=0.01, TolCurv=0.1, MaxDeg=8, MaxSegments=9):
        """
        interpPlate(): creates a plate surface that is 'thickness' thick, enclosed by 'surf_edge_pts' points,  and going through 'surf_pts' points.
        """
        # BOUNDARIES
        xmax, ymax, zmax = max(surf_pts[:,0]), max(surf_pts[:,1]), max(surf_pts[:,2]) 
        xmin, ymin, zmin = min(surf_pts[:,0]), min(surf_pts[:,1]), min(surf_pts[:,2])
        # POINTS CONSTRAINTS
        pts_array = [gp_Pnt(*pt) for pt in surf_pts]   
        # EDGE CONSTRAINTS: build closed polygon
        e_array = [Vector(*e) for e in surf_edge_pts]
        wire_builder = BRepBuilderAPI_MakePolygon()
        for e in e_array:
            wire_builder.Add(e.toPnt())
        wire_builder.Close()
        w = wire_builder.Wire()
        edges = [i for i in TopologyExplorer(w).edges()] 
        # MAKE SURFACE
        continuity = GeomAbs_C0 # Fixed, changing to anything else crashes.
        face = Face.makeNSidedSurface(edges, pts_array, continuity, Degree, NbPtsOnCur, NbIter, Anisotropie, Tol2d, Tol3d, TolAng, TolCurv, MaxDeg, MaxSegments) 
        # THICKEN SURFACE
        solid = BRepOffset_MakeOffset()
        solid.Initialize(face.wrapped, thickness, 1.e-5, BRepOffset_Skin, False, False, GeomAbs_Intersection, True) #The last True is important to make solid
        solid.MakeOffsetShape()
        
        return cls(solid.Shape())

and this function to cq.py

class Workplane(CQ):
    def interpPlate(self, surf_pts, surf_edge_pts, thickness, combine=True, clean=True, Degree=2, NbPtsOnCur=20, NbIter=2, Anisotropie=False, Tol2d=0.00001, Tol3d=0.0001, TolAng=0.01, TolCurv=0.1, MaxDeg=8, MaxSegments=9):
        """
        interpPlate(): creates a plate surface that is 'thickness' thick, enclosed by 'surf_edge_pts' points,  and going through 'surf_pts' points.
        :Array of [x,y,z] Real coordinates: surf_pts
        :Array of [x,y,z] Real ordered coordinates: edges_pts
        :Real: thickness
        :Integer: Degree = 3 (OCCT default value, 2 works better for Gyroids)
        :Integer: NbPtsOnCur = 15 (OCCT default value, 20 works better for thickening)
        :Integer: NbIter = 2
        :Boolean: Anisotropie = False
        :Real: Tol2d = 0.00001
        :Real: Tol3d = 0.0001
        :Real: TolAng = 0.01
        :Real: TolCurv = 0.1
        :Integer: MaxDeg = 8
        :Integer: MaxSegments = 9
        :type combine: true to combine shapes, false otherwise.
        :param boolean clean: call :py:meth:`clean` afterwards to have a clean shape
        """
        
        def _makeplate(pnt):
            return Solid.interpPlate(surf_pts, surf_edge_pts, thickness, Degree, NbPtsOnCur, NbIter, Anisotropie, Tol2d, Tol3d, TolAng, TolCurv, MaxDeg, MaxSegments)

        plates = self.eachpoint(_makeplate, True)

        # if combination is not desired, just return the created boxes
        if not combine:
            return plates
        else:
            # combine everything
            return self.union(plates, clean=clean)

As an example the attached script cq_InterpPlate_example.py, produces the Gyroid elementary plate of the attached screenshot through the use of cq.Workplane('XY').interpPlate(gxyz, xyz_max, AFT)

The surface needs to be relatively simple, and the number of interpolation points limited, otherwise it crashes. Also, the points defining the edges need to be ordered correctly to create a closed polygon. Do you think this could be a useful addition to CadQuery?

cq_InterpPlate_example.py.txt

This is a follow up of https://github.com/CadQuery/cadquery/issues/709.

Here we had a cube which's six faces were selected, a circle constructed on each and those extruded. My expectation from a beginners perspective was that the resulting cylinders would be perpendicular to the individual faces. I learned that this is not the current behavior (the circles seem to be on planes parallel to the base workplane through some (?) point on the respective face - which creates overlaps). Is there already a convenient way to achieve the desired behavior? If not, would it perhaps make sense to introduce a new option for the inPlane parameter of workplanes? E.g. "parent"? This could align the workplane parallel to the respective parent plane instead of taking over the orientation of the base plane.

So the example from the issue above could look like that: result = (cq.Workplane("XY") .box(10.0,10.0,10.0,centered=(True,True,True)) .faces() .workplane("parent") .circle(1.0,forConstruction=False) .extrude(1.0,combine=True,clean=False)) show_object(result)

That would create a box with six cylinders coming out of the six faces perpendicularly - easy to understand and potentially helpful in many cases. The other option would be to change the default behavior. But not sure whether people rely on the current alignment behavior or whether most consider the behavior just as "undefined" for non-parallel selected faces? But if people rely on the current behavior then the propsal above would allow to keep the current default behavior. Would this make sense and be desirable?

In implementing this feature I've had to touch some pretty fundamental CQ code, so I'm going to write a detailed description of what I've been up to here, because I'd really like others to follow along, provide good feedback, and hopefully get this merged without treading on other's toes.

Tags

The main feature I'm implementing is the abilty to tag an object (method CQ.tag) within the chain, and reload that object at a later point (method CQ.getTagged).

I've also created a method to create a workplane in the current CQ object by copying the workplane from another CQ object (method CQ.copyWorkplane). This is combined with tags in method CQ.copyWorkplaneFromTagged, allowing things like:

result = (
    # create a base solid for others to be built upon
    cq.Workplane("XY")
    .box(10, 10, 1, centered=(True, True, False))
    .faces(">Z").workplane()
    .tag("base")
    # build ontop of base solid
    .center(3, 0).rect(2, 2).extrude(4)
    .faces(">Z").workplane().circle(1).extrude(6)
    # go back to the base workplane
    .copyWorkplaneFromTagged("base")
    # build a different solid ontop of the base solid
    .center(-3, 0).circle(1).extrude(11)
)

A good example of a use case is modelling a PCB.

Construction geometry using tags

CadQuery shares the modelling context between all objects in the chain. This has an interesting interaction with tags, in that you can easily:

1. set a tag,
2. create some solids and workplanes, or any other CAD operations,
3. create some edges (which are added to the modelling context's pending edges),
4. go back to the tagged object with getTagged,
5. the solids created in step 2 are gone, but your pending edges are still there and can be used in eg. a loft operation

This could be very useful when step 2 involves creating complicated geometry, and you can't be bothered doing the maths to figure out where the edges need to go in step 3.

I wrote a test for this use case if you want to read some example code.

Other changes

This process of returning to tagged objects is a bit of an edge case for the existing CadQuery code, so I had to make a couple of changes to handle some errors that popped up.

• Workplane.newObject previously referenced the parent's plane. This made copyWorkplaneFromTagged produce some very confusing results, where the plane of a tagged object could be modified by objects further down the chain. I changed newObject to copy the plane instead. I acknowledge this increases the memory requirements, but I think it's worth it and also newObject is now more in line with how the user would expect it to function.
• Workplane.center previously changed the current object's plane before creating a new object with the current object's plane. I changed it such that the current object's plane is not modified. It's not as neat, but I think it's how users expect center to function.
• testWorkplaneCenter in test_selectors previously relied upon the mutable plane. The style of that test didn't seem to follow CadQuery's chained calls, so I changed it. I don't understand why the original code was written in that style, so I'm bringing attention to it here in case I messed with something I shouldn't. I see that test was some of the earliest CQ2.0 code written, and perhaps that was why it didn't use chained calls?

Todo

• [x] Add some examples for the docs
• [x] Further testing (I mean in regular use with CQ-editor, not just pytest)
• [x] See if I can think up of some other use cases for this. It's a pretty flexible method, the use cases are broad and I'm sure there are lots I'm missing. More use cases would let me write more tests and examples as well, which I would like to do.
• [x] Include feedback?

PS. I'm loving CadQuery. It's a light layer over OCC, so it's just so flexible. Extending it like this has been really enjoyable. None of that "smashing my head against the keyboard" as I struggle against heavy, opaque code I can't understand.

BRepBuilderAPI_MakeWire::Add(const TopTools_ListOfShape & L) offers the option to accept a list of shapes directly as argument: Adds the edges of <L> to the current wire. The edges are not to be consecutive. But they are to be all connected geometrically or topologically. If some of them are not connected the Status give DisconnectedWire but the "Maker" is Done() and you can get the partial result. (ie connected to the first edgeof the list <L>) Following this I modified the assembledEdges in shapes.py to be able to provide a list of unordered edges to BRepBuilderAPI_MakeWire. This way, when the list of edges is generated by another function, there is not need to make them consecutive.

We could use what @Peque has done ( https://github.com/Peque/sphinxcadquery ) to make the online documentation more appealing.

Cf. #13 for initial discussion

Update to OCCT/OCP 7.7.0

I'm not sure if the changes in the project test are some kind of regression or are due to wrong usage of the BRepProj_Projection.

As mentioned in #993, the GLTF exported file now displays correctly in blender.

I tried a few other viewers and found the colors are not displayed correctly using: CAD Assistant 1.6.0 Mayo 0.6.0.997-e1bebb0

Here is a screenshot of CAD Assistant import of the GLTF file exported with master (example code from #993):

Both cones are displayed as green. The expected result is one green cone and one blue cone.

I'm testing changes to the STEP color handling that should also fix the GLTF color display issue in these viewers.

Is it possible to use constraints to place objects for a cut operation? Or else some kind of undocumented way to "subtract" instead of "add" in an Assembly?

Hello, I'm new to cadquery and can not get a cutting with a circle profile working (test1). A "cylindric" cut out works fine (test2, test1 also works in Freecad). What I'm doing wrong? Error is TopoDS_Vertex hasn't gp_Pnt, but, sorry, I don't understand what it means and why is it different to the cylindric cut out...

outerring = cq.Workplane('XY').circle(20).circle(30).extrude(10).translate((0,0,-5)) cuttingring1 = (cq.Workplane('XZ').center(18,0).circle(3).sweep(cq.Workplane('XY').circle(16), isFrenet=True)) test1=outerring.cut(cuttingring1) #not working cuttingring2 = cq.Workplane('XY').circle(18).circle(25).extrude(6).translate((0,0,-2)) #test2=outerring.cut(cuttingring2) #working

Thank you, Markus

In this scenario I am trying to transfer an offset wire from a cylinder to a box. Performing a 2D offset I would expect that the dimensions of the wire will change but that it will remain on the same plane as the original wire. This is not the case as the offset2D operation changes the z component of the wire by 10 points (as much as the dimension of the box). The seems to be that the location of the wire does not match the CenterOfBoundBox. I am currently correcting it using center-offset.CenterofBoundBox() but it feels more of a hack than the intended behaviour. Shouldn't the location of a wire and its center be at least coplanar?

from cadquery import *
from cadquery.selectors import *
from math import *

from dataclasses import dataclass

box = Workplane('XY').box(10,10,10, centered=(True,True,False))
cylinder = box.faces('>Z').workplane(offset = 1).cylinder(10,5, centered=(True, True, False), combine=False)

center = box.faces('>Z').val().CenterOfBoundBox()

wire = cylinder.wires('<Z').val()
offset = wire.offset2D(-2)[0]

loc = Location(center-offset.CenterOfBoundBox())
wire_loc = offset.located(loc)

box = box.faces('>Z').add(wire_loc).toPending().cutBlind(-1)