I agree. Speeding up factor 50..100 using low level programming language is always possible. It would be much faster. But we should improveTurro75 wrote: ↑Sun Jul 15, 2018 8:47 pm
1) the solver is effective but slow (actually python on my laptop is slow), since it is pure math it would make sense rewriting calcmovedata and moverigids in c++ or freepascal and use them as external dll overriding the overhead due to python's slowness, I'm confident it will boost a lot the solving timing allowing a better precision and increasing the number of max steps.
solver logic first with python, as prototyping and testing is possible in shorter time. When new logic is perfect, we should think about further steps.
I had some applications in other projects, where pure python solution was kept alive as it was finally fast enough. (With a lot of tricks)
Your code regarding solving partial systems is good and understandable. I think, the simple father/son relation is not enough. The "tempfixing" requirements are at some higher level. The constraints relations between rigids/parts have to be analyzed in a more sophistical way, as looking forTurro75 wrote: ↑Sun Jul 15, 2018 8:47 pm
2) the idea to split the assembly in several sub assemblies to lower the load on solver isn't so bad, I'm thinking about determine if an obj is fully constrained to its father (all 6 DOF locked to the father)so creating a part container of both and use the container as boundbox reference. after the system is fully solved, simply delete the part container keeping globalplacement of sub objects. In theory it would work but I'm not so confident on future of part containers.
for constraint loops which are feeding back to fixed parts. So subsystems to solve will become some bigger, but there will be still an effect speeding up the system and increasing accuracy. I think the solution will be a mix of your approach and my old one.