Excellent news! We are getting closer to the manufacturers' reflexes.
I share this opinion.
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.Koemi wrote: ↑Fri Mar 23, 2018 10:42 amThe 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...
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.
As it improves things substantially. But as for this:
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.
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.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.
That's a nice feature to have. I'll think about it.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.
Well, using history is always the intention. I did read the papers and checked others code before starting.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.
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.
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).
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.I haven't looked into this yet, about the initial condition.
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.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.
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.That's a nice feature to have. I'll think about it.
Great. After you share your work hopefully @ickby will provide some feedback. And evaluating @ezzieyguywuf approach will get easier.Well, using history is always the intention. I did read the papers and checked others code before starting.