SOLVESPACE -- parametric 2d/3d CAD
Examples
Tutorials
Features
Download
Reference
Technology
Library
Forum
Contact
USER FORUM

(you are viewing a thread; or go back to list of threads)

Complaint/suggestion about assembly (by Dax)
My problem with Solvespace is that once you start assembling things, you lose the ability to change their parameters.

Suppose for example your assembly consists of L profiles with holes cut on each end, and they come in different lengths, so you make one truss where the length is unconstrained, and then save it to a file. Then you start anew, import the file and start assembling your thing Ė but oh, you canít change the parameters of the imported parts. Theyíre now static geometry.

You can open the file of that part and change the length there, but you canít change it while youíre assembling them together, so you have to know in advance the lengths of every single truss in your assembly, and save them in separate files, every single one, even if theyíre the same size, to give you the provision to modify one in case you need to.

Thatís incredibly cumbersome and unconstructive for experimenting with different configurations. Why canít I change the unconstrained parameters of the imported part by giving the part more constraints? Itís a generic truss, or a generic model of a bolt or something, why canít I just import it and then give it a definite length after the fact?



Suppose you want to model a small truss bridge for the moat of your house, or youíre putting skirting board around the walls.

The whole assembly might have hundreds of parts, so it becomes painfully apparent why you need to have a generic model of a piece that can be modified during assembly to produce the unique parts.

In programs like Sketchup3D, you have groups which behave like static objects relative to other groups in the same way as the imported objects in Solvespace behave, but which can still be modified internally while in assembly. You can have multiple instances of an object, which all change when you modify one, and then you can pick one instance and make it unique, which basically conjures a copy of the group which you can then independently modify.

In Solvespace you are starting from and constantly operating on a level that matches a single object (group) in Sketchup3D. Itís actually counter-intuitive and downright wrong to make an ďassemblyĒ at this level of hierarchy because you are in fact working inside a single object, a single part.

To make an assembly, we should take a step higher up in the hierarchy tree. What we currently have is

active
|-g0001
|-g0002
|-etc...

what I would need is

assembly
|-active #1
|-active #2
|-etc...

If you get what I mean. An instance of an object should show up as a new "active" where the internal groups are still available to modify.
Sat Feb 6 2016, 10:32:47
(no subject) (by Dax)
Now, I realize I can edit a part and then hit "regenerate all" while I'm doing assembly, but that's not the same thing at all.

Here for example, I'm designing a picture frame (attachment)

The vertical (leftmost) member is the original extrusion, and the horizontal members are saved and imported copies of that. I can still click and drag the vertical member to change its length until I'm satisfied with it, and then constrain it to whatever nearest nice measure.

In order to change the horizontal members, I need to have a second instance of Solvespace open, change the constraint there, save, go back to the assembly instance and hit regenerate, and if I don't like what I see then re-iterate. This is cumbersome.

You can also see the frame is missing the fourth side. That is because I cannot have a second instance of the vertical member that would change in length when I modify the first.

In order to have that, I would need to have three instances of Solvespace running, and three files: one for the assembly, one for the vertical members, one for the horizontal members. I would then need to jump between these instances to change parameters and regenerate the assembly to see how it looks like.

That's not very optimal.
Sat Feb 6 2016, 11:53:40, download attachment solvespace.png
(no subject) (by Jonathan Westhues)
A lot of what you propose is desirable behavior; it's just a lot more work to implement. You may find that some of what whitequark et al. are working on gets you closer to that.
Tue Feb 9 2016, 15:57:19
(no subject) (by whitequark)
This is almost exactly what I have planned. Unfortunately this requires a fairly massive refactoring of the way sketches are handled internally, so this won't land for a while. But you will surely get it.
Wed Feb 10 2016, 09:36:38
Post a reply to this comment:
Your Name:
Your Email:
Subject:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):
© 2008-2018 SolveSpace contributors. Most recent update Nov 22 2018.