USER FORUM

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

**Feature Request: Global Parameter/Tokens & (very basic) Expressions in dimension constraints**

*(by Eric S)*

Hi There.

I use solvespace extensively for designing models we use to CNC machine wood Stock (plywood).

To keep my models manageable and to enable these models to 'flex' for different materials and machine tolerances, I've taken to using the first group to define dimensioned construction geometry for key parameters that i use throughout the model...

The most obvious example is material thickness, but i also use certain values as offset to compensate for variations in the machining process or to get joints to behave in particular fashion(s).

It works well, but it's a bit Hackish. I also have to introduce (at times) a lot of additional geometry and constraints to support these types of offset since they're not really in the design intent.

a few observations from using the tool this way..

1)"format" the geometry in the first group for these global parameters so that they are readible and don't confuse other drafters requires a lot of redundant drawing effort, and it would be nicer to have a "global parameters" area in the browser to cleanly and simply define variable that i would like to use throughout the model.

I would envision such functionality would enable the ability to define a value with a label/token and be able to use that where appropriate. like in dimensional constraints.

example:

mat_thickness = .485 and then be able to use that instead of a literal numeric entry (entering "mat_thickness" instead of ".485" everywhere

This would also reduce the temptation to just use equal constraints all over the place, where they start losing readibility/meaning when the model starts getting more complex.

Additionally (and this would be AWESOME!) to be able to use very simple formulas (arithmetic) in the dimensional constraints.

like: mat_thickness + .02

or: mat_thickness + climb_offset

this would cut down on quite a bit of extra geometry in the designs.

If something like this were to be implemented i would expect that the resulting value would be shown on the constraint in the normal state, but upon double clicking the dimension the textbox would show the string with 'formula' for editing. at the point of closing the string would be evaluate and there is a clean point to invalidate the model or to succeed in resolving the new dimension value.

Don't expect you to jump right on that, but this would result in a big improvement in the general cleanliness of our models and really drive home the value as a parametric design tool. we would be able to circulate them more broadly and have non-experts have a fighting change to make simple changes to the models without having to have intricate knowledge of how the geometry was implemented.

Thanks for the all the work that you've done on SolveSpace. I love it.

ALSO: Any idea when the next release will hit?

Take Care.

for giggle I attached is a screen shot of a Parameter Group from one of our models.

I use solvespace extensively for designing models we use to CNC machine wood Stock (plywood).

To keep my models manageable and to enable these models to 'flex' for different materials and machine tolerances, I've taken to using the first group to define dimensioned construction geometry for key parameters that i use throughout the model...

The most obvious example is material thickness, but i also use certain values as offset to compensate for variations in the machining process or to get joints to behave in particular fashion(s).

It works well, but it's a bit Hackish. I also have to introduce (at times) a lot of additional geometry and constraints to support these types of offset since they're not really in the design intent.

a few observations from using the tool this way..

1)"format" the geometry in the first group for these global parameters so that they are readible and don't confuse other drafters requires a lot of redundant drawing effort, and it would be nicer to have a "global parameters" area in the browser to cleanly and simply define variable that i would like to use throughout the model.

I would envision such functionality would enable the ability to define a value with a label/token and be able to use that where appropriate. like in dimensional constraints.

example:

mat_thickness = .485 and then be able to use that instead of a literal numeric entry (entering "mat_thickness" instead of ".485" everywhere

This would also reduce the temptation to just use equal constraints all over the place, where they start losing readibility/meaning when the model starts getting more complex.

Additionally (and this would be AWESOME!) to be able to use very simple formulas (arithmetic) in the dimensional constraints.

like: mat_thickness + .02

or: mat_thickness + climb_offset

this would cut down on quite a bit of extra geometry in the designs.

If something like this were to be implemented i would expect that the resulting value would be shown on the constraint in the normal state, but upon double clicking the dimension the textbox would show the string with 'formula' for editing. at the point of closing the string would be evaluate and there is a clean point to invalidate the model or to succeed in resolving the new dimension value.

Don't expect you to jump right on that, but this would result in a big improvement in the general cleanliness of our models and really drive home the value as a parametric design tool. we would be able to circulate them more broadly and have non-experts have a fighting change to make simple changes to the models without having to have intricate knowledge of how the geometry was implemented.

Thanks for the all the work that you've done on SolveSpace. I love it.

ALSO: Any idea when the next release will hit?

Take Care.

for giggle I attached is a screen shot of a Parameter Group from one of our models.

**(no subject)**

*(by Jonathan Westhues)*

Thanks. That's a feature that I considered early in the development of the program, and it's the reason, for example, why the arithmetic expression parser uses the same data structures as the symbolic algebra system. So that would be mostly just user interface work.

The parameter table is indeed a bit ridiculous. You could simplify it slightly using the Constrain -> Comment function instead of Sketch -> Text in a TrueType Font; the latter is needed only when you want the actual curves (e.g., to machine text in to a part). You could also use the snap grid instead of the extra geometry to space the lines.

The parameter table is indeed a bit ridiculous. You could simplify it slightly using the Constrain -> Comment function instead of Sketch -> Text in a TrueType Font; the latter is needed only when you want the actual curves (e.g., to machine text in to a part). You could also use the snap grid instead of the extra geometry to space the lines.

**I agree**

*(by Eric S)*

In concept I totally agree with you. Using the comments as you noted was the technique I started with. However I found working them, in-practice, to be painful (at least in serving duty as Parameter labels).

Knowningly as for perhaps the wrong reason(s), i switched to using TTFs because it solved the issue of oodles of busy work when i would add new parameters and re-organize them and sometime we've found it useful to output them separately like a build sheet.

Talking about the functional stuff however, The ability to enter parameter definition(s) somewhere less hacky would be AWESOME. The ability to refer to them directly in the model by name would be absolutely killer and Using those in basic expressions would be incredible.

What are the chances some of what we're talking about there might happen?

And do you have an idea of when you might push another release? wish i could help, but i'm not experienced with the C.

Again Thanks!

-Eric

Knowningly as for perhaps the wrong reason(s), i switched to using TTFs because it solved the issue of oodles of busy work when i would add new parameters and re-organize them and sometime we've found it useful to output them separately like a build sheet.

Talking about the functional stuff however, The ability to enter parameter definition(s) somewhere less hacky would be AWESOME. The ability to refer to them directly in the model by name would be absolutely killer and Using those in basic expressions would be incredible.

What are the chances some of what we're talking about there might happen?

And do you have an idea of when you might push another release? wish i could help, but i'm not experienced with the C.

Again Thanks!

-Eric

**concur with feature request**

*(by Charles Pierce)*

I agree that global parameters and dimensional expressions would vastly increase the utility of SolveSpace as a mechanical design tool. This is one of the primary features I use in software from Geomate (Graficalc at http://www.graficalc.com/, which is described as the sketching equivalent of a spreadsheet). Graficalc's backsolve (the goal-seek enhancement I just posted here), is another of the essential features I use with it.

**Feature Request: Global Parameter : 1 vote more**

*(by Thierry B)*

I like it. A global parameters table and dimensional expressions will be very useful to maintain and understand models.

Thanks to add this features.

Thanks to add this features.

**(no subject)**

*(by whitequark)*

I have plans for implementing this. Currently, my main issue is that the constraint solver does not cope very well with discontinuous jumps. If there are several solutions to the system, and you rapidly change a parameter, it can end up in a different solution, which is almost always not what you want.

The easiest way to notice it is by constraining a rectangle horizontally, grabbing it by one of the points and suddenly jerking to the direction of where the rectangle lies compared to the point. You will see it invert. If other entities were constrained against the rectangle, this will usually break the sketch entirely.

As such, it does not appear that general-purpose parametric sketches are currently viable. Jonathan, do you have any ideas for this? How even do other CADs solve this problem?

I have an idea to work around this though, where you would have several sets of parameters, being able to switch between them, where the precomputed solution would be stored in the sketch for every set of parameters. A good example is a set of metric fasteners. The hex head would certainly get distorted if you will try to change it parametrically, but fortunately you don't need a continuous variation in its size.

Basically, this would be the same as having multiple files, but sharing entities, requests, etc. But not params.

There are a few issues with this:

* it requires somewhat drastic changes to the savefile format;

* after adding or removing params, it will probably be necessary to go through all the sets and look at / fix them manually.

I would far prefer some kind of a flag to the solver that I prefer a solution of the same form that the current one is. I'm not sure how would it be expressed mathematically--maybe the sign of all params should stay the same?

The easiest way to notice it is by constraining a rectangle horizontally, grabbing it by one of the points and suddenly jerking to the direction of where the rectangle lies compared to the point. You will see it invert. If other entities were constrained against the rectangle, this will usually break the sketch entirely.

As such, it does not appear that general-purpose parametric sketches are currently viable. Jonathan, do you have any ideas for this? How even do other CADs solve this problem?

I have an idea to work around this though, where you would have several sets of parameters, being able to switch between them, where the precomputed solution would be stored in the sketch for every set of parameters. A good example is a set of metric fasteners. The hex head would certainly get distorted if you will try to change it parametrically, but fortunately you don't need a continuous variation in its size.

Basically, this would be the same as having multiple files, but sharing entities, requests, etc. But not params.

There are a few issues with this:

* it requires somewhat drastic changes to the savefile format;

* after adding or removing params, it will probably be necessary to go through all the sets and look at / fix them manually.

I would far prefer some kind of a flag to the solver that I prefer a solution of the same form that the current one is. I'm not sure how would it be expressed mathematically--maybe the sign of all params should stay the same?

**(no subject)**

*(by Jonathan Westhues)*

There's some discussion of this problem in one of the tutorials, around "When the sketch is ambiguous, ...",

http://solvespace.com/constraints.pl

The simplest way to avoid flipping to unintended solutions is to change the parameter slowly, re-solving at each step. Analyze -> Step Dimension automates that already, pretty straightforward. That's potentially slow, of course. It could be sped up by not rewriting the symbolic Jacobian at each step.

Constraints that operate on signed distance (like point-line or point-plane distance, unlike point-point distance) are generally more robust. One way to make sketches more robust would be to introduce a signed point-point distance constraint, like as a dot product against an adjacent line (e.g., any line sharing an endpoint with the line whose length is being constrained other than the line itself) instead of as a simple magnitude. That would always keep the off-line point on the other side of that line, and thus avoid flipping.

That might be too complicated to expose to the user, but some heuristic could choose that adjacent line automatically; though if that heuristic failed (e.g., because the intended solution affected the angle between the two lines unexpectedly), the result would be particularly surprising.

http://solvespace.com/constraints.pl

The simplest way to avoid flipping to unintended solutions is to change the parameter slowly, re-solving at each step. Analyze -> Step Dimension automates that already, pretty straightforward. That's potentially slow, of course. It could be sped up by not rewriting the symbolic Jacobian at each step.

Constraints that operate on signed distance (like point-line or point-plane distance, unlike point-point distance) are generally more robust. One way to make sketches more robust would be to introduce a signed point-point distance constraint, like as a dot product against an adjacent line (e.g., any line sharing an endpoint with the line whose length is being constrained other than the line itself) instead of as a simple magnitude. That would always keep the off-line point on the other side of that line, and thus avoid flipping.

That might be too complicated to expose to the user, but some heuristic could choose that adjacent line automatically; though if that heuristic failed (e.g., because the intended solution affected the angle between the two lines unexpectedly), the result would be particularly surprising.

**(no subject)**

*(by whitequark)*

A slightly different idea: a solver mode which treats all point-point constraints this way. That is, it selects an adjacent line before trying to solve, fixes the sign, and solves--just for this parametric mode. My gut feeling says that this should be understandable enough, though I'm not entirely sure.

**(no subject)**

*(by Jonathan Westhues)*

My guess is that that would usually improve performance, and occasionally do something mystifying. Seems worth investigating, though.

There are relatively common special cases that seem like pure improvements in performance. For example, the length of a horizontal line segment isn't currently reduced to u2 - u1 = d. If it were, then the flipping would stop, and you could also forward-substitute that, removing an unknown from the Newton solution.

There are relatively common special cases that seem like pure improvements in performance. For example, the length of a horizontal line segment isn't currently reduced to u2 - u1 = d. If it were, then the flipping would stop, and you could also forward-substitute that, removing an unknown from the Newton solution.

**(no subject)**

*(by NotSolveSpace)*

Jonathan, why do you focus perfomance? Perfomance is not so important when your sketch modifing went wrong way. The main idea of the any gui computer programm must be robustness & usability for practics even if you need much more time to wait solution. Nowdays, in our cad, we almost eliminate ambiguousness from the sketching. As i said, we are using atan2-based angle expressions for angles, parallelity & perpendicularity. even horizontal-vertical constraints complemented with abs(a.x - b.x) +/- (a.x - b.x) expressions to support determinancy. Aslo, we are used signed point-line distance expression everywhere. So, now we have stable sketches when it enough-constrained.

**(no subject)**

*(by Jonathan Westhues)*

NotSolveSpace - You've posted many times, to criticize a choice I've made, or to claim to have made an improvement, or to show a random snippet of code out of context. You've also never provided any software that anyone else could use or evaluate. So perhaps you've done something good, but I have no way to know.

Do you plan to show your work in a form that others could evaluate and use? If so, when? If not, why are you spending your time this way?

Do you plan to show your work in a form that others could evaluate and use? If so, when? If not, why are you spending your time this way?

**(no subject)**

*(by NotSolveSpace)*

We are planning to launch this autumn. We are not criticize a choice you`ve made. We already made choice for your choice. But we cant say how we will publish - open source or not, but we can help to make this project better. Now we have completely different CAD, but root of the project is SolveSpace, so approaches is still the same & this can be helpful for people who can improve SolveSpace. if you will say, what this recomendations is stupid & i should not write here, so i will never do it. But you should consider what i written all this for best intention, not for critics.

**(no subject)**

*(by Jonathan Westhues)*

I welcome any contribution to the project; but at the same time, it's not a contribution until it takes a form that other people can use.

When you say "open source or not" - I assume you're aware that SolveSpace is licensed under the GPL? Loosely, this means that if you distribute any software derived from it, then you also must distribute the source for that whole program for free.

When you say "open source or not" - I assume you're aware that SolveSpace is licensed under the GPL? Loosely, this means that if you distribute any software derived from it, then you also must distribute the source for that whole program for free.

**(no subject)**

*(by NotSolveSpace)*

We have a project grown from solve space by iterative refactoring. at this moment this is completely another program. i think every code line was rewritten. so i cant call it solvespace anymore, i even cant name it NotSolveSpace. Only approach is the same, code is not. We will open API, we will open all code which is similar to SolveSpace (NURBS operations, mesh operations, refactored solver). This all will be like separated libraries, only our new code will be closed.

**(no subject)**

*(by ruevs)*

Here is my take on the original problem discussed in this thread:

http://solvespace.com/forum.pl?action=viewthread&parent=1005

http://solvespace.com/forum.pl?action=viewthread&parent=1005

**performance**

*(by John Griessen)*

performance over pragmatic is probably more clean and possible to build on, and can have a shot at enduring. Much appreciated, and when I have more days of rent paid up into the future, I will do some helping out with its development.

The pragmatically driven not-called-not-solvespace will be just another closed CAD tool in a sea of same. If they sell a copy of solvespace's nice constraint GUI workspace and drawing element browser details, maybe the FSF would help sue them over copyright infringement. Even if there is not a line of code the same.

Not sure how copyright applies to that. Might be a patent area instead.

The pragmatically driven not-called-not-solvespace will be just another closed CAD tool in a sea of same. If they sell a copy of solvespace's nice constraint GUI workspace and drawing element browser details, maybe the FSF would help sue them over copyright infringement. Even if there is not a line of code the same.

Not sure how copyright applies to that. Might be a patent area instead.

**NotSolveSpace**

*(by EvilSpirit)*

Now it is not just words or "random snippet".

I want to say sorry to you, Jonathan, & I hope you approve the contibution we will going to make with whitequark.

Welcome to https://github.com/Evil-Spirit/solvespace

I want to say sorry to you, Jonathan, & I hope you approve the contibution we will going to make with whitequark.

Welcome to https://github.com/Evil-Spirit/solvespace

**(no subject)**

*(by Jonathan Westhues)*

Copyright wouldn't protect an implementation with different code, except perhaps on specific UI text or graphics. Software patents (a) exist only when the inventor files an application and specific claims are allowed by an examiner employed by the government; (b) are expensive, since both the government and the patent agent or attorney who drafts the application must be paid; and (c) are generally contrary to the spirit of free software. So they're not relevant here.

But that's all of course irrelevant when the changes are published under the GPL; thanks, and I'll take a look. I probably wouldn't merge:

* Anything with a big speed penalty (like including all point-coincident constraints in the Jacobian; can't a similar effect be achieved without that?)

* Anything that breaks the file format (like removing any entities, even though adding FACE_QUAT_PT is reasonable and a superset)

I'll review the other changes more carefully.

But that's all of course irrelevant when the changes are published under the GPL; thanks, and I'll take a look. I probably wouldn't merge:

* Anything with a big speed penalty (like including all point-coincident constraints in the Jacobian; can't a similar effect be achieved without that?)

* Anything that breaks the file format (like removing any entities, even though adding FACE_QUAT_PT is reasonable and a superset)

I'll review the other changes more carefully.

**(no subject)**

*(by EvilSpirit)*

> like including all point-coincident constraints in the

> Jacobian; can't a similar effect be achieved without that?

if it is about

if(fabs(SK.GetParam(a)->val - SK.GetParam(b)->val) > CONVERGE_TOLERANCE) continue;

then

this is works only for new-created point-coincident. When it gets converged, it will solve like substitution.

there is 2 cases:

1. newly created constraints which generate a = b equations.

in this case first solver call will throw this equation into jacobian matrix, the next call will work like symbolic substitutions. it is not so problem, because it is works only one time when we apply new constriant.

2. dragging. when we drag, we choose one of (probably) conincident points and change its parameters. parameters of a points, conincident to the dragged are not affected, so approach with throwing to the jacobian start to work. in this case we have +1 equation. but this is overall good, because we dont break the sketch by changing parameters so much as we do it before with unconditional substitution. we break constraints only for enitities related to the dragged point, not for many which is coincident to it.

> Jacobian; can't a similar effect be achieved without that?

if it is about

if(fabs(SK.GetParam(a)->val - SK.GetParam(b)->val) > CONVERGE_TOLERANCE) continue;

then

this is works only for new-created point-coincident. When it gets converged, it will solve like substitution.

there is 2 cases:

1. newly created constraints which generate a = b equations.

in this case first solver call will throw this equation into jacobian matrix, the next call will work like symbolic substitutions. it is not so problem, because it is works only one time when we apply new constriant.

2. dragging. when we drag, we choose one of (probably) conincident points and change its parameters. parameters of a points, conincident to the dragged are not affected, so approach with throwing to the jacobian start to work. in this case we have +1 equation. but this is overall good, because we dont break the sketch by changing parameters so much as we do it before with unconditional substitution. we break constraints only for enitities related to the dragged point, not for many which is coincident to it.

**(no subject)**

*(by Jonathan Westhues)*

I get the benefit in case (1). That's a bit of an edge case, but I agree that's good behavior that can't readily be achieved in any other way, since neither parameter's initial value is a better guess for the new merged parameter than the other.

But why does it help in case (2)? Do you have an example? And if it helps, then is the test around line 112 of system.cpp still doing anything?

But why does it help in case (2)? Do you have an example? And if it helps, then is the test around line 112 of system.cpp still doing anything?

**(no subject)**

*(by EvilSpirit)*

the example about (1) can be found at https://github.com/Evil-Spirit...he/tests/point_connection.slvs

i will try do demonstrate example for (2)

i will try do demonstrate example for (2)

**(no subject)**

*(by walter steffe)*

Hello

I am also very interested in the parameter/expression feature.

In fact I would like to use solvespace in the frame of an electromagnetic design/optimization framework. The symbolic parameters will play the role of optimization variables and the cost function (to be minimized) will be provided by an external (electromagnetic) solver.

A similar situation can arise also in many other contexts (i.e. structural problems, thermal problems, ...).

The optimization parameters (variable ranges ...) are usually set in such a way the model topology do not change during the optimization process. So I do not expect a model breakdown due to a rectangle flipping or any other topological jump.

I may understand that a set of (non linear) constraints can allow more than one solution but this ambiguity is not caused by the fact that the entered dimension is a symbolic parameter (or an expression) instead of a numerical value.

So I think that if this ambiguity was solved for the numerical constraints the same solution should be valid also for the parametric constraints.

I am also very interested in the parameter/expression feature.

In fact I would like to use solvespace in the frame of an electromagnetic design/optimization framework. The symbolic parameters will play the role of optimization variables and the cost function (to be minimized) will be provided by an external (electromagnetic) solver.

A similar situation can arise also in many other contexts (i.e. structural problems, thermal problems, ...).

The optimization parameters (variable ranges ...) are usually set in such a way the model topology do not change during the optimization process. So I do not expect a model breakdown due to a rectangle flipping or any other topological jump.

I may understand that a set of (non linear) constraints can allow more than one solution but this ambiguity is not caused by the fact that the entered dimension is a symbolic parameter (or an expression) instead of a numerical value.

So I think that if this ambiguity was solved for the numerical constraints the same solution should be valid also for the parametric constraints.

**build**

*(by yugami)*

evil-spirit - your repository does not build on windows/Visual Studio without extensive modification. And once I managed to sludge my way through fixing the problems the text (both text windows and mouse over hints) in the resulting exe is unreadable.

**(no subject)**

*(by Jonathan Westhues)*

walter - Multiple solutions of equations specified algebraically by the user would of course work identically to multiple solutions of equations arising from the geometry now, just "chosen" according to the basin of attraction of the numerical method.

EvilSpirit - I understand the intended benefit for (1). But what about (2)?

EvilSpirit - I understand the intended benefit for (1). But what about (2)?

**(no subject)**

*(by walter steffe)*

Jonathan, my conclusion where based on the (implicit) assumption that the user equations are of the same type as those implemented in popular CADs (Catia, Solidworks ..).

With these CADs you can define a user parameter which can than be entered in a geometrical dimension with no difference with respect to a numerical value.

You may also set a formula which define this parameter as an (univariate) function of other parameters. Circular dependencies among user parameters are not allowed so that the user equations can never increase the number of solutions.

The ambiguity implied by the geometrical equations is resolved by the fact that when a dimensional constraints is applied to a sketch they it is not allowed to change the topology.

In example you can start by drawing a rectangle. At this point the rectangle dimensions are indeterminate but its topology is already defined. If you specify the horizontal and dimension it will stretch in that directions but it will never flip.

Of course you are free to implement a different (more general) logic for your parametric CAD allowing the user to enter generic equations (instead of univariate functions).

This choice will increase a lot the complexity of solvespace algorithms. May be I am wrong but my feeling is that the added functionality will not balance this big effort.

With these CADs you can define a user parameter which can than be entered in a geometrical dimension with no difference with respect to a numerical value.

You may also set a formula which define this parameter as an (univariate) function of other parameters. Circular dependencies among user parameters are not allowed so that the user equations can never increase the number of solutions.

The ambiguity implied by the geometrical equations is resolved by the fact that when a dimensional constraints is applied to a sketch they it is not allowed to change the topology.

In example you can start by drawing a rectangle. At this point the rectangle dimensions are indeterminate but its topology is already defined. If you specify the horizontal and dimension it will stretch in that directions but it will never flip.

Of course you are free to implement a different (more general) logic for your parametric CAD allowing the user to enter generic equations (instead of univariate functions).

This choice will increase a lot the complexity of solvespace algorithms. May be I am wrong but my feeling is that the added functionality will not balance this big effort.

**(no subject)**

*(by Jonathan Westhues)*

The solver in SolveSpace now has no geometric understanding of the topology of the sketch. The only thing that disambiguates among multiple solutions is the initial conditions (i.e., the positions in which the entities are initially drawn).

Custom equations entered by the user would naturally work that way too, though care is sometimes required to write the equations in a way that makes their basins of attraction reasonable.

Custom equations entered by the user would naturally work that way too, though care is sometimes required to write the equations in a way that makes their basins of attraction reasonable.

**(no subject)**

*(by walter steffe)*

Perhaps "orientation" is a more appropriate term than "topology".

In any case let us consider the simple rectangle case.

I think the the initial conditions can be identified by 4 points (that is 4 couples of x,y coordinates) and 4 line segments (which can e regarded as four oriented couples of points).

You can assign a label to each one of these entities.

In example points A=(x_a, y_A), B=...

segment a=(A,B), b=(B,C)...

Initial label assignment can be done in such a way A,B,C,D are encountered in that order when the rectangle is walked in the counter-clockwise direction (as seen from z axis).

At this point you can specify length of segment "a" as the distance from A to B. This constraint admits different solutions but I think that only one preserves the initial orientation of the vertex quadruple (A,B,C,D).

In any case let us consider the simple rectangle case.

I think the the initial conditions can be identified by 4 points (that is 4 couples of x,y coordinates) and 4 line segments (which can e regarded as four oriented couples of points).

You can assign a label to each one of these entities.

In example points A=(x_a, y_A), B=...

segment a=(A,B), b=(B,C)...

Initial label assignment can be done in such a way A,B,C,D are encountered in that order when the rectangle is walked in the counter-clockwise direction (as seen from z axis).

At this point you can specify length of segment "a" as the distance from A to B. This constraint admits different solutions but I think that only one preserves the initial orientation of the vertex quadruple (A,B,C,D).

**(no subject)**

*(by Jonathan Westhues)*

I'm not sure what you're getting at. The solver is numerical, and needs an initial guess for the parameters that it's solving for. That's what I mean by "initial conditions". When multiple solutions exist, that's what disambiguates. Attraction to those initial conditions is the only thing that would keep, for example, the vertices of a rectangle in clockwise vs. ccw order.

**(no subject)**

*(by walter steffe)*

I have assumed that, for the rectangle case, the parameters that is solving for are the coordinates of the 4 points:

x_A, y_A, x_B_y_B,...

So there are 8 unknowns.

I have also assumes that there are other implicit constraints:

-segment "a" and "c" are horizontal

-segment "b" and "d" are vertical.

-point A is anchored at (0,0)

I am also not sure what you mean with "attraction" but its seems to me that it is something related with the numerical method you are using for solving the system of equations.

What I am saying does not depend on the numerical method.

I am assuming that you are able (in some way) to find the complete set of solutions associated with the system of equations and I am just suggesting a way to select the unique good solution. That solution should it that one which preserves the initial orientation of the vertex quadruple (A,B,C,D).

x_A, y_A, x_B_y_B,...

So there are 8 unknowns.

I have also assumes that there are other implicit constraints:

-segment "a" and "c" are horizontal

-segment "b" and "d" are vertical.

-point A is anchored at (0,0)

I am also not sure what you mean with "attraction" but its seems to me that it is something related with the numerical method you are using for solving the system of equations.

What I am saying does not depend on the numerical method.

I am assuming that you are able (in some way) to find the complete set of solutions associated with the system of equations and I am just suggesting a way to select the unique good solution. That solution should it that one which preserves the initial orientation of the vertex quadruple (A,B,C,D).

**(no subject)**

*(by Jonathan Westhues)*

The solver doesn't find the complete solution set (which may be infinite; but even when it's finite, it doesn't). It finds only a single solution, and which is determined by the basin of attraction of the numerical method. "Basin of attraction" is a technical term from the theory of dynamical systems:

https://en.wikipedia.org/wiki/Attractor#Basins_of_attraction

https://en.wikipedia.org/wiki/Attractor#Basins_of_attraction

**(no subject)**

*(by walter steffe)*

It is not clear to me why you are referring to the theory of dynamical systems. Our problem is described by a set of normal (not differential) equations which and it does not involve the time concept.

In any case if the numerical method can find only a single solution there is'nt any ambiguity.

There are just two possible cases:

1) The methods finds a proper solution (which should fulfill my selection criteria).

2) The methods finds a not proper solution such as a flipped rectangle.

In case 1 all is OK and the problem is solved.

In case 2 you should use a different numerical method.

In any case if the numerical method can find only a single solution there is'nt any ambiguity.

There are just two possible cases:

1) The methods finds a proper solution (which should fulfill my selection criteria).

2) The methods finds a not proper solution such as a flipped rectangle.

In case 1 all is OK and the problem is solved.

In case 2 you should use a different numerical method.

**(no subject)**

*(by Jonathan Westhues)*

"Time" is iteration within the numerical method that solves the equations. This terminology is routinely used in the literature; a web search will find lots of pretty (and unfortunate, for our purposes) fractal pictures of a Newton's method's basin of attraction.

My suggestion would be to review SolveSpace's internals, especially around system.cpp, more closely.

My suggestion would be to review SolveSpace's internals, especially around system.cpp, more closely.

**(no subject)**

*(by walter steffe)*

Ok Jonathan, now I understand the role of time and I will take some time to review SolveSpace's internals as you suggest.

Nevertheless it seems to me that if, for a given initial condition, the iterative method converges to a unique solution there are only two possibility:

1) You have some way ensured that a change of oriantation (like a rectangle flip) can never occur along the whole trajectory in the "phase space".

2) A change of oriantation can happen and therefore the final solution can be a sketch that does not preserve the initial orientation (like a "flipped rectangle").

In the second case you need an algorithm that is able to detect the change of orientation. The found solution has to be be discharged when the such a change is detected.

At this point I think it is necessary to search for a new solution starting from a different (randomly perturbed ?) initial condition.

Going back to the original topic (parametric dimension and expressions) I am still convinced that other commercial CADs have found a way to assure that the "flipping effect" can never occur for any initial condition and for any set of (non conflicting) constraints which the user selects from the menu.

The intruduction of parametric dimensions and formulas can not affect this behavior because the user equations are not added to the constraint equations. The dimension parameters are instead resolved (replaced by numerical values) before starting the solution of the constraint equations.

Nevertheless it seems to me that if, for a given initial condition, the iterative method converges to a unique solution there are only two possibility:

1) You have some way ensured that a change of oriantation (like a rectangle flip) can never occur along the whole trajectory in the "phase space".

2) A change of oriantation can happen and therefore the final solution can be a sketch that does not preserve the initial orientation (like a "flipped rectangle").

In the second case you need an algorithm that is able to detect the change of orientation. The found solution has to be be discharged when the such a change is detected.

At this point I think it is necessary to search for a new solution starting from a different (randomly perturbed ?) initial condition.

Going back to the original topic (parametric dimension and expressions) I am still convinced that other commercial CADs have found a way to assure that the "flipping effect" can never occur for any initial condition and for any set of (non conflicting) constraints which the user selects from the menu.

The intruduction of parametric dimensions and formulas can not affect this behavior because the user equations are not added to the constraint equations. The dimension parameters are instead resolved (replaced by numerical values) before starting the solution of the constraint equations.

**(no subject)**

*(by ruevs)*

If "a way to assure that the "flipping effect" can never occur for any initial condition and for any set of (non conflicting) constraints which the user selects" is implemented then you are right.

However currently when you drastically change a dimension - by e.g. changing an "expression" (in the future feature we are discussing) - then the solution can leave the "local minimum" and "jump" into another one - if you think of the "solution space" like this:

http://www.webdev20.pl/skins/d...s/3d_grapher/webgl_ploter.html

This is not a very precise analogy but I think it illustrates the problem.

However currently when you drastically change a dimension - by e.g. changing an "expression" (in the future feature we are discussing) - then the solution can leave the "local minimum" and "jump" into another one - if you think of the "solution space" like this:

http://www.webdev20.pl/skins/d...s/3d_grapher/webgl_ploter.html

This is not a very precise analogy but I think it illustrates the problem.

**(no subject)**

*(by walter steffe)*

Hello Ruevs, the problem (random jumps to different solutions) is very clear.

I was just saying that, according to my user experience, this problem does not occur with other commercial CADs.

I have used Catia changing all sketch dimensions several times (in the frame of an optimization procedure) and the I can say that I have never seen such kind of jumps.

Catia is a closed software and the internal details of its sketcher are not published. I can only guess that, perhaps, they do not use an iterative method.

There are also other approaches, such as, in example, that one described in the annexed paper.

I was just saying that, according to my user experience, this problem does not occur with other commercial CADs.

I have used Catia changing all sketch dimensions several times (in the frame of an optimization procedure) and the I can say that I have never seen such kind of jumps.

Catia is a closed software and the internal details of its sketcher are not published. I can only guess that, perhaps, they do not use an iterative method.

There are also other approaches, such as, in example, that one described in the annexed paper.

**(no subject)**

*(by EvilSpirit)*

There is a lot of natural simple ways to force solver preserve topology if the sketch. Using all the signed expressions for angle, pt line distance, pt pt distance, expressions for greater and less. Current solver approach is good, no need to make big changes to get stable sketches. Changeing of the equations will be helpful.

**(no subject)**

*(by EvilSpirit)*

Jonathan, is is hard to demonstrate how (2) is works,

but system:112 in this case probably doing nothing.

but system:112 in this case probably doing nothing.

**(no subject)**

*(by walter steffe)*

I would suggest the following additional constraint:

A>0 (or <0 depending on the starting value)

where:

A=sum ((P_(i+1)-0) x (P_i-0)) . n)

P_i are the consecutive vertices of the closed sketch

x = vector product

n = normal versor associated with sketch plane

O =arbitrary point on the sketch plane.

It can be readily seen that A is the oriented area as seen by the n direction.

A changes sign when the rectangle flips.

A>0 (or <0 depending on the starting value)

where:

A=sum ((P_(i+1)-0) x (P_i-0)) . n)

P_i are the consecutive vertices of the closed sketch

x = vector product

n = normal versor associated with sketch plane

O =arbitrary point on the sketch plane.

It can be readily seen that A is the oriented area as seen by the n direction.

A changes sign when the rectangle flips.

**(no subject)**

*(by Jonathan Westhues)*

In concept, that helps, but:

(a) That's potentially a really long equation.

(b) Most problematic "flipping" preserves the direction of the overall contour; it's just a few vertices flipping locally, not the whole thing. So many such equations would be needed.

(c) The manner in which equations are solved doesn't lend itself to inequality constraints.

You could try it if you wanted. Signed distance, like EvilSpirit says, seems more promising. Point-line distance is already signed, and point-point distance could be made signed with respect to a nearby line, either specified explicitly or inferred from geometry.

(a) That's potentially a really long equation.

(b) Most problematic "flipping" preserves the direction of the overall contour; it's just a few vertices flipping locally, not the whole thing. So many such equations would be needed.

(c) The manner in which equations are solved doesn't lend itself to inequality constraints.

You could try it if you wanted. Signed distance, like EvilSpirit says, seems more promising. Point-line distance is already signed, and point-point distance could be made signed with respect to a nearby line, either specified explicitly or inferred from geometry.

**(no subject)**

*(by walter steffe)*

Ok Jonathan.

But now I think that it could be sufficient (and easier) to avoid ambiguity by applying signed orientations (that is angles) to the sketch segments.

In a technical drawing most lines are horizontal or vertical.

Some time there are lines at different angles (45 deg, 30 deg ..)

but still there is a good chance that they are in a prescribed direction.

There are two ways of specifying the horizontal direction of e segment:

1) P1_y =P2_y

2) Oriented angle between P2-P1 and x axis =0.

Let us assume that segment length is also constrained:

distance(P1,P2)= L.

With horizontal constraint of type 1 there are two solutions (because P1 and P2 can be exchanged).

This ambiguity is removed by the horizontal constraint of type 2.

So I suggest to use as many angular constraints (of type 2) as possible.

When I draw a rectangle (using the menu command) I would expect that

4 constraint of this type are automatically imposed (on all the 4 edges).

Than If I impose a new dimensional constraint (in example height=h)

the rectangle would never be able to flip even if the vertical length is implemented as an unsigned distance between a couple of points.

But now I think that it could be sufficient (and easier) to avoid ambiguity by applying signed orientations (that is angles) to the sketch segments.

In a technical drawing most lines are horizontal or vertical.

Some time there are lines at different angles (45 deg, 30 deg ..)

but still there is a good chance that they are in a prescribed direction.

There are two ways of specifying the horizontal direction of e segment:

1) P1_y =P2_y

2) Oriented angle between P2-P1 and x axis =0.

Let us assume that segment length is also constrained:

distance(P1,P2)= L.

With horizontal constraint of type 1 there are two solutions (because P1 and P2 can be exchanged).

This ambiguity is removed by the horizontal constraint of type 2.

So I suggest to use as many angular constraints (of type 2) as possible.

When I draw a rectangle (using the menu command) I would expect that

4 constraint of this type are automatically imposed (on all the 4 edges).

Than If I impose a new dimensional constraint (in example height=h)

the rectangle would never be able to flip even if the vertical length is implemented as an unsigned distance between a couple of points.

**(no subject)**

*(by EvilSpirit)*

a solution already has been offered in this topic:

"horizontal-vertical constraints complemented with abs(a.x - b.x) +/- (a.x - b.x) expressions to support determinancy"

solution with signed pt-pt distance (p1 = p0 + dir(angle) * distance) is also good, but more expensive.

"horizontal-vertical constraints complemented with abs(a.x - b.x) +/- (a.x - b.x) expressions to support determinancy"

solution with signed pt-pt distance (p1 = p0 + dir(angle) * distance) is also good, but more expensive.

**(no subject)**

*(by walter steffe)*

I do not fully undertand your expression but I think that the "abs(x)" function should not be used inside of the constraint equations.

If you admit the "abs(x)" function you have to admit also "sign(x)" for being sign(x)=x/abs(x).

Using the function "sign(x)" it were possible to convert any inequality constraint in an equality constraint. In fact A>0 could be rewritten as sign(A)=1.

as pointed by Jonathan in a previous post the solver does not work well with the inequality constraint A>0. I think that this problem can not be overcome by simply replacing A>0 with sign(A)=1 because it would be just a cosmetic (not a substatial) change.

So my conclusion is that the functions "sign(x)" and "abs(x)" must not be used in the constraint equations.

If you admit the "abs(x)" function you have to admit also "sign(x)" for being sign(x)=x/abs(x).

Using the function "sign(x)" it were possible to convert any inequality constraint in an equality constraint. In fact A>0 could be rewritten as sign(A)=1.

as pointed by Jonathan in a previous post the solver does not work well with the inequality constraint A>0. I think that this problem can not be overcome by simply replacing A>0 with sign(A)=1 because it would be just a cosmetic (not a substatial) change.

So my conclusion is that the functions "sign(x)" and "abs(x)" must not be used in the constraint equations.

**(no subject)**

*(by EvilSpirit)*

Just imagine equation (directy written for the solver)

abs(a) = a

it is equivalent to

a >= 0.

using this approach it can be possible to implement any kind of expressions for ranged values, like min < value < max.

derivative for the abs(x) function will be sign(x).

for horiz / vert

abs(a.x - b.x) = a.x - b.x

this is equivalent to

a >= b.

this is proven equation, so you no need to make conclusions.

abs(a) = a

it is equivalent to

a >= 0.

using this approach it can be possible to implement any kind of expressions for ranged values, like min < value < max.

derivative for the abs(x) function will be sign(x).

for horiz / vert

abs(a.x - b.x) = a.x - b.x

this is equivalent to

a >= b.

this is proven equation, so you no need to make conclusions.

**(no subject)**

*(by walter steffe)*

I agree with your equation equivalence.

In fact sign(a)=1 is the same as abs(a)/a=1 or abs(a)=a.

What I wanted to say is that if the solver does not work well with the equation a>0 the same problem should arise also with sign(a)=1 or with abs(a)=a.

This is because, at each step, an iterative solver explores only a small neighbourhood of the current point.

For a generic point sign(a) does not change inside of that neighbourhood. The equation sign(a)=1 can not provide any usefull information to the local solver and is in effect inactive.

If it were so easy to overcome the inequality limitation why would have Johnatan expressed the following objection to my previous post:

(c) The manner in which equations are solved doesn't lend itself to inequality constraints.

In fact sign(a)=1 is the same as abs(a)/a=1 or abs(a)=a.

What I wanted to say is that if the solver does not work well with the equation a>0 the same problem should arise also with sign(a)=1 or with abs(a)=a.

This is because, at each step, an iterative solver explores only a small neighbourhood of the current point.

For a generic point sign(a) does not change inside of that neighbourhood. The equation sign(a)=1 can not provide any usefull information to the local solver and is in effect inactive.

If it were so easy to overcome the inequality limitation why would have Johnatan expressed the following objection to my previous post:

(c) The manner in which equations are solved doesn't lend itself to inequality constraints.

**(no subject)**

*(by walter steffe)*

I want to correct myself.

The equation

abs(a)-a=0

is inactive (it becomes an identity) only if it is satisfied (a>0) over the neighbourhood.

If a<0 the derivative of equation with respect to a evaluates to -2. So the equation becomes active when it is not satisfied and then I think that it can effectively drive the solution.

The equation

abs(a)-a=0

is inactive (it becomes an identity) only if it is satisfied (a>0) over the neighbourhood.

If a<0 the derivative of equation with respect to a evaluates to -2. So the equation becomes active when it is not satisfied and then I think that it can effectively drive the solution.

**(no subject)**

*(by walter steffe)*

The same thing can non be said about the equation sign(a)=1 which is always inactive because its derivative is always zero (apart of the isolate point a=0).

So EvilSpirit I think you have found a good way to enforce an inequality.

So EvilSpirit I think you have found a good way to enforce an inequality.

**(no subject)**

*(by walter steffe)*

At this point I would like to highlight an important

result of this long thread:

As already pointed by EvilSpirit a possible way to enforce the signed pt-pt distance is trough the following (vector) equation:

p1 = p0 + dir(angle) * distance

or else

p1_x = p0_x + cos(angle) * distance

p1_y = p0_y + sin(angle) * distance

The two equations must be complemented with the inclusion of "angle" among the solver variables.

In that way the number of degree of freedom is reduced by one as expected by a distance constraint.

The initial value of angle can be set using following equation:

angle=atan2(p1_y-p0_y, p1_x-p0_x)

EvilSpirit, you said that this approach is more expensive.

Nevertheless I have yet not seen a valid alternative and I think that the stability of solution (avoiding random jumps) should have higher priority than a fast (but wrong) responce.

result of this long thread:

As already pointed by EvilSpirit a possible way to enforce the signed pt-pt distance is trough the following (vector) equation:

p1 = p0 + dir(angle) * distance

or else

p1_x = p0_x + cos(angle) * distance

p1_y = p0_y + sin(angle) * distance

The two equations must be complemented with the inclusion of "angle" among the solver variables.

In that way the number of degree of freedom is reduced by one as expected by a distance constraint.

The initial value of angle can be set using following equation:

angle=atan2(p1_y-p0_y, p1_x-p0_x)

EvilSpirit, you said that this approach is more expensive.

Nevertheless I have yet not seen a valid alternative and I think that the stability of solution (avoiding random jumps) should have higher priority than a fast (but wrong) responce.

**(no subject)**

*(by EvilSpirit)*

of course, to get the right derivatives we have to write

(abs(a) - a) / 2 = 0

(abs(a) - a) / 2 = 0

**(no subject)**

*(by EvilSpirit)*

Jonathan likes perfomance :) but i can say, what jacobian calculation for each step is not so expensive as linear system solve.

**(no subject)**

*(by EvilSpirit)*

so, one bad equation is better than simple two.

**(no subject)**

*(by walter steffe)*

but which is the alternative single (bad) equation which is able to enforce a signed pt-pt distance ?

**(no subject)**

*(by EvilSpirit)*

there is actually no need to make signed pt-pt distance. there is signed angle through atan2 (perpendicular and parallel) which is make enough to do determinated sketches.

**(no subject)**

*(by walter steffe)*

You are right, It should be sufficient.

**It may not be needed to afoid "flipped" solutions.**

*(by ruevs)*

Hi guys,

In general I agree that it is good to reduce the tendency for the solutions to "flip/tangle" when a parameter "jumps" (is changed quickly by a lot).

What makes the flipped sketches bad is that they are practically impossible to "untangle". One usually has to remove some of the constraints before it can be done. For a complex sketch with a lot of constraints this is impractical.

However there is another solution (apart from - or in addition to - improving the solver/constraints), which is much simpler and will have no performance impact. The idea is not mine, I found it here:

https://news.ycombinator.com/item?id=9248174

Quote:

"For "confused" constraint solvers, I see this as largely being a problem of there being lots of solutions to a well constrained system, because of flips and such. It needs to be easy for the user to specify which one they want.

Our approach was to have fast pulls of the mouse temporarily over ride the constraint solver. So, if you needed to flip the model, you do a really fast pull and it would flip. This works much better with multi touch, where you can just grab a few points with different fingers and force your model into whatever shape you want."

So basically the suggestion is to temporarily suspend the solver when the user moves something very fast. In this way it becomes much easier to "untangle" "flipped" sketches. Otherwise you are "fighting" the solver - and usually you lose. Of course the threshold for "fast" will have to be determined empirically (or configurable).

In general I agree that it is good to reduce the tendency for the solutions to "flip/tangle" when a parameter "jumps" (is changed quickly by a lot).

What makes the flipped sketches bad is that they are practically impossible to "untangle". One usually has to remove some of the constraints before it can be done. For a complex sketch with a lot of constraints this is impractical.

However there is another solution (apart from - or in addition to - improving the solver/constraints), which is much simpler and will have no performance impact. The idea is not mine, I found it here:

https://news.ycombinator.com/item?id=9248174

Quote:

"For "confused" constraint solvers, I see this as largely being a problem of there being lots of solutions to a well constrained system, because of flips and such. It needs to be easy for the user to specify which one they want.

Our approach was to have fast pulls of the mouse temporarily over ride the constraint solver. So, if you needed to flip the model, you do a really fast pull and it would flip. This works much better with multi touch, where you can just grab a few points with different fingers and force your model into whatever shape you want."

So basically the suggestion is to temporarily suspend the solver when the user moves something very fast. In this way it becomes much easier to "untangle" "flipped" sketches. Otherwise you are "fighting" the solver - and usually you lose. Of course the threshold for "fast" will have to be determined empirically (or configurable).

**(no subject)**

*(by Jonathan Westhues)*

That actually happens now, if you move fast enough (by accident, of course, with a threshold determined by the time to solve your sketch). A deliberate implementation of that would of course make that threshold more reasonable.

My intended "untangling" procedure is to check "relax constraints", drag the sketch closer to the desired configuration, and uncheck. That avoids the need to delete constraints.

My intended "untangling" procedure is to check "relax constraints", drag the sketch closer to the desired configuration, and uncheck. That avoids the need to delete constraints.

**(no subject)**

*(by ruevs)*

I never noticed that check-box! Thank you! It is a better solution. Maybe it should be mentioned in your "tutorial on constraints".

For that matter the "threat all dimensions as reference" is also nice and I had not paid attention to it either.

For that matter the "threat all dimensions as reference" is also nice and I had not paid attention to it either.

**(no subject)**

*(by EvilSpirit)*

For the commercial solvers they are use some another approach - they remember parameters for all skecth at start of dragging and for each movement solver starts calculation from the beginning, so it is simple to untangle the sketch. But this looks ugly, entities moves non natural way, not like physical body. I dont like it.

**(no subject)**

*(by Emyr)*

Quote: "i think every code line was rewritten. so i cant call it solvespace anymore, i even cant name it NotSolveSpace. Only approach is the same, code is not... This all will be like separated libraries, only our new code will be closed."

Your whole project is inherently derivative and can only be released under a GPL-compatible license.

It doesn't matter that the code bears no resemblance to what you started with since each version of your code is derivative of the previous, right back to original SolveSpace.

To avoid this requirement you would need to adopt a cleanroom split-team approach, as used by ReactOS: two completely separate teams, the team that writes the new code never has the original code.

Your whole project is inherently derivative and can only be released under a GPL-compatible license.

It doesn't matter that the code bears no resemblance to what you started with since each version of your code is derivative of the previous, right back to original SolveSpace.

To avoid this requirement you would need to adopt a cleanroom split-team approach, as used by ReactOS: two completely separate teams, the team that writes the new code never has the original code.

**(no subject)**

*(by EvilSpirit)*

I am not responsible for it. Chief said we have contacted Jonathan and there is no copyright issues. You can found leaked info using Glo be X,Y C A D keyword. Put it together before googling.

**more votes for "global parameters" feature request !**

*(by elektrouwe)*

any news about a future release with global parameters ?

As soon as this is implemented many of my friends from A,CH,D and me (min. 12 people :-) ) will switch to solvespace. We have access to laser cutters in fablabs and/or at home. One of the most annoying problems we face is the varying thickness of

acryl and plywood sheets from batch to batch or even from end to end of a large format sheet. A global thickness parameter would make our day ! I tried the free version from Siemens solid edge, which has this feature. It is a nice program if you use it every day, but for casual work in a fablab it is too complex. Please solvespace go for it !

As soon as this is implemented many of my friends from A,CH,D and me (min. 12 people :-) ) will switch to solvespace. We have access to laser cutters in fablabs and/or at home. One of the most annoying problems we face is the varying thickness of

acryl and plywood sheets from batch to batch or even from end to end of a large format sheet. A global thickness parameter would make our day ! I tried the free version from Siemens solid edge, which has this feature. It is a nice program if you use it every day, but for casual work in a fablab it is too complex. Please solvespace go for it !

**(no subject)**

*(by Jonathan Westhues)*

It's a good feature, just a question of the work to implement it.

In the meantime, have you tried creating a sketch with a construction line having length equal to your plywood thickness, importing it at the beginning of each part, and then constraining against that line length? That achieves the same effect, just without names for the "parameters".

In the meantime, have you tried creating a sketch with a construction line having length equal to your plywood thickness, importing it at the beginning of each part, and then constraining against that line length? That achieves the same effect, just without names for the "parameters".

**(no subject)**

*(by EvilSpirit)*

Just wait. I am on the way. If you promise me to be a testers(12 pcs) i will implemet it.

**(no subject)**

*(by User1)*

@EvilSpirit,

Please make a new nightly build with latest futures.

I very active on testing and bug reports (if You remember I report about latest bug with crashing after open asm.slvs).

So, please make nightly binary (solvespace and libslvs) for Ubuntu Thrusty 14.04

Please make a new nightly build with latest futures.

I very active on testing and bug reports (if You remember I report about latest bug with crashing after open asm.slvs).

So, please make nightly binary (solvespace and libslvs) for Ubuntu Thrusty 14.04

**Great progress**

*(by ruevs)*

There has been some great progress on parameter support in SolveSpace lately. It is not ready yet, but there is a new (unofficial) version you can try here https://github.com/solvespace/...ues/77#issuecomment-2191629118.

**(no subject)**

*(by ruevs)*

More progress on parametric constraints:

https://youtu.be/qX3N7cF-32w

https://github.com/solvespace/solvespace/pull/1482

https://youtu.be/qX3N7cF-32w

https://github.com/solvespace/solvespace/pull/1482

**Post a reply to this comment:**