USER FORUM
(you are viewing a thread; or go back to list of threads)
Constraints suggestion (by Gijs van Oort)
Dear Jonathan,
Very nice program!
I have a suggestion about managing constraints. Assume you have a sketch in which multiple line segments have the same length (or, multiple points are coincident, or multiple lines are parallel, or whatever). At the moment, this needs multiple constraints, each one 'connecting' two line segment lengths to each other. Which line segments exactly are chosen is not relevant (for 3 lines, you could for example connect A-B, A-C, or A-B, B-C). Things become different if you decide to remove (or destructively edit) one line (say line A). In the first case, all constraints are lost, even the fact that B and C should have the same length. In the second case B and C will still be connected, which is probably what you wanted.
A solution for this would be the following suggestion:
Instead of having two separate sets of constraints (A-B, A-C), group all these constraints into one multiple-element constraint, i.e., constraining A-B-C at once. Now, if you remove line A, B and C are still connected. If you remove B, A and C are still connected. Removing a constraint simply removes the selected element from the group. Duplicating an element (e.g. a line segment) may add all constraints to the group (no need to choose one counter-element 'at random').
Furthermore, it may be possible to handle constraints more intelligently when splitting elements. For example, if you split two intersecting line segments, you could apply a coincidence constraint to all four endpoints at the intersection (A-B-C-D). The user can then remove any two of the four resulting line segments, and the two remaining line segments will still be connected to each other by the constraint.
I wonder what your opinion is on this!
Best regards,
Gijs van Oort,
Enschede, The Netherlands
Very nice program!
I have a suggestion about managing constraints. Assume you have a sketch in which multiple line segments have the same length (or, multiple points are coincident, or multiple lines are parallel, or whatever). At the moment, this needs multiple constraints, each one 'connecting' two line segment lengths to each other. Which line segments exactly are chosen is not relevant (for 3 lines, you could for example connect A-B, A-C, or A-B, B-C). Things become different if you decide to remove (or destructively edit) one line (say line A). In the first case, all constraints are lost, even the fact that B and C should have the same length. In the second case B and C will still be connected, which is probably what you wanted.
A solution for this would be the following suggestion:
Instead of having two separate sets of constraints (A-B, A-C), group all these constraints into one multiple-element constraint, i.e., constraining A-B-C at once. Now, if you remove line A, B and C are still connected. If you remove B, A and C are still connected. Removing a constraint simply removes the selected element from the group. Duplicating an element (e.g. a line segment) may add all constraints to the group (no need to choose one counter-element 'at random').
Furthermore, it may be possible to handle constraints more intelligently when splitting elements. For example, if you split two intersecting line segments, you could apply a coincidence constraint to all four endpoints at the intersection (A-B-C-D). The user can then remove any two of the four resulting line segments, and the two remaining line segments will still be connected to each other by the constraint.
I wonder what your opinion is on this!
Best regards,
Gijs van Oort,
Enschede, The Netherlands
(no subject) (by Jonathan Westhues)
That's something that bothers me too. A lot of things in SolveSpace assume that constraints are on a finite number of entities, so it would require some low-level changes (including to the file format) to implement a constraint on a group like that.
The easiest way to achieve that behavior would probably be a special case in the cleanup code after deleting an entity, to recognize when an equality relationship (equal length, coincident, parallel, horizontal/vertical, etc.) between two non-deleted entities gets lost, and put those back explicitly. I already do that for point-coincident constraints, in FixConstraintsForPointBeingDeleted() in modify.cpp, and it would be a fairly localized change to do that for other kinds of equality constraint too.
Constraints after splitting are messy. I currently generate a point-coincident constraint at the intersection; so the particular constraint that you mention already exists, if I understand correctly, but nothing else does. That gets difficult to handle in general, though. For example, if there used to be a length constraint on the line AB, then there's no simple constraint on the lines AX and XB after splitting that would provide the same behavior.
As a partial solution, SolveSpace will currently retain the original (pre-splitting) lines or curves if they're marked as construction. That bloats the sketch, but means you won't lose existing constraints.
Thanks, and let me know if you have any other questions or comments.
The easiest way to achieve that behavior would probably be a special case in the cleanup code after deleting an entity, to recognize when an equality relationship (equal length, coincident, parallel, horizontal/vertical, etc.) between two non-deleted entities gets lost, and put those back explicitly. I already do that for point-coincident constraints, in FixConstraintsForPointBeingDeleted() in modify.cpp, and it would be a fairly localized change to do that for other kinds of equality constraint too.
Constraints after splitting are messy. I currently generate a point-coincident constraint at the intersection; so the particular constraint that you mention already exists, if I understand correctly, but nothing else does. That gets difficult to handle in general, though. For example, if there used to be a length constraint on the line AB, then there's no simple constraint on the lines AX and XB after splitting that would provide the same behavior.
As a partial solution, SolveSpace will currently retain the original (pre-splitting) lines or curves if they're marked as construction. That bloats the sketch, but means you won't lose existing constraints.
Thanks, and let me know if you have any other questions or comments.
(no subject) (by Witold)
Hi. This would be very useful and improve the user experience of the SolveSpace. For example, I have 16 arcs in my projects of equal radius / length, and it would make my project much easier to manage model and browse constraints, if all 15 constraints appeared as one constraint group (it is easier to rename it too, or show all elements in the groups).
Thanks.
Thanks.
(no subject) (by Rune)
From a user point of view, it sounds complicated. I think a better way around would to have a list of named constraints (or definitions) with values/formulas. So for example you could have a Diameter D_inner=10mm, Length L_outer=11, Angle Alpha=12 etc that you would/could use as constraints. It should be a section in the existing list of constraints.
It should be possible to edit the name and values of all constraints in the list so you could create a true parametric design. I would also imagine that it could speed up the solver because you would avoid "daisy chained" constraints and the user would get a clearer idea of what is the 'defining' and what are the depending constraints. At the moment it easily gets quite messy. The implementation of 'definitions' would also facilitate the splitting and copy paste issue.
Would it be technically feasible to implement such a 'definitions' list or would it radically change the program structure?
It should be possible to edit the name and values of all constraints in the list so you could create a true parametric design. I would also imagine that it could speed up the solver because you would avoid "daisy chained" constraints and the user would get a clearer idea of what is the 'defining' and what are the depending constraints. At the moment it easily gets quite messy. The implementation of 'definitions' would also facilitate the splitting and copy paste issue.
Would it be technically feasible to implement such a 'definitions' list or would it radically change the program structure?
(no subject) (by Uwe)
variables/definitions as suggested above by Rune is exactly what I was looking for. Googling for "parametric 2D cad freeware" led me to solvespace. We have a laser cutter in our FabLab and are looking desperately for a program that allows us
to define thickness of our plywood/pmma sheets (which have horrible tolerances) and tool width (differs between long and short focus lens). Almost all of our designs rely on fitting 2 or more parts together with a defined thickness. Boxes are a good example: the are many online box-generators available and all use a variable for material thickness. I hope that solvespace was able to define something like "slot_x = 2 * board_thickness + 10, slot_y = board_thickness..."
This is, what I understand as parametric design (am I wrong?).
Is there a chance that solvespace will have something like this in near future ?
to define thickness of our plywood/pmma sheets (which have horrible tolerances) and tool width (differs between long and short focus lens). Almost all of our designs rely on fitting 2 or more parts together with a defined thickness. Boxes are a good example: the are many online box-generators available and all use a variable for material thickness. I hope that solvespace was able to define something like "slot_x = 2 * board_thickness + 10, slot_y = board_thickness..."
This is, what I understand as parametric design (am I wrong?).
Is there a chance that solvespace will have something like this in near future ?
(no subject) (by Jonathan Westhues)
You can express the relationships that you mention geometrically. For example, the lengths of collinear line segments sharing endpoints sum, and the "length ratio" constraint multiplies a length by a constant. I've attached an example. Algebraic entry would in some cases be helpful, and I considered implementing that early on; but I haven't done that work, and I don't know when I'd have time to.
For the tool width issue, take a look at "cutter radius offset" in the configuration screen (at the top left of the browser window, click "home", then click "config"). It would be possible to cutter-radius-compensate by hand; but that seems painful compared to just drawing the part you want, and applying the offset in the export filter.
For the tool width issue, take a look at "cutter radius offset" in the configuration screen (at the top left of the browser window, click "home", then click "config"). It would be possible to cutter-radius-compensate by hand; but that seems painful compared to just drawing the part you want, and applying the offset in the export filter.
(no subject) (by Uwe)
got it - thanks a lot, Jonathan
(no subject) (by Rune)
Two words about that. One thing is that it is difficult to see what is going on in a drawing, for the simple sum.slvs you can deduct that g2 is controlling the height and the first line piece but when you got more complicated drawing you really need to keep external notes on what is going on.
Second is that I have tried going that way of having a DIMENSIONS group (with dimensions ;) ) a CALCULATIONS group on which I base the rest of the drawing converting radius to diameters etc. (I'm studying the dynamics ). At that point the solver becomes rather sloooow because you need to repeat a lot of constraints in the end.
But the program does things that I haven't found any other program doing, so I definitely think its worth developing further
Second is that I have tried going that way of having a DIMENSIONS group (with dimensions ;) ) a CALCULATIONS group on which I base the rest of the drawing converting radius to diameters etc. (I'm studying the dynamics ). At that point the solver becomes rather sloooow because you need to repeat a lot of constraints in the end.
But the program does things that I haven't found any other program doing, so I definitely think its worth developing further
Naming elements of the drawing (by Rune)
Hi, I have been messing a bit with the code (eMVe version) to produce a version that allows renaming of elements. Under [Edit] there is a Rename option or it can be edited in the Browser window (see jpg).
The browser then shows constraints between named segments (see jpg).
Also you can temporarily disable the look-up of bad constraints [option under Edit] which is a point where the CPU may hang for a long time.
Keyboard shortcuts have been added to allow changing groups by pgup/pgdwn.
If you are interested, let me know and i'll share the source on github.
P.S. IT'S EXPERIMENTAL disclamer!!!
The browser then shows constraints between named segments (see jpg).
Also you can temporarily disable the look-up of bad constraints [option under Edit] which is a point where the CPU may hang for a long time.
Keyboard shortcuts have been added to allow changing groups by pgup/pgdwn.
If you are interested, let me know and i'll share the source on github.
P.S. IT'S EXPERIMENTAL disclamer!!!
Post a reply to this comment: