Assembly3 preview

[realthunder]

I have added my own logic to auto relax/skip redundant composite constraints. Now multi-PlaneAlignment should be even more reliable. And multi-PlaneCoincident works, too.

The order of appearance of the constraints determines how redundancies are handled.

PlaneCoincident: the second PlaneCoincident of the same pair or parts is relax to a 2d points horizontal or vertical constraint. The third and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any pre-existing PlaneCoincident or AxialAlignment.

PlaneAlignment: the second one is relaxed to two PointInPlane or PointPlaneDistance constraint. The third one is relaxed to one PointInPlane or PointPlaneDistance. The forth and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any existing PlaneCoincident or AxialAlignment.

AxialAlignment: ignored if there are any existing PlaneAlignment or PlaneCoincident constraints

These rules are only heuristics, and can still lead to inconsistent result if your specify the constraints "too wrong", e.g. two plane coincident on two different planes, or two plane alignment on the same plane.

In the following screencast, I've turned off auto re-solve at the beginning, because it is kind of hard to select elements for the second PlaneCoincident if they snapped together. Once the second one is created and snapped, you can see that there are two solutions when I dragged the parts. Because, according to the logic above, the points horizontal/vertical constraint can indeed be satisfied at two different locations. In fact, if you consider plane orientation, there are more solutions. This is a thing with SolveSpace that you should probably be getting used too. It is better to be under constrained than over constrained.

[Koemi]

The screencast you have added is 'in real life' not realisitic. Linking two circles on the same plane should normally result in zero DOF (considering one part is fixed/locked). Now there is still one DOF that can not excist. To my very humble opinion that is...

That said; keep up the good work! You're doing an amazing job realthunder, I love to see the Assembly3 WB getting 'mature'. I follow this thread with great interest.

[jpg87]

I have added my own logic to auto relax/skip redundant composite constraints. Now multi-PlaneAlignment should be even more reliable. And multi-PlaneCoincident works, too. ...

Excellent news! We are getting closer to the manufacturers' reflexes.
If you only constrain the centers of the last two circles, would that eliminate the problem of the 2 position possibilities?

keep up the good work! You're doing an amazing job realthunder, I love to see the Assembly3 WB getting 'mature'. I follow this thread with great interest.

I share this opinion.

[realthunder]

The screencast you have added is 'in real life' not realisitic. Linking two circles on the same plane should normally result in zero DOF (considering one part is fixed/locked). Now there is still one DOF that can not excist. To my very humble opinion that is...

There is really no DOF left in this case. When we talk about DOF, the emphasis is on 'F'. There are multiple solutions, yes, but no 'Free' variables. The multiple solution is inevitable in this kind of inverse problem, like given an angle, since we write equation using sine or cosine, there bound to be multiple solutions satisfy the equation. In fact, the two solutions found by the horizontal constraint are the same positive and negative angles between the two associated parts.

This also answers the following questions.

If you only constrain the centers of the last two circles, would that eliminate the problem of the 2 position possibilities?

In theory, to disambiguate this kind of problem, one must ask the solver for all possible solutions, and compare the solution to the desired positions. I guess this may complicates solver implementation quite a bit.

[triplus]

I would suggest for this to stay enabled:

It turns out that SolveSpace allows redundant constraints.

As it improves things substantially. But as for this:

I have added my own logic to auto relax/skip redundant composite constraints. Now multi-PlaneAlignment should be even more reliable. And multi-PlaneCoincident works, too.

To get removed as "auto relax" results in this (fourth PlaneAlignement constraint added):

PlaneAlignment.png (11.09 KiB) Viewed 631 times

Lets just leave this things to SolveSpace solver and to the way it works? As the general problem was too strict redundant constraints policy and not composite constraints?

You once said there is a setting you could expose. That determines on how robust SolveSpace solver is to "initial conditions". This is something that makes sense to me. And after i guess use cases and feedback should drive the maturing of the Assembly 3? I read some info and i guess SolveSpace solver doesn't use sparse matrix decomposition ATM. Therefore if we end up using it for a while. There is still room for future speed improvements in large assemblies. But i guess lets first see how things evolve around Assembly 1 strategy.

As for Link effort. The way i see it one thing is still missing. In use cases where you create a Link to geometry in external file. And there is substantial amount of "design history" in that file. Or in use cases where you need to have a big number of "part documents". There should be a way (one example of a solution to the problem being Assembly 2 import feature). Where only the "subset of geometry" would get loaded and documents wouldn't need to be opened at all. Or it would be opened only to extract a "subset of geometry" to crate a Link feature and after to be closed.

As for Topology effort. If i am correct in assuming you are now after history and geometry based solution. I feel that if that is correct. My guidance likely came to an end and @ickby should take over.

[realthunder]

To get removed as "auto relax" results in this (fourth PlaneAlignement constraint added):

Could you please attach the file that shows this problem? SolverSpace redundant constraint tolerance is still on. My logic only handles some specific combinations of my added composites.

You once said there is a setting you could expose. That determines on how robust SolveSpace solver is to "initial conditions". This is something that makes sense to me. And after i guess use cases and feedback should drive the maturing of the Assembly 3? I read some info and i guess SolveSpace solver doesn't use sparse matrix decomposition ATM. Therefore if we end up using it for a while. There is still room for future speed improvements in large assemblies. But i guess lets first see how things evolve around Assembly 1 strategy.

I haven't looked into this yet, about the initial condition. As for the speed, the easiest speed up is to move the entire asm3 code to C++, then we can have roughly the same response speed as SolveSpace CAD itself. But I don't think that's worth it at the moment. Ideally we shall make our own solver work first, or find another one with a compatible license.

As for Link effort. The way i see it one thing is still missing. In use cases where you create a Link to geometry in external file. And there is substantial amount of "design history" in that file. Or in use cases where you need to have a big number of "part documents". There should be a way (one example of a solution to the problem being Assembly 2 import feature). Where only the "subset of geometry" would get loaded and documents wouldn't need to be opened at all. Or it would be opened only to extract a "subset of geometry" to crate a Link feature and after to be closed.

That's a nice feature to have. I'll think about it.

As for Topology effort. If i am correct in assuming you are now after history and geometry based solution. I feel that if that is correct. My guidance likely came to an end and @ickby should take over.

Well, using history is always the intention. I did read the papers and checked others code before starting.

[GlouGlou]

A lot of hours Im searching. Could you help me to make the final constraint? Rod must be straight housed in the hole.
Have a look inside the pin rod assembly, i succeed to use a shape2D while i haven't the sketch.
OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.5235 (Git shallow)
Build type: Release
Branch: (HEAD detached at FETCH_HEAD)
Hash: f405cbcfb65f681366cf4ff09518cc4b95d19c99
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Locale: French/France (fr_FR)

[realthunder]

A lot of hours Im searching. Could you help me to make the final constraint? Rod must be straight housed in the hole.
Have a look inside the pin rod assembly, i succeed to use a shape2D while i haven't the sketch.

You are making things too complicated. I've deleted everything leaving only the bodies. You have the sketch containing the circle to create the rod, which is perfect for use as constraining element. Using Axial Alignment along is enough. It accepts more than two elements, so you can conveniently add more elements aligning on the same axis. BTW, Plane Coincident/Alignment/Parallel all support multiple elements.

[GlouGlou]

I agree with that. But its not possible to use clones?

[triplus]

SolverSpace redundant constraint tolerance is still on. My logic only handles some specific combinations of my added composites.

Yes. When you enabled redundant constraint tolerance. PlaneAlignment started to work more like Assembly 2. Composite constraints didn't cause solver troubles anymore as before. After you added the additional logic to handle composite constraints. I got results as seen above. I didn't save the original file therefore i made a new one and attached it. Notice that it only took 2 PlaneAlignment constraints this time for things to start misbehaving. In addition try to delete a cube from assembly (FreeCAD crash).

I haven't looked into this yet, about the initial condition.

From general point of view. If this area could improve a bit. Likely that would be that. Everything else i guess is more or less in OK state now. Maturing and relations related discussions should likely happen based on use case feedback going forward.

As for the speed, the easiest speed up is to move the entire asm3 code to C++, then we can have roughly the same response speed as SolveSpace CAD itself. But I don't think that's worth it at the moment. Ideally we shall make our own solver work first, or find another one with a compatible license.

Note that i didn't complain about the speed. I just researched a bit on where SolveSpace is ATM. And it has still potential to get faster. As for what we will do in the future. End up using SolveSpace for a while, write our own solver or do something else. I don't know. What i do know is Assembly 3 likely will end up being a good option. And from user point of view the license is compatible.

That's a nice feature to have. I'll think about it.

Good to hear that. This is basically what "the core" feature of a "Link" effort i guess is. At least the discussion in the past (before the Link effort) went in this direction. On how it would be nice to have something like that.

Well, using history is always the intention. I did read the papers and checked others code before starting.

Great. After you share your work hopefully @ickby will provide some feedback. And evaluating @ezzieyguywuf approach will get easier.