This is by far my favorite CAD program for quick engineering-oriented designs.
But it's not without its bugs, and frankly the performance seemed to steadily deteriorate as more of the code was "cleaned up" to use more modern C++/STL stuff over the years.
I use a local fork from an older release that instead diverges even further away from using C++ crap in a very performance-sensitive area (the IdList indexing is done ad-hoc) and it's been far more usable for the large-ish models I tend to work on (designing sheds/roofs and cabin structures). The same models I work efficiently on are basically impossible to work with in current upstream releases (when I last tried them, admittedly pre-pandemic so years ago), almost every operation becomes a many-second stall.
Edit:
My local fork is based on Alexey Egorov's changes @
That ID list change never made it in and AFAICT it isn't known to be complete. The performance gain was huge though. We have made a lot of progress on performance over the last couple years and it's way better than the old 2.3 version. Version 3.1 incorporates Eigen for matrix operations in the solver - another old contribution by Alexey Egorov that we finally merged.
I don't think the problem is really the ID list implementation, but algorithms with O(n*2) time complexity. Evey time we improve the ID list by a decent amount someone just adds a few more components or whatever and it slows down again.
It does look like they finally improved the IdList in 2021 according to [0]. When I have time I'll give it a spin on some of the models I was last working on.
The last time I went down this path, IIRC the interactivity had improved substantially even on large assemblies, but a bunch of new bugs had been introduced. So I just stayed on the old branch with the indexing fix, it's been relatively bug-free for the stuff I do. From what I recall even just picking lines/points/faces with mouse clicks had become unreliable and inconsistent in the last new release I tried, it was very broken.
That makes me sad. We aim to avoid introducing bugs. I am aware of one open NURBS issue that is an actual regression where the model works in version 2.3 but not 3.0. Of course it may be affecting others too and we just haven't been told.
It saddened me at the time as well, and normally I would have spent substantial time working with upstream to try fix such regressions.
But between being busy rebuilding my home's roof structure at the time, which is what I was trying to use SolveSpace to assist in, and being generally frustrated with the seeming lack of interest/prioritizing the kinds of performance regressions and general scalability limits my use case kept encountering, I spent less effort working with upstream. I was doing quite large assemblies of stick-frame structures, and it seemed most users were doing simple models for 3D printing.
Another factor around that era was whitequark had abruptly quit SolveSpace maintenance, and seemed to be the only active person at the time. We'd often chatted about issues in IRC and they were usually super helpful, when they told me they were no longer involved I kind of gave up hope.
Glad to see things seem to have rebounded since, and my roof is all done so maybe I'll retry some of the things I was tripping over bugs attempting, using the latest release.
>> Another factor around that era was whitequark had abruptly quit SolveSpace maintenance, and seemed to be the only active person at the time.
Whitequark said the project was in (several) good hands and called me out by name. Jonathan then contacted me to kind of formalize my promotion and my first action was to invite several important contributors to the "solvespace organization" on github. They aren't super active but made important contributions, and I feel like I can call on them for issues in specific areas and they respond as well as I could hope for OSS volunteers. The project seems much more secure as a result, while development remains slow but steady ;-)
But it's not without its bugs, and frankly the performance seemed to steadily deteriorate as more of the code was "cleaned up" to use more modern C++/STL stuff over the years.
I use a local fork from an older release that instead diverges even further away from using C++ crap in a very performance-sensitive area (the IdList indexing is done ad-hoc) and it's been far more usable for the large-ish models I tend to work on (designing sheds/roofs and cabin structures). The same models I work efficiently on are basically impossible to work with in current upstream releases (when I last tried them, admittedly pre-pandemic so years ago), almost every operation becomes a many-second stall.
Edit:
My local fork is based on Alexey Egorov's changes @
https://github.com/Evil-Spirit/solvespace-master/tree/id-lis...