TODO for sketcher

[jriegel]

Its a bit different. Its not to protect the parameters...

The constraints drive the solver process. The solver try to keep them satisfied. So if we
drag one point in the Sketch by the mouse, we force a point to a certain position (x,y).
On way would be to set the parameters representing x,y of this point to the mouse position.
But when we start to solve some other constraint (e.g. a horizontal) would move the point
somewhere else. So what we basically do is to remove x,y of this point from the parameter
vector. Unfortunately we can not just remove the parameter. That would shorten the parameter
space and invalidate all pointers in the constraints. So what I did is to search all constraints
refer to that point and redirect this constraints to other two doubles. Since this doubles are
not part of the parameter vector they stay constant while solving and the (e.g. horizontal)
constraint drive its other point to the right position. If the solver returns successful it means
all constraints are meet, so the fixed x,y position of our dragged point was ok. Which mean
we can write the x,y coordinate to the actual parameter vector. Then we write back the parameter
to the geometry (including our written back x,y point).

So you may ask what happens to the x,y parameter in the parameter vector while solving? Basically nothing
cause there is no driving constraint left for it (we redirected all), so the solver ignores it (invariant).

I know, its a bit tricky to wrap the brain around it, took me quit a while.....

This whole artistic is because of the absence of a fix-constraint in this solver. So we temporarily change
the constraints to simulate a fixed point and the copy of the constraint vector is a easy way to
keep this local to solve().

[jriegel]

The error its easy to show, just create a new sketch. Draw one line, give him a horizontal constraint and drag
first one point and then the other. It don't work at the actual code..

The error gets suspended if you add or delete a geometry or constraint, because then the Sketch in the
ViewProvider gets a new constraint and geometry set which is untainted - until you drag again....

[logari81]

nice explanation, now I got it. I will try to fix it.

[logari81]

I think I have found a less ugly and more general solution, please take a look at revisions 4281, 4282.

[jriegel]

That looks good!

Also nice implementation of the Circle, works like a charm!

[jriegel]

Hi logari,

Code: Select all

        else if ((*it)->getTypeId()== Part::GeomCircle::getClassTypeId()) { // add a circle
            const Part::GeomCircle *circle = dynamic_cast<const Part::GeomCircle*>(*it);
            TopoDS_Shape shape = (*it)->toShape();
            if (shape.ShapeType() == TopAbs_EDGE) { // this should be an assert condition
                // triangulate the edge
                BRepTools::Clean(shape);
                BRepMesh::Mesh(shape, 1e-2);

                const TopoDS_Edge& aEdge = TopoDS::Edge(shape);

                // try to extract the edge triangulation
                TopLoc_Location aLoc;
                Handle(Poly_Polygon3D) aPoly = BRep_Tool::Polygon3D(aEdge, aLoc);

if you use the mesher to create the lines for the circle I would suggest not to use a fixed seg-value (1e-2). That lead to big problems if some one draw a circle with some meters diameter......
I would suggest to use a fixed number of segments for the circle (e.g. 20) and use Pythagoras to calculate them.

[logari81]

ah, ok, I will improve the resolution for the triangulation of circles as soon as I find some time for this.

Now I have a question concerning arcs. I am trying to implement arcs in the sketcher and I realize that there is no GeomArc object in Geometry.h. Of course I can use GeomTrimmedCurve (actually I have already started it with it) but this requires a lot of complex manipulation of OCC object to be repeated at different places of the sketcher. It would be much more convenient to encapsulate all these calculations in a new class GeomArc built on top of GeomTrimmedCurve or GeomCurve. However I see that there are already different objects characterized as arcs:
1. Arcs in the draft module are some kind of enhanced Circles implemented as PythonFeature
2. ArcPy.h defines arcs corresponding to GeomTrimmedCurve

If I now add a GeomArc class in Geometry.h I will probably increase the possibilities of confusion. What is your idea/strategy about arcs throughout the whole FreeCad?

[wmayer]

If I now add a GeomArc class in Geometry.h I will probably increase the possibilities of confusion. What is your idea/strategy about arcs throughout the whole FreeCad?

I think we can have the class GeomArc if it makes the sketcher code easier. ArcPy will use this class then. The arc in draft is directly constructed from a shape not a geometry and thus is something different in the end anyway.

[NormandC]

Some problems with pad and pocket features created from circles, see bug 315. Understandable with something so fresh.

While in Sketch edit mode, moving the circle by picking & dragging its center point, or changing its size by grabbing and dragging its perimeter works very well.

[jriegel]

No its good! Tell us all your observations!