TODO for sketcher

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: TODO for sketcher

Postby jriegel » Wed Mar 23, 2011 12:12 pm

Next steps I think should be a more intuitive creation of the arcs, similar to the function of the draft module and it also seems the coincident constraint of e.g. a line with the end points of the arc doesn't work.
This is because the performance hack to remove all coincident constraints by using the same point. In Arc only the middle point gets tested, but thats the least likely to be coincident to a line.
So we have to test the end and start point here....

For the creation:

There are two cases.
Case 1: free creation of an arc.

There you have to define at least three points on the arc or start,end, middle. But in CAD this is rather unusual, cause a arc is
most likely part of a hull in some sense. So creating a free arc means you have to add some constraints by hand..

Case 2: creation tool (like Catia)

Most likely use is the creation of a set of lines and arcs in a row, with some predefined constraints. E.g.
starting with a line. At the end of the line you can decide whether continue with another line or with a tangent arc.
If the arc is tangent you can define the complete arc by the next point alone. Then continue with another (coincident) line or arc.
That makes a fast workflow to define a complete hull of a Part...

If the arc is implemented and logari is not interested to implement such a work flow let me know. Then I will do it!
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: TODO for sketcher

Postby logari81 » Wed Mar 23, 2011 1:21 pm

jriegel wrote: This is because the performance hack to remove all coincident constraints by using the same point. In Arc only the middle point gets tested, but thats the least likely to be coincident to a line.
So we have to test the end and start point here....
This is one of the parts that I haven't committed yet and I am going to commit soon, I am just a bit busy these days but I will continue working on the Sketcher in the weekend. I will finish the arcs and continue with external constraints. You can reserve these two tasks for me :). Of course I will ask for help again if I get stuck.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: TODO for sketcher

Postby jriegel » Wed Mar 23, 2011 3:40 pm

We can organize by Mantis.
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: TODO for sketcher

Postby logari81 » Thu Mar 24, 2011 9:41 pm

I have improved a bit the drawing of arcs in the sketcher making it consistent with arcs drawing in draft. However, I have some difficulties with arcs in sketchsolve. According to its documentation, every arc needs an arcRules constraint. When I add such a constraint I get a crash with some Illegal storage access message. I cannot find out what I am missing here.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: TODO for sketcher

Postby jriegel » Fri Mar 25, 2011 6:34 am

I had a some years ago a discussion with the guy maintain the usage of this solver in heekscad.
He gave me the tip about avoiding the coincident constraints for points and he also mentioned
that he has to do some kind of arc rule rewrite. Unfortunately I couldn't dig up that discussion
cause it was in some kind of chat-room... :(

Anyway, you can take a look in the heekscad code to see whats needed. There is a special
class with the sole purpose to get around that issues of the solver.
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: TODO for sketcher

Postby logari81 » Sun Mar 27, 2011 8:13 am

I have done a bit of progress with arcs in the Sketcher. However I have a problem with the changes in revisions 4292 and 4293. After 4293 a full cloning of the Geometries and the underlying OCC objects takes place. Before that we used to clone the Geometries but still linking to the original OCC objects. This way under:

Code: Select all

     // if successfully solve write the parameter back
we could apply changes to the original Geometry.

Now that we fully clone the Geometries this is not possible anymore. Any suggestions?

Why do we use copies of the Geometries for GeoDef.geo instead of the original ones at all?
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: TODO for sketcher

Postby logari81 » Sun Mar 27, 2011 6:05 pm

arcs are almost finished. There was a bug in sketchsolve that cost me a lot of hours, but now arcs work relatively well provided that one partially reverts 4292, 4293.

It seems that the arcs in the sketch harm a bit the robustness of the solver. Occasionally it fails to solve the constraints. Maybe we could improve this situation by intelligently fixing some of the arc parameters before the solution, check the solution status and if needed release these fixed parameters and repeat the solution again. Some sanity checks on the solution results could also be helpful.

Our priorities:

1. Find a solution for the issue with 4292, 4293
2. Improve the robustness of the solver with arcs
3. Implement tangent constraints
4. Implement external constraints
5. Implement some path tool

I do not have any important uncommitted changes now and in the next days I am not going to work on the Sketcher, so this is a nice point to step in if you want to take over the implementation of some of the listed objectives.
wmayer
Site Admin
Posts: 16460
Joined: Thu Feb 19, 2009 10:32 am

Re: TODO for sketcher

Postby wmayer » Mon Mar 28, 2011 8:54 am

I have done a bit of progress with arcs in the Sketcher. However I have a problem with the changes in revisions 4292 and 4293. After 4293 a full cloning of the Geometries and the underlying OCC objects takes place. Before that we used to clone the Geometries but still linking to the original OCC objects. This way under:
The way how it was implemented in 4292 and before was simply wrong. In some cases we used the default copy constructor (created by the compiler) but this is definitely wrong because it internally copies the handle but not the actual geometry object it points to. So, the consequence was that two instances of e.g. GeomCircle (the FreeCAD class) can access the same instance of Geom_Circle (the OCC class). IMHO this makes no sense and is even wrong because it leads to some evil side-effects which are hard to find. That's why I have made the copy-constructor and assignment operator private in the class Geometry in rev. 4293 and replaced the use of the copy-constructor with the clone() method.

So, the question is whether we really need a copy or whether it suffices to use the original instance. The original geometry instances are created in Python code over their wrapper classes. If we want to use the original instance we only have to make sure to keep the appropriate Python instance and increment its reference counter and decrement if when removing the geometry object from the sketch. This makes sure that the geometry instance won't be destroyed as long as we need it.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: TODO for sketcher

Postby jriegel » Mon Mar 28, 2011 2:59 pm

we could apply changes to the original Geometry
Werner is right, this handle paradigms in Geometry is dangerous. And thats because of a
feature of the document called "Transactions".

Every change in the document is monitored by the transaction/undo/redo facility. That mean
if you change a property, the document makes a copy of the original property to allow a undo.
Cloning is essential to make this work...
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: TODO for sketcher

Postby logari81 » Mon Mar 28, 2011 3:09 pm

I understand both of you and I agree with your points, so what would be the solution now?