First basic implementation

Discussion about the development of the Assembly workbench.
ickby
Posts: 2922
Joined: Wed Oct 05, 2011 7:36 am

First basic implementation

Postby ickby » Thu Apr 25, 2013 11:36 am

Hello,

I've written a first, very basic concept for the solver integration. This is not very useful at the moment, it's just to let you guys check if the basic idea behind it is ok with you. The code is in this repository, within the "assembly" branch (which is based on jriegel/dev-assembly): git@github.com:ickby/FreeCAD_constraint.git

Currently you can select two vertices and then hit the constraint button, they should be coincident afterwards.

1. The idea behind the implementation is to build up the solver incrementaly. This means that every new part gets added to the existing solver structure. Thats opposed to the complet recreation of the solving system with each recalculation like in the sketcher. At the moment the incremental creation brings not realy a huge speed up, however, this will change in the future when I get the time to implement my ideas for analysing. I therefore integrated the solver tightly into ItemPart and ItemAssembly. I would like to here if you can live with that, or if this way of integration is too tight.

2. I added helper functions to ItemPart and ItemAssembly to make it easyer to find the right Items for a given Document Object. Is this the right place for such functionality? We already discussed diffrent possibilities in the other thread, but I decieded to use this method as it seems more logical for me than a complete graph or linked based tree traversal. If this is not wished, I can of course change this (Thats the point for such an early showcase :) )

3. I had problems getting the right value of the selected geometries. If the features underlying sketch is not rotated at all, the TopoDS_Shape of the Part gives the correct value. If it is rotated, it gives the local value, which is of course the same as the unrotated one. Now I could of cource extract the sketchbased feature from the document object and get the rotation value, but that is not very general as chamfer's for example are not derived from sketchbased. And a check for every possible type seems not very clever. Is there a better way of doing it? (in the current implementation the rotation is neclected and the results will be wrong after solving if the placement is not identidy)

4. My solver code is heavy template based and puts quite some pressure on the compilers. On windows I only tested it with VS 2010, so I would love to here experiences with other versions, if anyone usese one. EDIT: I develop on Linux with gcc, so that works too.

Love to here youre ideas and comments,
Stefan
Last edited by ickby on Thu Apr 25, 2013 12:19 pm, edited 1 time in total.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: First basic implementation

Postby jriegel » Thu Apr 25, 2013 12:09 pm

Wow ickby, thats a big junk of code ! :o
I'm impressed! I will take a look as soon as I can!

1 Sounds good, but I think there will be soon lots of people experimenting with your solver and will have all kind of demands ;)

2 I wouldn't care much at the moment. Later on we have to do anyway a proper python interface for that helpers and then the best place is most probably the module itself. But I have not a opinion on that at the moment. For sure I want to have much more python in Assembly in opposite e.g. to PartDesign. I think build up, traversal and changing of product trees will be heavily done with python, since its so application and policy dependent.

3. The plan is to use only the Body as interface to the whol PartDesign crowed of features. So the AssemblyItemPart will link a Body and dont care about the othere features. The Placement of the Body and the features down below stay untouched. Only the AssemblyItemPart changes. So is my plan, we will soon see if it holds on to reality :)

4. I'm still on VS 2008 (VC9). So will see if its run there. But what I see, its not all to fancy templating. Gcc should have also no problem with that, since boost is well ported. Older compilers - go to hell...

Stay tuned!
Stop whining - start coding!
logari81
Posts: 654
Joined: Mon Jun 14, 2010 6:00 pm

Re: First basic implementation

Postby logari81 » Thu Apr 25, 2013 2:04 pm

@ickby, I haven't looked at your code but just a quick comment:

in 99% of the user cases, the assembly will not need to solve a mechanism at all, so the task of the solver is reduced to solving all assembly steps individually with only 6 dofs in each step. It seems that your comment #1 refers to that. I hope that your solver exploits this great simplification that will be valid for 99% of the cases.
ickby
Posts: 2922
Joined: Wed Oct 05, 2011 7:36 am

Re: First basic implementation

Postby ickby » Sat Apr 27, 2013 6:48 am

@logari: Thats one of my ideas, yes, it is however not implemented yet. I decided to tread the most general case first and after that treat the special cases. Thats because I don't think it is that seldom needed. For example the engine from the 0.13 splashscreen (which is one of my test cases). Of course non-cyclic systems will be the majority, and the needed infrastructure for such simplifications is already in the code, so it's a matter of time.
Another thing to consider: The general solving code is non trival and still not bug free. It's good that it is used exclusivly the first time as this gives me the chance to make it stable before I introduce simplifications and it is only used seldom afterwards.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: First basic implementation

Postby jriegel » Mon Apr 29, 2013 3:50 pm

Hi Stefan,
I tried to apply your branch, but seams you forgot to check-in some files:
ConstraintPy.xml
ConstraintPyImp.cpp
ConstraintAxisPy.xml
ConstraintAxisPyImp.cpp
Stop whining - start coding!
ickby
Posts: 2922
Joined: Wed Oct 05, 2011 7:36 am

Re: First basic implementation

Postby ickby » Mon Apr 29, 2013 9:32 pm

ah yes, they are added now.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: First basic implementation

Postby jriegel » Wed May 01, 2013 5:18 pm

Now the Solver.h seams to be missing :)
Stop whining - start coding!
ickby
Posts: 2922
Joined: Wed Oct 05, 2011 7:36 am

Re: First basic implementation

Postby ickby » Wed May 01, 2013 5:26 pm

updated now, hope this is everything this time! Is there a way to check for untracked files in a directory?
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: First basic implementation

Postby jriegel » Wed May 01, 2013 6:11 pm

I use SmartGit gui which shows untracked files and makes it generally more easy to work with git...
Stop whining - start coding!
wmayer
Site Admin
Posts: 14887
Joined: Thu Feb 19, 2009 10:32 am

Re: First basic implementation

Postby wmayer » Thu May 02, 2013 11:00 am

git status