Assembly3 preview

[emills2]

The downside maybe that the speed gain is only noticeable when the system is large enough, and may have negative impact otherwise.

That's very true in regards to speed, but once again, this has shifted the issue to solver performance. I was speaking only from the perspective of solvability and stability: putting the solution in reach of imperfect solvers, and not allowing a solver to scramble what is known to be solved (and provably known to be solved).

once again, it's a gradual approach:
1 filter LCSs,
2 filter 3 orthogonal planar constraints,
3 stop here if you want. don't accept new filters unless they can be shown to improve performance.

the LCS situation just opens the box, and makes it straight forward to add new filters later (in my head...and i'm not the one doing the work)

this brings back the topic of what the end game is: cool demo models or airbuses/robots/entire factories.

[emills2]

anyway, it was just an idea based on the direction you seemed to be headed. i have no beef really. if you have a solver that's so good you can just throw the LCSs into as 3 planes / 3 points / plane+line+point instead of filtering rigid bodies, by all means, don't waste time pre-processing.

from my limited understanding FEA has the same issue: you can pre-condition a problem to dramatically reduce solution time....but the pre-condtioning might take longer than solving the raw problem

Edit: it seems to leave you with a coin toss...where one side is more work than the other...but it is NOT! the two strategies will not have the same success ratios

so while a solve everything algorithm may be faster when it works, i have a feeling that feels logical, that says "less pieces will have a higher success rate with the same solver", and that's more important than speed of easy cases

[emills2]

We can try naive algorithm first, something like, once found three plane constraints between two parts, solve a system with just these two, and if no DOF left, treat as single part

actually i had imagined full vetting of the 3 plane constraints, before passing it to the 'local pair' solver:
-get the normal vectors for all 3 constraint planes, n1, n2, n3
-test n1Xn2 == 0
-test n1Xn3 == 0
-test n2Xn3 == 0
-if any test is true, reject the part as rigid, the constraints are malformed/redundant and misleading.

if you perform this test for each constraint, at the moment it is added, for both(all) parts it touches, there is near 0 delay for pre-processing from the user's point of view.

i usually add my constraints one at a time. if i update my parts, but don't change the constraints, when i go back to the assembly, there are many constraints to update. you would need to run the rigidity test on all parts that have changed, since formerly non parallel planes could have become parallel. once again, you can filter these out before running a local solver.

[Zolko]

Hello realthunder,

I very much like the "mover" feature of Assembly 3, but I'm not sure where to find the corresponding code. I'd like to take that feature and adapt it to Assembly 4, because that is a missing piece: being able to import a part, and then move it around in the assembly "by hand" interactively. In AWS (or Asm4) there is an App::Placement called 'Offset' for each part, that must be edited and parameters set numerically, but that placement could also be manipulated by the dragger in the same manner as in Asm3. This would be a very useful feature, and combined with the LCS snapping would allow to create quite complex assemblies very easily.

Would you be willing to tell where to find the corresponding code ? And may-be how to use it ? Does it use some dark magic specific to Asm3 or do you think it could be adapted to Asm4 (and its pure App::Part and App::Link objects) ?

Asm3_mover.png (338.07 KiB) Viewed 1922 times

[jpg87]

...

Hello,
I read this thread from time to time, but I'm not sure I understand all the details. This is why I allow myself to describe how I perceive the assembly WB (or maybe how I imagine it!).


How Asm3 works
1- Creation of a subassembly
I work mainly from functional geometry (real surfaces of solids).
Moreover, in an assembly, Asm3 could ignore by default the exact definition of "secondary" surfaces that have no chance of being designated as functional (surfaces with draft, surfaces from B-splines, etc .: filtering to be defined with options checked by the user) ...
Asm3 tools are perfect for building a sub-assembly in "surface contact, coaxiality ..." mode as I like, and the solver does its job.
2- Creating a higher-level assembly
When creating a higher level assembly A, the subassemblies A1, A2, A3, ... are considered as unique blocks in A. The solver ignores the internal constraints between the elements of the subassemblies A1, A2, A3, ... and solves only the constraints between the subassemblies imported into A.
So on if multi-levels are needed.
Asm3 retains only the simplified geometries of the subassembly objects, for example the functional surfaces already used between the sub-assemblies of the last active level, and the reopening of the general file, does not need to reopen the component files .
3- Any changes
If for various reasons I have to modify a sub-assembly of lower or intermediate level, I activate this subassembly, and the solver takes into consideration only the internal constraints of this subassembly. FC reads only the data of the functional geometry known in this subassembly.
If I need to use new functional surfaces, designating them in the 3D window forces Asm3 to re-read the higher definition level of the designated object.
4- After an external update of a component
Work in any assembly may require an automatic update subject to validation or caused by the user, modified component (s), after detection by FC of date change or size of component files.


Can you tell me if my perception is close to the reality of Asm3 (or its future?) and what I did not understand?

Thank you in advance.

[wsteffe]

-get the normal vectors for all 3 constraint planes, n1, n2, n3
-test n1Xn2 == 0
-test n1Xn3 == 0
-test n2Xn3 == 0

Collinarity of a couple of normals is a sufficient but not a necessary condition for linear dependence.

Apart of that you are trying to check the linear independency of the 3 complanarity contraints introduced by a single attachment (or mate).
You should instead check the linear independency of the big system arising from the constraints associated with all mates.
One possibility would be trying to solve that big system but I think it could be handled more efficiently with a proper restriction/selection of admissible connectors + graph theory and some euristc.

The paper link (http://graphics.tudelft.nl/~rick/pdfs/solving.pdf) mentioned by realthunder was in a different thread (assembly without solver).

[emills2]

Collinarity of a couple of normals is a sufficient but not a necessary condition for linear dependence.

absolutely. but i'm just suggesting using simple reliable heuristic, NOT a complete mathematical solutions. this could to improve solver reliability on real hardware now, as opposed to on paper. research is great. practical applications are great too.

once again, perfect is the enemy of good.

the engineering solution to the halting problem: 'if the program runs too long, hit the computer with a stick until the program stops.'

[wsteffe]

perfect is the enemy of good.

Yes, I too agree with this principle.

Nevertheless I think that there are some requirements which should be met also in the most pragmatic approach.
One, in my opinion, is the linear independence of the set of mates (or connectors which I prefer as a term).

You may give up with the requirement on the maximality of the set of independent connectors. I mean it is not so important if the
identified set of connectors is not maximal (so that it could be extended without breaking the linear independence).
But it is very important to verify that it is composed of independent connectors.

This could be done very simply if we restrict our attention to the rigid connectors (that it connectors which establish e rigid connection between
a couple of bodies). In this simple case the rigid connectors are linearly independent if the corresponding graph (with vertex associated with bodies and branches associated with rigid connections) does not contain any loop (it has a tree-like structure).

This simple heuristic doesn't work any more when you extend the set of admissible connectors. In example it breaks if you add sliding connectors which fix all the relative DOFs with the exception of a translation in a given direction. But it may be the case that a more complex heuristic could be found to be valid also in this generalization.

But perhaps, following the most pragmatic approach, it could be sufficient to restrict the identification (with elimination of related DEFs) to the sets of rigid connectors because these are probably the most common connectors and because their linear independence can be easily checked trough a simple loops search in a graph.

[Mark Szlazak]

-get the normal vectors for all 3 constraint planes, n1, n2, n3
-test n1Xn2 == 0
-test n1Xn3 == 0
-test n2Xn3 == 0

Collinarity of a couple of normals is a sufficient but not a necessary condition for linear dependence.

Apart of that you are trying to check the linear independency of the 3 complanarity contraints introduced by a single attachment (or mate).
You should instead check the linear independency of the big system arising from the constraints associated with all mates.
One possibility would be trying to solve that big system but I think it could be handled more efficiently with a proper restriction/selection of admissible connectors + graph theory and some euristc.

The paper link (http://graphics.tudelft.nl/~rick/pdfs/solving.pdf) mentioned by realthunder was in a different thread (assembly without solver).

I started a thread over a years ago where i collected links to papers related to geometric constraint solver research here:

https://forum.freecadweb.org/viewtopic.php?f=8&t=26737

[realthunder]

In AWS (or Asm4) there is an App::Placement called 'Offset' for each part, that must be edited and parameters set numerically, but that placement could also be manipulated by the dragger in the same manner as in Asm3. This would be a very useful feature, and combined with the LCS snapping would allow to create quite complex assemblies very easily.

You want to drag an App::Placement? Just right click the item in the tree view and select 'Transform'. Or is there other thing you want?