What is the current status of this? This is basically the only feature I'm currently missing.

This is a major feature that depends on updating the savefile format, unfortunately.

@whitequark
I've made a prototype https://youtu.be/r85jSktKrWw

The hard part here is changing the savefile format and adding the UI, unfortunately.

@whitequark no problem here.

1. just save one more textfield.
2. just another text screen with list of parameters and ability to change names.

The hard part here is changing the savefile format and adding the UI

1. One more text field is good solution; For export list of variables/parameters use CSV format.

2. Current line styles UI could be used as template for variables/parameters UI.

@Symbian9 Anyone can say "could be used as a template". How about writing the code for it? I'm not interested in your opinions, I have mine.

Is the intention to only support explicit constraints of the form x = express/function of other variables, or implicit constraints could also be in the scope of this bug.

Something like this:

where the constraint definition (and its text) is not attached directly to any entity, and there is no way to solve for one specific variable. Should be possible to incorporate this into existing solver using Lagrange multipliers maybe?

@Evil-Spirit That is a very cool and impressive demo. Had you had chance to do more work on it recently?

@baryluk Hello, unfortunately, I have no time for doing that. But if someone wants integrate this, I can help in advice. Ofc we can intoduce such kind of constraint like arbitrary equation, so It will be awesome! At the moment I need such thing inside my CAD project NoteCAD and may be I will implement this.

Done! So if someone wanted to have such thing in SolveSpace, I can point where and how it can be implemented.

@whitequark what if we just use @Evil-Spirit implementation which seems to identify variables in expressions and create a parameter for them. Then add a new constraint type "equation" where you can type things like: x=5 or aa + bb = c*c the equation constraints would need a text string that would need to be saved in the file, much like the parameters would need name saved.

The equation constraints could be placed at the top of the constraint list in the text window where they could be edited. This would be a bit limited, but fairly simple and useful.

Let's discuss this once 3.0 is out. I don't think we need any more features to delay the release.

Oh I completely agree with that!

@Evil-Spirit While there is a lot to do for this to be a feature, I took some time to rebase it on master before it bit-rots too much. You can try it on my "parameters" branch here: https://github.com/phkahler/solvespace/tree/parameters

Commit: phkahler@d6f9730
or Patch: https://github.com/phkahler/solvespace/commit/d6f9730a33906a56371f2d0df232529707b84b1c.patch

I saw the video months ago and wanted to try it myself. Very nice!

It seems, it needs to introduce one more list to represent parameters in browser.

@phkahler two links to be aware of:
https://github.com/ryannining/solvespace // Parametric sketches Ryan Widi
https://youtu.be/UPgOUa1Q2Ns

Update:
Since this keeps coming up I will dump here all my links to relevant information that are not already in this issue:
https://solvespace.com/forum.pl?action=viewthread&parent=3169&tt=1598104778 // Parametric sketches
https://solvespace.com/forum.pl?action=viewthread&parent=1383&tt=1469710256 // Minor change (by RYAN WIDI SAPUTRA)
https://www.youtube.com/watch?v=UPgOUa1Q2Ns
https://www.youtube.com/watch?v=o0ONJMqz8H8
https://www.youtube.com/watch?v=lKpvIbZh47M
https://www.youtube.com/watch?v=6eSkfgW02ww

https://www.youtube.com/watch?v=r85jSktKrWw // Alexey Egorov @Evil-Spirit

Update 2021-09-26. Even older stuff from the forum:
https://solvespace.com/forum.pl?action=viewthread&parent=211

I merged the great contribution from @dgramop into https://github.com/solvespace/solvespace/tree/parameters. Thank you very much!

Parameters are now "convincingly working" ;-)

For those who have wanted this for years but do not compile SolveSpace themselves, I attach a Windows binary to try out. Please play around with it and let us know what you think.
solvespace_parameters_e52d37c.zip

You can see what it can do here #1433 (comment) and from the example model here #1433 (comment).

From the discussion above you can see some interesting points to try. For example try making parametric sketches and then changing units - does is work "intuitively"? What happens when if one uses parameters from a different group (I haven't tried :-)?

Thanks, this is really great! There are still a few places where variables don't seem to be accepted yet. Like e.g. for the number of repeats in a linear array. But this is a big step forward!

places where variables don't seem to be accepted yet. Like e.g. for the number of repeats in a linear array.

Ha! This is an interesting thought. If we make the number of repeats in a step translating/rotating group an equation with parameters - like all other constraints - that may be a unique fearure among all CAD software.

Would it be?

Of course we will have to round or truncate the number of repeats resulting from the equation.

We have the solver powering everything, let's go nuts!

Would it be?

I'm sure somebody's cad supports variable input for repeats, but parameters are always a hacked-in afterthought for mainstream cad modelers. thanks to the nice underlying solver and all the other design decisions made long ago, i feel like solvespace readily takes these kinds of features. I doubt any other cad so richly integrates parameters with constraints... then again I mostly use FOSS cads and sparingly free versions of professional software.

Like e.g. for the number of repeats in a linear array

This would be a very useful feature. I for one would like to use it in many of my models. For situations where I need something that parametric, I must turn to OpenSCAD. I think round-down truncation is a sensible. We can also introduce explicit ceil and floor operators

@NothanUmber Do you have time to carry the torch for this excellent feature idea you suggest? I am unlikely to get around to it for a few months, with some other pressing projects using up all my cycles. I think it's a good entry point to the parameters branch and solvespace.

The variable pattern feature would indeed add wings to Solvespace!
But I think I would still need a rocket to get me to my current target, the moon. Or, let's say at least a very strong catapult that supports joint sketches (so the linear pattern can be part of a sketch that can then be e.g. extruded), And lofts. And optimally fillets (so I would not have to switch programs for that step).
But will keep an eye on Solvespace for other, more fitting projects!

the linear pattern can be part of a sketch that can then be e.g. extruded

That "just works™". Here is an example with step rotating #841 (comment)

Everybody wants chamfer/fillet and many people want loft ;-)

Thanks, looks promising!
Imho loft would be much more important than fillets. Because adding fillets is the last "sugar on the cake" step that might have to be redone anyways in case of bigger geometry changes. So doing this in another program isn't so bad.
But creating complex bodies by lofting between different sketches is often very hard to substitute.
Can often be tricky which points to connect though. Some programs fully rely on heuristics (with more or less desirable results) or manual point assignment (which can also lead to problems when the geometry changes a lot).
So it is a sound approach to have a CAD system that focusses on 100% "stable" features. Which works very reliable in the supported cases. And leaves the other tasks to the many heuristics based CADs.

I still like the CadQuery loft approach the most. It is very simple but also pretty predictable. As I understand it: Connect the first point in one sketch to the first point in the second and so on. So one has to specifically make these sketches for this purpose. But as all sketches are generated programmatically there it doesn't hurt.

I still like the CadQuery loft approach the most. It is very simple but also pretty predictable. As I understand it: Connect the first point in one sketch to the first point in the second and so on.

I've had this thought for Solvespace. When we extrude, copies of all the sketch entities are made at the end of the extrusion (2 copies for double sided) and these are simple transforms of the original sketch entities. It might be possible to make copies that are embedded in a plane but otherwise free to be moved and constrained (perhaps copy the constraints too but allow deletions?) the extrusion surfaces would still connect entity to entity - point to point - but the new ones would be movable and constrainable.

Of course then people will come along with all sorts of new options they want - can the new plane be non-parallel to the first one? Oh now we need to allow manipulation of the surface curvature between the planes. And on and on.

Hey, loft has it's own issue - don't "scatter" the discussion ;-)

@NothanUmber this may be of interest to you

just hacked together proof-of-concept. really an experiment for adding expression support to groups with inputs in the text window. was this approach/effect/result jive with what you were thinking?

Hi! Just to understand what you did - you added x+3 as a driven dimension constraint to the width of the rectangle and then used that "x" as expression to drive the amount of copies in the linear pattern? If yes then this is indeed one incredent of the things I had in mind!
I want to pattern two sketches on parallel construction planes, both N times. And then select both patterns and loft the closed wires in those pair-wise (first wire-loop in pattern on one plane with first pattern on parallel plane etc, second wire-loop on plane one with second wire-loop on plane two etc.)
The distance between the pattern instances would be two separate parameters and the width and height of the base sketches could also be changes separately. This would give a highly parametric way to create a multitude of lofts that could then e.g. be used to carve non-parallel pipes with variyng thickness on different places into a block. Or alternatively, using the parametric pattern as part of a sketch made from different sub-sketches - that are then later lofted. So one could get a similar result as described before without boolean subtraction, just by preparing more complex sketches with N "pipe channels" or holes. (At the point where I wrote about the parametric patterns I didn't realize yet that solvespace has currently no lofts yet, which would be incredent no. 2 - but having this could also be useful in many other scenarios outside of my specific one of course!)
Thanks for your experiment, looks very promising!

Great. For now let's tackle the parametric repeat ingredient. That way I can be a little more atomic about my changesets. I can ping you when I make a PR so that you can help test the branch

Yes, great! Sorry if my posting came across unthankful, that was not the intention. I finally found a solution how I can proceed with my project in FreeCAD. But I still like the concept of Solvespace and will gladly test your PR!

No not at all haha. I too have to use other CAD programs occasionally when I need some missing feature urgently. Lofting is definitely a good one to have.

Just wanted to put this here before I forget. We should perhaps cache parsed (and simplified) expressions alongside the constraints (and in the latest PR, groups) that they apply to. Right now I've left some perf on the table by re-parsing these expressions even when they have not changed. Fields that use no parameters in their expression can skip the parameter evaluation altogether.

This will motivate some nicer structuring around string expressions, their cached trees, and cached values. It will also let us go crazier with parameters, and for example parameterize colors

It will also let us go crazier with parameters, and for example parameterize colors

PLEASE NO!!! One thing we eventually want is physically based rendering (PBR).
#1217

That will need a change to the color model and maybe named materials. The notion of parameterizing colors seems like such a programming nerd geek thing to do ;-) I'm usually in favor of generalizing things, but that is going too far.

IMHO every open source developer needs to read the Darktable rant:
https://ansel.photos/en/news/darktable-dans-le-mur-au-ralenti/

And understand where he's coming from. And adopt a similar outlook.

Before going hog wild with parameters, can we please get the scope rules working correctly with what exists?

With you on the complexity limit. Skimmed the article and see where you're coming from. I'll take off my rose-colored parameters glasses. Colors will be saved from my parameterization campaign 🫡

Scope rules are definitely the next thing to hit here

@dgramop I've metioned before that I think the scope issue is in the creation of the parameters and handles when parsing:

#1433
#1436

Since we've talked about defining parameters in the text window, I think a new request type to create a parameter and a little text window UI to edit them might just solve the scope issues. We'd then disable creation of new named parameters while parsing expressions while still using them. I've been meaning to try this, but as you can tell I've been away from Solvespace this past year. BTW I'm planning to dive back in soon.

Something that just occurred to me. Since it has not been mentioned in a while - @dgramop take a look at the changes that @ryannining did in 2016 - at least as a "second opinion" and a source of ideas.

#77 (comment)
#77 (comment)
#77 (comment)

Using the windows build offered in the comments above, the solver will complain of an unsolvable constraint when adding named parameter-based constraints to multiple group's sketches after a first group's sketch already has constraints built out of named parameters. Additionally, it is impossible to reference a named parameter defined in a different group. This makes named parameter-driven constraints only useful within a single sketch of a part.

I think we have a huge problem with this - handling UNITS. Solvespace currently stores distances in mm regardless of what units are selected. The conversion is done when you type them in, and when displayed. That mean you can draw a sketch in inches and then switch the display to feet/inches and it will show everything in imperial units.

If we convert parameters to units when entering values in the text window and then use them in expressions on a sketch, what happens if the user changes units for viewing? What about other constants entered into an expression? If you enter "size + 5" we are going to store the expression as a string, so how should constants be interpreted WRT units? We certainly don't want a UI change of units to cause geometry to change.

If parameters are converted in the text window, then they will also have to be "checkboxed" if they are a length, since angles don't have units (degrees only) and constants that might be multiplied shouldn't either.

Not sure where the other comments on units were, but IIRC someone suggested the equivalent of type inferencing to figure it out. But even that would require units to be set at the dimension or sketch level.

My original thinking was to store parameters without units and just multiply the expression by the appropriate scale factor. The problem with that is the scale factor will change if the user changes units or opens a file with the setting different and then the dimension will change.

You can try some of this with my named_parameters branch
BTW scope rules are not correct, but you can use a parameter in subsequent groups and it will behave as a constant.

My original thinking was to store parameters without units and just multiply the expression by the appropriate scale factor. The problem with that is the scale factor will change if the user changes units or opens a file with the setting different and then the dimension will change.

Possible solution: When an expression has no parameters we'll treat is just like now - convert linear dimensions to mm and store that in valA of the constraint. When there are variables in the expression we'll store the string AND store the current scale factor (1, 25.4, 1000 for mm, inches, meters) in valA. During regeneration if there's no string we'll convert valA to a constant expression just like before - If there is an string, we'll convert it to an expression and then multiply that by valA (also converted to an expression) and hand that to the solver. This way parameters can remain unitless, but expressions in dimension will pick up the unit conversion at the time the expression is typed in and keep it until the user changes it - but it will preserve its value during regeneration even if the displayed units are changed or the file is opened with a different unit setting. This may have some occasional odd behavior but should work as expected in all the common use cases.

Using the windows build offered in the comments above, the solver will complain of an unsolvable constraint when adding named parameter-based constraints to multiple group's sketches after a first group's sketch already has constraints built out of named parameters.

With regard to this unsolvable constraint bug, I have a fix (PR #1549 ). This is my bad.

This happens because parameters created inside a relation constraint are not added to the correct list before being passed to the solver.

This led to the solver being unable to solve an unused relation constraint. WLOG, say you use the default relation constraint x=5. The solver, in trying to solve x-5=0, then has 0 parameters to nudge, so it can't just set x = -5. Now if you added, say a line segment, and used this parameter, the expression in the line segment would have added the parameter to the correct list. Now the solver is actually passed x as a free variable and can solve for it.

For cross-referencing, that's another can of worms and the discussion of how to approach is still ongoing iirc.

You can try some of this with my [named_parameters branch (https://github.com/phkahler/solvespace/tree/named_parameters)

I had the chance to sit down and try your branch. Love where it's headed. I do think it would be cool to have group-scoped-parameters get auto-created if you start using them in an expression (insert if not exists). I'm excited to see your changes land in the common branch!

If there is an string, we'll convert it to an expression and then multiply that by valA (also converted to an expression) and hand that to the solver

Imagine if you switch back-and-forth between inches and mm to quickly punch in a few measurements. While it's clear to the user what's happening and eliminates guesswork, it felt a bit like cheating. If I'm understanding what you mean by regeneration, then that might not be so clutter some.

My understanding of regeneration: When a user edits an expression, the factor leaves the expr_scaling_to_base (or equivalent) field, and joins the string expression. Otherwise it's multiplied. I think this behavior exists in parameters (I may be mistaken)

Somewhere in my git tree is a lost expression simplifier that would find and eliminate conversion factors that divide/multiply to 1.

If we do dimensional analysis, we could bubble up ambiguity resolution to the user for when our dimension analysis fails, and associate dimensionality with each parameter, this way we have clear conversion factors.

I think we have a huge problem with this - handling UNITS.

Units... I still have no idea how to handle them. From studying physics my inclination is to always carry the units through the calculations and make sure they make sense. But on the other hand what if I wanted to make the area of a circle equal to the length of a line segment - as a number e.g. 100mm^2 = 100mm. The current parameters branch allows it:

ParametersCircleAreaCircumference.zip

And of course it "breaks" when one switches to imperial:

As senseless as making an area be equal to a length may be; it "tickles" a "don't impose limitations" in programs "fetish" in me :-)