USER FORUM
(you are viewing a thread; or go back to list of threads)
Triangular holes in surface w/ spherical exclusions; as well as performance problems (by ELLIOTTCABLE)
Hey there! New to SolveSpace, and I'm experimenting w/ modelling an Apple display as a learning exercise.
I'm running into two issues:
1. the back-plane, which has (http://ell.io/ii/Mvs2rV) lots of spherical exclusions, seems to be unable to form a complete ("watertight?") surface. Are there any tips for me avoiding this issue with the solver? (screenshot: http://ell.io/ii/gA0N3X)
2. for similar reasons, the performance is absolutely _horrible_ — every single click/change/whatever requires around 120-150 seconds of calculation, with the app completely frozen. Are there any usage-pattern tips for improving the perf of models with a lot of step-translate-repeated boolean exclusions like this one? I'd love it if somebody could optimize my model and tell me what sorts of things I did wrong. (=
also re: https://github.com/solvespace/solvespace/issues/1186, feel free to use my model (CC-BY-SA 4.0) for performance testing in CI, if you wish.
I'm running into two issues:
1. the back-plane, which has (http://ell.io/ii/Mvs2rV) lots of spherical exclusions, seems to be unable to form a complete ("watertight?") surface. Are there any tips for me avoiding this issue with the solver? (screenshot: http://ell.io/ii/gA0N3X)
2. for similar reasons, the performance is absolutely _horrible_ — every single click/change/whatever requires around 120-150 seconds of calculation, with the app completely frozen. Are there any usage-pattern tips for improving the perf of models with a lot of step-translate-repeated boolean exclusions like this one? I'd love it if somebody could optimize my model and tell me what sorts of things I did wrong. (=
also re: https://github.com/solvespace/solvespace/issues/1186, feel free to use my model (CC-BY-SA 4.0) for performance testing in CI, if you wish.
(no subject) (by Daniel Engineering Solutions)
Well I'd love to help you out, but I cannot get the attached file to open at all. I'm not sure exactly how you modeled everything but it won't open on my computer. If you attach some screenshots I may be able to help.
(no subject) (by cmpxchg)
It seems to be a large grid-array like connector, with holes subtracted from a large slab, using many groups in a single file.
Perhaps one can try modelling each pin as a linked .slvs
file, using diff operator on the linked group, and have that 3d-object file step-translate horizontally, then step-translated vertically.
If it doesn't perform, tick 'suppress this group's solid model' of several groups and move on completing the high-level model.
Plus, one can detail the pin later and hope/tune on a successful non-NURBS-to-triangle mesh step file export.
Using a 3 or more level linked-slvs model should work too, but it seems that solvespace or the filesystem API it is using, sometimes seem to use a cached version of the .slvs file. One has to open and save each level to make sure the deepest linked .slvs file is properly represented in the highest-level document.
Perhaps one can try modelling each pin as a linked .slvs
file, using diff operator on the linked group, and have that 3d-object file step-translate horizontally, then step-translated vertically.
If it doesn't perform, tick 'suppress this group's solid model' of several groups and move on completing the high-level model.
Plus, one can detail the pin later and hope/tune on a successful non-NURBS-to-triangle mesh step file export.
Using a 3 or more level linked-slvs model should work too, but it seems that solvespace or the filesystem API it is using, sometimes seem to use a cached version of the .slvs file. One has to open and save each level to make sure the deepest linked .slvs file is properly represented in the highest-level document.
(no subject) (by ruevs)
Thanks for the interesting model.
The "Pro-Display-XDR-grid.slvs.zip" needs a 64 bit build of SolveSpace to open. The 32 bit version runs out of RAM. When it opens in takes literally minutes on my (old 8-th gen i5) machine to load.
The NURBS errors (red stuff and missing "pieces") are known and of the type that depends both on construction approach and the "chord tolerance (in percents)" and "max piecewise linear segments" settings. The reason is that sphere intersections are solved numerically. Reducing the tolerance makes the model finer (and slows it down even more).
As for construction approach - attached is my take. I avoid drawing the arcs in plane with the "slab" faces and this helps - but no fully. Also the model has much fewer spheres cut out so that is is manageable and opens in the 32 bit SolveSpace.
The "Pro-Display-XDR-grid.slvs.zip" needs a 64 bit build of SolveSpace to open. The 32 bit version runs out of RAM. When it opens in takes literally minutes on my (old 8-th gen i5) machine to load.
The NURBS errors (red stuff and missing "pieces") are known and of the type that depends both on construction approach and the "chord tolerance (in percents)" and "max piecewise linear segments" settings. The reason is that sphere intersections are solved numerically. Reducing the tolerance makes the model finer (and slows it down even more).
As for construction approach - attached is my take. I avoid drawing the arcs in plane with the "slab" faces and this helps - but no fully. Also the model has much fewer spheres cut out so that is is manageable and opens in the 32 bit SolveSpace.
(no subject) (by ruevs)
Well I solved it - the attached model does not have any "red stuff" (NURBS failures) but frankly the workaround is rather "perverse" :-)
Offtopic (by ruevs)
Who will ever wipe the dust from all those intersecting spheres?!
It looks cool, but is probably expensive to manufacture (anyway one triple pays for it) and impractical - Apple designers are... weird...
It looks cool, but is probably expensive to manufacture (anyway one triple pays for it) and impractical - Apple designers are... weird...
Post a reply to this comment: