USER FORUM
(you are viewing a thread; or go back to list of threads)
Computationally optimal design in Solvespace (by Dave)
I am using Solvespace professionally - it works extremely well for basic stuff - but sometimes I have more complex models 10-20 megs big. As the design grows they require extreme patience for drawing single lines. I could be waiting 15 seconds for Solvespace to put down a red dot for the start of the line. Another 10 seconds for the line to update as I move the mouse.
I can't help thinking that the way I'm doing my design is causing this slowness. What is the best "workflow" to avoid this slow down or is it inevitable?
When drawing is is possible to force Solvespace to not attempt to perform constraints like point-on-point and point-on-line *while drawing*?
I'm guessing not having chains of dependencies helps. e.g. doing multiple extrusions that are each dependent on previous extrusions.
Dare I ask, would other 3D packages slow down this much?
I love Solvespace by the way. Sorry for all the questions.
I can't help thinking that the way I'm doing my design is causing this slowness. What is the best "workflow" to avoid this slow down or is it inevitable?
When drawing is is possible to force Solvespace to not attempt to perform constraints like point-on-point and point-on-line *while drawing*?
I'm guessing not having chains of dependencies helps. e.g. doing multiple extrusions that are each dependent on previous extrusions.
Dare I ask, would other 3D packages slow down this much?
I love Solvespace by the way. Sorry for all the questions.
(no subject) (by Paul)
Hi Dave,
Without seeing what you're doing I'm going to guess that your designs are stressing the constraint solver. If you have any way to build from source code you could try the pending solver changes here: https://github.com/solvespace/solvespace/pull/842
Barring that, you might ask someone to post a test build of that for your specific OS. I'm curious how much it helps you.
There are other parts of SolveSpace where performance suffers as the model grows and we are gradually working on those, but if sketching is slow it should either be the solver or a bug.
If the geometric complexity is killing performance you might also try increasing the "display chord tolerance" setting to a little higher value. Try doubling it. This will make your curves a bit more faceted but will increase performance in some areas - but probably not while sketching.
To your last question, No. Good commercial 3D packages currently scale better than SolveSpace. If you ask me the best-in-class tool is Inspire: https://www.altair.com/Inspire/
Without seeing what you're doing I'm going to guess that your designs are stressing the constraint solver. If you have any way to build from source code you could try the pending solver changes here: https://github.com/solvespace/solvespace/pull/842
Barring that, you might ask someone to post a test build of that for your specific OS. I'm curious how much it helps you.
There are other parts of SolveSpace where performance suffers as the model grows and we are gradually working on those, but if sketching is slow it should either be the solver or a bug.
If the geometric complexity is killing performance you might also try increasing the "display chord tolerance" setting to a little higher value. Try doubling it. This will make your curves a bit more faceted but will increase performance in some areas - but probably not while sketching.
To your last question, No. Good commercial 3D packages currently scale better than SolveSpace. If you ask me the best-in-class tool is Inspire: https://www.altair.com/Inspire/
(no subject) (by Andrew)
Where possible, keep parts in separate files, and bring them into an assembly file. When doing this, it is possible to have a construction file for key dimensions, and 'assemble' it into multiple latter files. Also note, it is necessary to open and save files to propagate changes up dependency chains.
(no subject) (by Dave)
I am running it on Linux. I build the latest version from Github source.
My drawing takes 75 seconds to load with and without the patches but thanks for suggesting them all the same.
With the patched version, after I have placed the first point of a construction line (in the same place each time), the green line takes 10 seconds to refresh when I quickly move the mouse to a different position on the screen. In this timed example, the unpatched version appears quicker (though maybe it's just luck that the refresh rate coincided with me clicking start on the stopwatch).
I would love to see a feature to disable constraint-matching when drawing lines etc. so that the lines themselves draw quickly and you can apply constraints later.
Please see attached image to get an idea of the complexity of my drawing.
My drawing takes 75 seconds to load with and without the patches but thanks for suggesting them all the same.
With the patched version, after I have placed the first point of a construction line (in the same place each time), the green line takes 10 seconds to refresh when I quickly move the mouse to a different position on the screen. In this timed example, the unpatched version appears quicker (though maybe it's just luck that the refresh rate coincided with me clicking start on the stopwatch).
I would love to see a feature to disable constraint-matching when drawing lines etc. so that the lines themselves draw quickly and you can apply constraints later.
Please see attached image to get an idea of the complexity of my drawing.
(no subject) (by Tom)
Can you split the drawing into more groups? But there's an option to "relax constraints and dimensions" too, in the property browser window.
(no subject) (by Koen Schmeets)
I assume you are compiling in Release mode?
-DCMAKE_BUILD_TYPE="Release"
And with OpenMP?
-DENABLE_OPENMP="ON"
Those make a big difference.
If you want you can share your project over here so we can try it out and profile it.
-DCMAKE_BUILD_TYPE="Release"
And with OpenMP?
-DENABLE_OPENMP="ON"
Those make a big difference.
If you want you can share your project over here so we can try it out and profile it.
(no subject) (by Paul)
What is your chord tolerance setting? Also, did you "force to triangle mesh" in any group?
(no subject) (by Dave)
Tom:
I have one assembly that is imported - this is the flat base in the drawing. I'm not really sure how else to split it into more assemblies (if that's what you mean) as most of the dimensions are dependent on the aforementioned flat base.
Koen:
Yes, I used Release.
I found this line in ./CMakeCache.txt: "ENABLE_OPENMP:BOOL=OFF"
so I just rebuilt the latest Solvespace with this enabled but it does not appear to run faster (and constraints matching for a single construction line does not seem faster).
Paul:
The imported flat base has "force NURBS surfaces to triangle mesh" enabled (no other extrusions though). I have disabled it and no "bad red stuff" appears so I will now leave it disabled.
Chord tolerance is "0.01%; 0.02mm, 37029 triangles". Should I increase this?
Is there any way I can profile it myself? I could share but suppose I'd prefer not to as it's for a work project.
I have one assembly that is imported - this is the flat base in the drawing. I'm not really sure how else to split it into more assemblies (if that's what you mean) as most of the dimensions are dependent on the aforementioned flat base.
Koen:
Yes, I used Release.
I found this line in ./CMakeCache.txt: "ENABLE_OPENMP:BOOL=OFF"
so I just rebuilt the latest Solvespace with this enabled but it does not appear to run faster (and constraints matching for a single construction line does not seem faster).
Paul:
The imported flat base has "force NURBS surfaces to triangle mesh" enabled (no other extrusions though). I have disabled it and no "bad red stuff" appears so I will now leave it disabled.
Chord tolerance is "0.01%; 0.02mm, 37029 triangles". Should I increase this?
Is there any way I can profile it myself? I could share but suppose I'd prefer not to as it's for a work project.
(no subject) (by Andrew)
You can create a construction drawing to define critical dimensions, and assemble that drawing into multiple components without any problems. Construction sketches can be extruded without creating a solid model, so that they can be used constrain actual components in other files.
(no subject) (by Paul)
@Dave
The new default chord tolerance is 0.1% That is a factor of 10 which means some operations will take 100x longer for you than if left at default. Most of those operations run in parallel if OPENMP is enabled in the build, but only for NURBS surfaces and not triangle meshes. Once any group in your sketch or assembly is forced to triangle mesh, every one after that is too. It is definitely preferable to stay with NURBS. Even though they may be displayed as faceted, NURBS surface are exported in STEP files as true curved surfaces. You can also set the export chord tolerance in mm when exporting to .stl or other non-step formats. The conversion to triangle mesh with be done at the time of export based on that setting. So higher chord tolerance can improve performance at the expense of visual quality, but it really is just visual.
Having said all that, I don't know why drawing a line would slow down. Do you have a terminal window open? Can you see it posting time to Generate the sketch periodically? We don't want solid geometry for any groups being regenerated while doing 2D sketching, but maybe that's happening? If so it will print in the terminal.
The new default chord tolerance is 0.1% That is a factor of 10 which means some operations will take 100x longer for you than if left at default. Most of those operations run in parallel if OPENMP is enabled in the build, but only for NURBS surfaces and not triangle meshes. Once any group in your sketch or assembly is forced to triangle mesh, every one after that is too. It is definitely preferable to stay with NURBS. Even though they may be displayed as faceted, NURBS surface are exported in STEP files as true curved surfaces. You can also set the export chord tolerance in mm when exporting to .stl or other non-step formats. The conversion to triangle mesh with be done at the time of export based on that setting. So higher chord tolerance can improve performance at the expense of visual quality, but it really is just visual.
Having said all that, I don't know why drawing a line would slow down. Do you have a terminal window open? Can you see it posting time to Generate the sketch periodically? We don't want solid geometry for any groups being regenerated while doing 2D sketching, but maybe that's happening? If so it will print in the terminal.
(no subject) (by Dave)
Okay Andrew, that sounds good for parts where I expect the dimensions to remain static and I believe I have done that here.
Paul, I have changed the chord tolerance back to 0.1%. I assume you mean that I should not force NURBS so I have disabled that. The drawing still takes 75 seconds to load and single line constraint matching is very slow.
I opened a terminal window and captured the output when it loads the file. Please see loadfile.txt attached. There are a LOT of messages like "Vector::WithMagnitude(x) of zero vector!"
I also logged additional messages when I try to move a construction line around (after making a single point-on-point constraint for it):
Generate::DIRTY (for bounding box) took 1349 ms
Generate::DIRTY took 4972 ms
Generate::DIRTY (for bounding box) took 1273 ms
Generate::DIRTY took 4846 ms
Generate::DIRTY (for bounding box) took 1415 ms
Generate::DIRTY took 5008 ms
Generate::DIRTY (for bounding box) took 1314 ms
Generate::DIRTY took 4896 ms
Generate::DIRTY (for bounding box) took 1400 ms
Generate::DIRTY took 4996 ms
Generate::DIRTY (for bounding box) took 1310 ms
Generate::DIRTY took 4903 ms
If it would really help I suppose I can post the file if the above is not sufficient for diagnosis.
Paul, I have changed the chord tolerance back to 0.1%. I assume you mean that I should not force NURBS so I have disabled that. The drawing still takes 75 seconds to load and single line constraint matching is very slow.
I opened a terminal window and captured the output when it loads the file. Please see loadfile.txt attached. There are a LOT of messages like "Vector::WithMagnitude(x) of zero vector!"
I also logged additional messages when I try to move a construction line around (after making a single point-on-point constraint for it):
Generate::DIRTY (for bounding box) took 1349 ms
Generate::DIRTY took 4972 ms
Generate::DIRTY (for bounding box) took 1273 ms
Generate::DIRTY took 4846 ms
Generate::DIRTY (for bounding box) took 1415 ms
Generate::DIRTY took 5008 ms
Generate::DIRTY (for bounding box) took 1314 ms
Generate::DIRTY took 4896 ms
Generate::DIRTY (for bounding box) took 1400 ms
Generate::DIRTY took 4996 ms
Generate::DIRTY (for bounding box) took 1310 ms
Generate::DIRTY took 4903 ms
If it would really help I suppose I can post the file if the above is not sufficient for diagnosis.
(no subject) (by Dave)
BTW, as you may be able to see above, the line draw update time is down to 5 seconds which I believe is due to increasing the chord tolerance.
(no subject) (by Andrew)
So long as you open and save dependent files, you can make changes to dimensions in construction drawing and propagate them up the file dependency chain, so there is no need to limit this approach to 'static' dimensions.. Such construction drawing only need to capture critical dimensions to constrain parts dimensions., and changes can be propagated to several components that are dependent on them. A useful tactic for keeping components in separate file for 3d printing projects, whilst still allowing an assembly drawing to see how it all fits together.
Also, can save and link a sketch to extrude, it just requires actual selection of the sketch plane for the extrude normal, which is useful for different lengths of a section.
Also, can save and link a sketch to extrude, it just requires actual selection of the sketch plane for the extrude normal, which is useful for different lengths of a section.
(no subject) (by Dave)
Hi, as requested here is a link to the project, now taking 90 seconds to load.
https://www.dropbox.com/s/rv15c8ppx6qpe91/web.zip?dl=0
If someone (Koen?) could profile it I'd be most grateful. I just want to get a handle on whether it's Solvespace or something I have done that is causing it to load so slowly.
Cheers and merry christmas.
Dave
https://www.dropbox.com/s/rv15c8ppx6qpe91/web.zip?dl=0
If someone (Koen?) could profile it I'd be most grateful. I just want to get a handle on whether it's Solvespace or something I have done that is causing it to load so slowly.
Cheers and merry christmas.
Dave
(no subject) (by Paul)
I had a look. I believe the problem is SolveSpace, although there are some things you could do to help. I noticed that the first 2 extrusions (one linked) could have been done as a single sketch/extrude. Later there are walls extruded up from the base with triangular holes cut out later. You could use a construction line - constrained perpendicular to some lines in the base - to define a vertical workplane. Draw a wall and the triangular cutouts in the workplane and extrude along the thickness of the wall. This saves doing a boolean difference and gets it done in fewer extrusions.
BTW going through group by group I had to "force NURBS to triangle mesh" at both g035 and g017. I left one with errors until I got to the other one. You only need to force the first one.
While I don't know where the performance problem is, it is not in the boolean code or the surface triangulation code. Those run in parallel and when this thing pauses for a while it is only running on one core. I suspect it's just a problem with the overall complexity of the model - SolveSpace has a few algorithms that don't scale well. OTOH dragging a line in a 2D sketch group should not be so slow - that still seems like a bug to me, like its running some of that slow code with each mouse movement.
BTW going through group by group I had to "force NURBS to triangle mesh" at both g035 and g017. I left one with errors until I got to the other one. You only need to force the first one.
While I don't know where the performance problem is, it is not in the boolean code or the surface triangulation code. Those run in parallel and when this thing pauses for a while it is only running on one core. I suspect it's just a problem with the overall complexity of the model - SolveSpace has a few algorithms that don't scale well. OTOH dragging a line in a 2D sketch group should not be so slow - that still seems like a bug to me, like its running some of that slow code with each mouse movement.
(no subject) (by cean)
I tried to only read the Triangles at the end of the file. It seems there is points inside a plane. Is it normal?
(no subject) (by cean)
67282 Triangles.
(no subject) (by Dave)
Hi Paul, thanks for taking a look. I think I'll have to try my luck at Freecad for more complicated stuff then. I do love the simplicity of Solvespace though and it really is easy to use.
Cean, I'm no expert on that but it does seem that a rectangular surface should only need 2 triangles to define it and the drawing has an excess of triangles.
Cean, I'm no expert on that but it does seem that a rectangular surface should only need 2 triangles to define it and the drawing has an excess of triangles.
Post a reply to this comment: