USER FORUM
(you are viewing a thread; or go back to list of threads)
System Resources/Memory Usage (by Roland Frank)
Hello.
I am curious (and eager to learn something) :-)
I am running Solvespace on a Windows 7 64-bit System.
Haswell i5-4570 CPU, 8 GB RAM.
Quite an up-to-date System I would say ...
I designed attached (Casino) Dice.
It takes quite long to load and seems to nearly crash the system ...
Is the number of constraints a "problem" ?
Or does it take so much time because i used a lot of
Operations resulting in small Faces ?
Have you already experienced some "frontiers" with
Solvespace ?
Is there a (theroetical) limit concerning file size
and/or number of facets and/or number of constraints ?
Thanks for Response/Feedback.
Roland
I am curious (and eager to learn something) :-)
I am running Solvespace on a Windows 7 64-bit System.
Haswell i5-4570 CPU, 8 GB RAM.
Quite an up-to-date System I would say ...
I designed attached (Casino) Dice.
It takes quite long to load and seems to nearly crash the system ...
Is the number of constraints a "problem" ?
Or does it take so much time because i used a lot of
Operations resulting in small Faces ?
Have you already experienced some "frontiers" with
Solvespace ?
Is there a (theroetical) limit concerning file size
and/or number of facets and/or number of constraints ?
Thanks for Response/Feedback.
Roland
(no subject) (by Jonathan Westhues)
The constraints in that model are simple; those should be a very small fraction of the total time to regenerate. Typical mechanical drawing won't usually push the limits of the constraint solver, as long as some attention is paid to the structure of the model. When you do have trouble, as you may, for example, with complicated mechanisms, the problem is usually non-convergence or unexpected solutions, not correct but slow response.
By default, we model surfaces as NURBS. SolveSpace's implementation of that is fairly robust for most surfaces of extrusion, but not for surfaces of revolution like the spherical edges on your model. You've therefore fallen back to a triangle mesh model.
Boolean operations on triangle meshes are conceptually simpler, but painful in practice. Each triangle split increases the number of facets and edges in the model, and increases the probability that a triangle with bad aspect ratio will form. Due to the limitations of fixed-precision computer arithmetic (like normal floating point, which SolveSpace uses), those triangles tend to break. It's possible to refine the mesh to fix those, but SolveSpace doesn't do that.
In summary: The constraint solver usually works pretty well, and surfaces of linear extrusion usually work pretty well. More complicated surfaces are dodgy.
By default, we model surfaces as NURBS. SolveSpace's implementation of that is fairly robust for most surfaces of extrusion, but not for surfaces of revolution like the spherical edges on your model. You've therefore fallen back to a triangle mesh model.
Boolean operations on triangle meshes are conceptually simpler, but painful in practice. Each triangle split increases the number of facets and edges in the model, and increases the probability that a triangle with bad aspect ratio will form. Due to the limitations of fixed-precision computer arithmetic (like normal floating point, which SolveSpace uses), those triangles tend to break. It's possible to refine the mesh to fix those, but SolveSpace doesn't do that.
In summary: The constraint solver usually works pretty well, and surfaces of linear extrusion usually work pretty well. More complicated surfaces are dodgy.
Thanks ... (by Roland Frank)
Hello Jonathan.
Thanks for the detailed reply.
Roland
Thanks for the detailed reply.
Roland
Post a reply to this comment: