USER FORUM
(you are viewing a thread; or go back to list of threads)
Sudden slow-down (by Blinkenlight)
I noticed that sometimes trying to assemble a number of other sketches results in SolveSpace slowing down unbearably - it never actually becomes "unsolvable" / "over-constrained": it always comes back eventually to a responsive solved state, but _any_ further action (except simple viewing - 3D rendering stays smooth and fast) results again in up to 30 seconds of "non-responsiveness", lack of window repaint etc. each time. When this happens it's essentially impossible to continue work since even drag operations proceed in millimetric increments, with half-minute-pauses between them. This is not tied to a specific sketch that I could identify, and the hardware is otherwise perfectly capable of running SolveSpace smoothly as long as this is not happening.
Essentially my question is: whether or not this is a fixable issue, are there known causes that lead to this sort of behaviour, so that at least one could hopefully try to avoid them...? What is causing the seemingly incomparably larger workload?
Essentially my question is: whether or not this is a fixable issue, are there known causes that lead to this sort of behaviour, so that at least one could hopefully try to avoid them...? What is causing the seemingly incomparably larger workload?
(no subject) (by Jonathan Westhues)
Can you post an example that exhibits this?
An ill-conditioned set of constraints can be very slow to solve. The solver uses various heuristics to detect that, but perhaps they're not working here. The slowdown could also be in the NURBS Booleans, if you're dragging something outside the active group.
An ill-conditioned set of constraints can be very slow to solve. The solver uses various heuristics to detect that, but perhaps they're not working here. The slowdown could also be in the NURBS Booleans, if you're dragging something outside the active group.
(no subject) (by Blinkenlight)
It took quite some effort to replicate the problem, sorry for the relatively complex example but I could not reproduce it in any simpler form. In this example, 'Test4' loads in 4 seconds for me, but 'Test5' loads in 11 - and the interesting thing is that the only difference between the two files is the _value_ of a parameter in g006-sketch-in-plane (10 vs. 15 mm) that seemingly shouldn't affect anything in any significant way. It does though, and even if the difference is only a few seconds here, I've seen much longer delays - I just can't demonstrate one now. It's also interesting that even though the two files were saved immediately one after the other and only differ in one value, they're visibly quite different, even in size. Please note there's a suppressed section between the two endplates...
(no subject) (by Jonathan Westhues)
I believe the delays here are all in the solid model, not the constraint solver. The file size probably differs because you'd last regenerated at different zoom levels; the tolerance for the triangle mesh is constant in screen pixels.
To decrease those delays, you can use NURBS surfaces when possible, and put any imported parts that are triangle meshes towards the end of the assembly. It also helps to avoid Boolean operations in assemblies (like your extrude), and of course to avoid modeling unnecessary detail when possible (like the sort-of-threads on the bolts, maybe).
In any case, this seems different from what you describe above. When you observe that, are you dragging a point from an earlier group when a later group is active? That requires the entire model between those two groups to regenerate, which is why most CAD programs don't let you do that.
SolveSpace does, but if the model is nontrivial then the result will be really slow. To avoid that, just activate the group that contains the point that you're dragging.
To decrease those delays, you can use NURBS surfaces when possible, and put any imported parts that are triangle meshes towards the end of the assembly. It also helps to avoid Boolean operations in assemblies (like your extrude), and of course to avoid modeling unnecessary detail when possible (like the sort-of-threads on the bolts, maybe).
In any case, this seems different from what you describe above. When you observe that, are you dragging a point from an earlier group when a later group is active? That requires the entire model between those two groups to regenerate, which is why most CAD programs don't let you do that.
SolveSpace does, but if the model is nontrivial then the result will be really slow. To avoid that, just activate the group that contains the point that you're dragging.
(no subject) (by Blinkenlight)
Thanks for the pointers, I'll try to make god use of them. I had a sneaking suspicion NURBS <-> triangles may have a contribution, I was using triangles as a result of SolveSpace complaining about interference during modelling which seemed to go away if I restricted to triangles.
As for the details yeah you're absolutely right - it's just I'm in the "let's see what can I get away with" phase of discovery with SolveSpace and the not-quite-threads seemed like a clever answer to the inability to model actual threads that I have been reading about; of course, they aren't really practical, just something my OCD insists on... :)
As for the dragging part, it's quite possible I was doing that, I have no idea - obviously, I'm not really a pro CAD person which is exactly why I like the ease of use of SolveSpace and what it enables even an idiot like me to achieve. Thanks again for all the advice!
As for the details yeah you're absolutely right - it's just I'm in the "let's see what can I get away with" phase of discovery with SolveSpace and the not-quite-threads seemed like a clever answer to the inability to model actual threads that I have been reading about; of course, they aren't really practical, just something my OCD insists on... :)
As for the dragging part, it's quite possible I was doing that, I have no idea - obviously, I'm not really a pro CAD person which is exactly why I like the ease of use of SolveSpace and what it enables even an idiot like me to achieve. Thanks again for all the advice!
(no subject) (by Blinkenlight)
Well, I just found out where I got the "restrict to triangles" idea - the holes in the end plates simply don't "punch through" the plate without it. In the attached example, one hole goes through correctly while the other one does not - it seems simply because the second doesn't have a perfectly cylindrical "bore" (restricting to triangles makes both holes work). Is this intended behaviour? If so, would there be a workaround?
(no subject) (by Jonathan Westhues)
That's not intended behavior, but Booleans on surfaces of revolution will sometimes fail. The performance impact of one triangle-mesh part will be small if it's the last one in the assembly, though.
Post a reply to this comment: