Another approach to assembly solver (A2plus)

[Turro75]

continue....

then I constrained all items in a chain according to rule1
at some point I inserted an angle constraint in the middle, it is quite fast on recalculating

NEW LOGIC test Angled in between.PNG (77.9 KiB) Viewed 249 times

and then I I constrained all objs in "reversed" so no constraint match rule1
at some point I inserted an angle constraint in the middle, it is quite slow on recalculating

OLD LOGIC test Angled in between.PNG (99.38 KiB) Viewed 249 times

There is a problem, locking position of an object should be done according to degrees of freedom and not on status of the fathers.
May be when DOF will be introduced (required for animation) it will be fixed even this problem.

Let me know how about this.

the code is not clean and produces a lot of debugging info in the report console.

[kbwbe]

Hey @Turro75,

great. This is the real spirit of teamwork and open source.
Your solver improvements concerning "total steps used" are really impressive.

I will have look at your code, test it with your examples and my testcases.
Heavy stuff, will need a little bit of time to verify and find caveats.

Topic DOF: not easy to calculate. As Solver is more a multi body physics simulation than pure theoretical mathematics.
Do you have an idea ?

[Turro75]

I know it's not easy at all. Then falling down in the Hamish's algorithm could be an option but I think it will invalidate the your solver works.


I could say an easy way could be evaluating the impact of a constraint over an obj.
I.e. Circular edge locks 5dof but 1 axis rotation is left free. Lock rotation fix even the 6th dof so the obj is fully locked so it should be joined to the father as a subassembly. We could try to compile a list of effect for each constraints and see if a simple math does the job.

Another idea would be adding the six dof to each rigid, 1 means free and 0 means locked. When domovecalc add vectors it could be easy multiply each axis movement to the relevant dof, a similar approach could be done with rotation. Another check is if dof is globally locked or only relative to constrained obj.

How about?

[kbwbe]

I know it's not easy at all. Then falling down in the Hamish's algorithm could be an option but I think it will invalidate the your solver works.

I could say an easy way could be evaluating the impact of a constraint over an obj.
I.e. Circular edge locks 5dof but 1 axis rotation is left free. Lock rotation fix even the 6th dof so the obj is fully locked so it should be joined to the father as a subassembly. We could try to compile a list of effect for each constraints and see if a simple math does the job.

User could put redundant constraints to rigids. So a lot of checks are needed to eliminate them. Example: User fixes parts with 2 circularEdgeConstraints
and is not using lock rotation. If axes are different, rigid will has no DOF anymore, if axes are equal, still one DOF remains.
We will risk, that in special cases, the solver will fail. So everything we do, has to take care of all possible cases as solver has to work everytime...

Another idea would be adding the six dof to each rigid, 1 means free and 0 means locked. When domovecalc add vectors it could be easy multiply each axis movement to the relevant dof, a similar approach could be done with rotation. Another check is if dof is globally locked or only relative to constrained obj.

How about?

Perhaps one idea more:
ATM solver has most problems with long chains of constrained rigids. Necessary number of solversteps is growing fast.

There are two good examples.
Your recent assembly and Manuel's crankshaft. I should be possible to detect long chains (ending up somewhere but not to fixed rigids) and solve those chains later step by step after solving some others which are closer (less constraint hops) to fixed parts. Such a solution would not harm the flexibility of the solver in other cases, which is important.

[kbwbe]

@Turro75,

Good news + and others...

Good:
Your algorithm works in generally and solved all my test assemblies.

Not so good:
Manuel's crankshaft assembly could not use the benefits. It still used over 50.000 steps which is only little different from previous version.
But i will check my constraints wether i used some which are looping back to fixed rigids. This would possible break your improvements.

Edit1:
Very good news...
I disruppted (moved) all your parts in your testassembly and have put it to my standard tests...
- previous solver version failed !
- your modified version solved it within 6500 steps. It is fast
/Edit1

As there are to seem no severe bugs, i will now have deeper look at your code.

[kbwbe]

There is a problem, locking position of an object should be done according to degrees of freedom and not on status of the fathers.
May be when DOF will be introduced (required for animation) it will be fixed even this problem.

Hi @Turro75,
did you already register a solver failure caused by your stated problem above ? For me, everything works...

[Turro75]

Happy to ear that!

Let me explain a little deeper what I modified:

The solver is left untouched the only modification is that it solves constraints_reduced and rigids_reduced instead of constraints and rigids.
I splitted loadsystem to subroutines which create a limited set of constraints involved in the solver (constraints_reduced) after that it adds only involved and not locked rigids to rigids_reduced. Deps are calculated only on constraints_reduced and rigids_reduced.

Moreover I introduced a partial solve system which solves the above calculated small groups of constraints. When success the constraints are removed from list and rigids are locked so won't be involved in further calculation.

If the logic isn't able to find other constraints but there are still unresolved constraints
It takes all remaining constraints and all remaining rigids and try to solve them all together. This is why on some assembly You get a so close result. In fact if no constraints match the selection filter, then all constraints are solved all together as previous logic did.

I also introduced a limitation of step for each partial solve.

Of course how to use it:
Respect the 3rules of assembly I posted previously

1) in an assembly at least one part must be marked as fixed
2) when creating a constraint always select as first the reference object and then the object that must be moved.
3) manually pay attention to recursive constraint creation

Everytime You ignore the point n.2 You break the optimized calculation chain, after that the solver comes back to previous "all together" behavior.

[Turro75]

There is a problem, locking position of an object should be done according to degrees of freedom and not on status of the fathers.
May be when DOF will be introduced (required for animation) it will be fixed even this problem.

Hi @Turro75,
did you already register a solver failure caused by your stated problem above ? For me, everything works...

Yeah I saw it, in the piping structure I forgot to lock rotation on this object, the original logic used that freedom by rotating all other items while new logic fixed it as lock rotation was on.

Cattura.PNG (28.06 KiB) Viewed 198 times

If the user "carefully pay attention to constraints creation" the logic is brilliant and fast as You already noticed.
I.e. if the user fix the angle of that items, everything works and is stable.

The good news is that now the new logic is ready for subassemblies, You have only to concentrate on filtering and creating constraints_reduced and rigids_reduced. i.e. by using only constraints where Obj1 has all 6 degrees of freedom defined instead of current filter.

[kbwbe]

@Turro75,

thank you very much for your work and explanations. I will now read more of your code and try to understand it exactly.
My feeling says that your code will be merged next version.

[kbwbe]

@Turro75,

please HELP !

I am trying to reassemble my platform-testfile (attached again).
The file is my previous version i assembled before. It works with your optimized algorithm in this state.

When i delete all constraints and reassemble it following your rules, in early state solver failure happens.

Can you please test and confirm or post back correctly assembled platform ?
So i could have a look what i am doing wrong.