Parametric sketches #77
Comments
|
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 |
|
The hard part here is changing the savefile format and adding the UI, unfortunately. |
|
@whitequark no problem here.
|
|
|
@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 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 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: Update: https://www.youtube.com/watch?v=r85jSktKrWw // Alexey Egorov @Evil-Spirit Update 2021-09-26. Even older stuff from the forum: |
|
I'm glad to see some movement on this issue. 'Life' got in my way as I was researching how to supply parameter values and store them in the slvs file. And I haven't been able to get back to it, and several other projects that have been neglected. |
|
@jwesthues The old implementation creates named parameters at the time a dimension is evaluated. I'm not sure when those are evaluated. I also thought those got evaluated to a constant, but in this case expressions are saved and displayed, and can be edited. Any text string in the expression that is not a built-in and not already a parameter name is used to create a new named parameter. So questions about that - not necessarily for @jwesthues
I wanted to either create a new constraint (equation) or just allow equations in the existing comments. Probably a new constraint type. This way we can just type "X=5" as a constraint equation on the diagram. Or even general algebraic expressions with more than one variable. Suddenly SS becomes an algebra tool as a side effect. This should require very little new code. @uberintj if you still want to tackle this, it's all right here right now ;-) It seems like a good intro to some core parts of the code. |
|
@phkahler, I'm trying to get back into the swing of things. Got knocked out of my normal orbit early this spring and am just now getting back to being able to handle my normal work load. Things slow down in the winter, so that's the most likely time I'll be able to dedicate. But I'll chime in here anyway for the things I can answer.
I agree with creating a new constraint type to specify a parameter's value (my terminology is currently 'unconstrained variable'), because this lets us give definitive constraint. I think we need some precedence rules for these, so an assembly being linked into another can have its parameter(s) overridden to make them apply to the linking assembly (I guess this can be generalized down to the GROUPS that source the parameters since linked assemblies end up in groups?). Anyway, this is what I was digging on when I got derailed. And other one...A couple weeks ago you reported
Back here I wrote:
With that issue I think you're running into that incomplete VARIABLE op type 'feature'. I'm still not sure what that is all about. At any rate, I still have this on my radar, but can't make any promises as to time frames. My feelings won't be hurt if someone beats me to it, but it will be in the back of my mind whether I can actually work on it or not. |
Yes. I tried removing that and it fixed the upper-case issue, but broke the test suite (wouldn't build) so I modified the test to look for the new Op::PARAM instead. Then it built but failed the test. Didn't debug it but that is the issue with that. It seems VARIABLE was an idea to implement a similar feature using some other type of "variable" that never got implemented. Evil-Spirits approach of just allowing existing parameters to have names seems like it may be better, and the ability to implicitly create them seems kind of nice. IMHO using a new constraint type Constraint->Equation is the way to go. You can verify the text is an equation by finding the "=" and then get two expressions from either side of that. Then take their difference as a constraint expression. Constraints down in the solver are just expressions that are implied to equal zero. I'd rather leave it to others so I can get back to geometry and NURBS stuff. but I have also been rather busy. |
In my opinion the parametric sketches should introduce NO (or close to none) new user interface. Here is a short description of the idea I've formed in my mind of how this should work over the years.
That is (roughly) the UI - in other words almost no new UI - just equations that work. Of course we will show some "good stuff" in the text window when an constraint that is an equation is selected. As for storing this stuff I was thinking of introducing an entirely new "structure" to the file format - let's call it "user equations list" - that holds all equation in the |
@uberintj Not at this time. That requires #78 (self contained sketches) and #80 (Hierarchical sketches). Currently linked sketches are static with no regeneration of groups happening within them, so there is no way to modify any part of them. What I'm hoping for short term is to get the named parameter stuff merged in a way that is useful within the current limitations. I would like equations that create named parameters to do so when linked into another sketch. This would allow a simple sketch containing definitions "N=5", "width=15" to be linked into a sketch, and you could link different version of it with different values and these would be used in later groups of the present sketch. I other words you could link in a parameter table and swap it out later. Fully hierarchical sketches is probably going to break file compatibility anyway, so I'd like to put it off as long as possible. We can build a lot towards it prior to then while maintaining compatibility and adding new features. Having named parameters implemented in some form should make less work at the time of change, and will allow people to experiment and figure out what it would ideally look like. @ruevs I disagree with part of your proposal. I don't think it's appropriate to type an equation into a dimension. An expression is fine (just like now), but an equation doesn't make sense. Also, as soon as we allow named parameters in those expressions, they have to be re-evaluated during group regeneration/solving. So the expression has to be stored rather than evaluated and saved as a single value. There is some question about displaying the value or expression on the sketch. The current patch displays the expression and the old video shows adding an additional reference dimension to display the value. I'm not a fan of that, but it seems like a detail to work out after a more complete implementation is done. Adding equations in constraints could be done by looking for valid equations in comment constraints but I think it may be better to have an actual equation constraint type that is largely like a comment. This is a very minimal UI change. The existing patch has essentially zero new UI while adding a good bit of capability - but not quite enough. Edit: Maybe I read that comment about overriding parameters wrong. I meant a linked file should be able to provide parameter values to the "linking" file. Maybe you meant the same thing. |
|
@phkahler That explanation makes sense and gives me a better idea of the scope of changes that fit in with the history of this project. I was kind of conflating all of those things into this ticket to get a full parametric sketches feature complete. I'm good with the incremental steps required to get there. And I did mean that the linking file should be able to override parameters of incoming linked files - to me, this would be the epitome of a parameterized design where it's defined in the place where it is used. I also agree about equations being a different beast and making a specific constraint type and UI facilities for them, not that my experience here bears much weight. Just from a high level, it seems to make more sense to have the assignment of parameter values be a specific 'thing' with it's own use cases and flow, however simplistic those requirements may be. |
@uberintj That's a tricky one. I don't think overriding existing parameters is a great idea. I think the linked sketch should have it's own "local variables" if there is a name conflict. If you've ever used Simulink (block diagrams) I like their concept of a "mask" which can be used to define parameters on a per-instance basis. So maybe a sketch contains a parameter table with defaults, and when linked you can override those with different values per instance. These would be stored in the parent sketch. This gets back to the idea of a parameter table of some sort rather than just named parameters in the solver. If we do go with some kind of parameter table, would there still be interest in the idea of general algebraic equations typed on the sketch? I still think that's also a cool interim way to define fixed values ;-) A parameter table probably belongs in the text window and that makes more sense when it's per instance for linked sketches later on. |
|
@phkahler I think we may be having a vocabulary issue here, and it's probably my fault for not being more versed in this problem domain. The per-instance basis solves the use case I mainly think of with a parameterized model, which is: I can define something, and reuse it in different contexts to get the most use out of that design. Think nested end tables - they all look the same but are of progressively smaller dimensions. Or even screws - they are mostly the same except for sizes and pitches. Pulleys with different diameters and different sized holes for the shafting. Things like that. So your idea of a parameter table puts words to what I envisioned at least. A place in the text window where you could define default values for them and some way to specify what those values should be when you reuse the model. As for the expressions/equations in the model I think that's too powerful to let go. It seems like removing them would require specifying a distinct parameter for each of those constraints instead. |
See solvespace#1428. Unimpl markers for solvespace#77 lead to an assert failing if the user accidentally enters an uppercase letter as the first character of a dimension. This leads to the application crashing unexpectedly. Now it shows the expected error message
|
@phkahler I'm currently working in the parameters branch. When I was writing some code to let users edit parameterized constraints (with their original expressions, instead of by-computed-value), I ran into a problem: units. The way I see it, we have a few options: In inches mode, the formula becomes: And of course we would do a little bit of simplification of the formula between conversions so you can convert back and forth without making super long formulas Benefits:
Drawback:
Alternative: Dimensional Analysis Example: Suppose a user, in mm mode, types in: User in inches mode sees c_1 * p_2 + c_2 + p_2, except the parameters p_1 and p_2's current values are divided by 25.4, and c_2 is divided by 25.4 Possible edge case/confusing behavior: Which parameter, p_1 or p_2, is expressed in mm^2, and which parameter in 1/mm? If we had more constraints, we could probably stick all the constraints into a matrix and do the dimensional analysis to figure out what's what. Should one of the parameters be dimensionless and the other parameter be rescaled? Benefits:
Drawbacks:
We could totally pick a certain convention and stick to it. I think the goal should be to do something that the user would consider predictable and correct. I'm worried that dimensional analysis may lead to the system making incorrect assumption and re-writing people's formulas when they convert from inches to mm in ways that they may not predict or approve of. |
|
@dgramop Thanks for looking at this and finding this extra complication! It's hard to think through all the use cases, but maybe the idea of a list of named parameters would be good after all. If there are name/value pairs then we could do unit conversion at that time - say in the text window where a list of these might exist. But when I saw the demo of the branch and then tried it, I envisioned using Solvespace as a general purpose algebra tool, and I still like that idea. Just typing in a system of equations and having them solved seems so close at hand. But if we have to specify values (to deal with unit conversion) then they really can't be solved for and just become fixed named parameters. That's what everybody really wants for CAD so it's not the end of the world. @jwesthues What do you think of 1) the parameters branch with the @Evil-Spirit changes and 2) The problem mentioned above about trying to deal with units in general expressions? Or should we settle for just having named parameters defined in the text window and do unit conversion there? |
|
I for one, do not see a problem with units. SolveSpace is in mm internally - in RAM and in the .slvs files on disk. We should just store all constants inside user entered formulas in mm and convert them back and forth for display, No more, no less. Bo mixing of units in formulas allowed, no lists of parameters needed. |
To be more specific what I propose is that in inches mode the formula becomes:
where all expressions in the brackets are displayed as numbers - already calculated. e.g. in mm: That's all. |
@ruevs Regardless of how we deal with units, I'm very much in favor of adding names to solver parameters rather than having separate storage of "variables" as suggested by the existing stub and test case. What if arbitrary constraint equations are allowed? How should units be handled for this: |
My first impulse might be to split the work into three stages:
Each of those stages is useful in isolation, and I don't think implementing each next stage breaks backwards compatibility. I haven't thought about this much recently, though. |
|
Here's my latest thought and it's pretty simple. Do everything like we were thinking, including allowing arbitrary constraint equations with named parameters. Then, when parsing an expression for a dimension just take the expression and multiply the entire thing by the scale factor for the units needed by the dimension (expr)*conversion. This allows parameters to have the values the user types in, allows equations to be solved without worrying about units, but drops the appropriate scale factor in place behind the scenes for expressions that represent a distance - not for each parameter, but for the expression. This is what it does today when you type an expression for a constraint - parse the expression and then apply the scale factor based on selected units (and somehow the type of dimension - length vs angle). @dgramop @ruevs Would this cover all or most of the bases? As I see it, the main branch evaluates an expression, converts the resulting number based on units and drops that in a constraint equation, while the parameters branch drops the expression right into the constraint equation without evaluation. Is this correct? If so, all we need is to drop the expression times the scale factor into the constraint equation. Right? Did he just miss that multiplication? |
|
This is more complicated than I initially thought - I apologise for my last comment. I was thinking only of units in the sense of mm, inches etc. Instead of in the sense of physics units. The problem comes from dimensionality mm², mm³, 1/mm, tan(mm) etc. and from degrees. I will read all comments from the last few days and think about it carefully. Like @phkahler, I still really like allowing "arbitrary algebra" but the dimensions/units need to be taken into account somehow... |
This would cover all the bases, and have good predictable behavior, and add no burden to the user. We could do it this way and see if people complain. If they do, we can see what the users are clamoring for and cater more directly to that. |
@phkahler I'm not sure I understand the desired behavior here. Like if I define
|
|
I've been thinking about this all day and have changed my opinion like 3 times.
Benefits:
Drawbacks:
Scale factors are easy and gets this feature rolling soon, so that we can get feedback and cater to what users might actually want. Overhauling the unit system adds a ton of scope, but I wouldn't mind coding that up. Why I think @jwesthues 's approach is worth the cost to the userI used to do most of my CAD work in openSCAD. I could hop on a plane, design something based on the vague idea of the shape and make everything a function of a few variables. Eventually, I could take measurements of whatever my design was supposed to plug into, fit with etc. and punch them in the variables. Then 3d print. Since openSCAD really doesn't have units, each of my variable names would have an associated units. This way, when it came time to measure other parts, I would know exactly what to measure. It felt almost like a datatype - just another form of metadata on a variable. This is similar to what we would ask users to do in solvespace I'm driven to solvespace since it would be nice to have a more traditional CAD experience without giving my workflow of design-then-measure. Do we want to be agile and use the scale factor solution, waiting to see if people want a more opinionated system? |
I think for this solution we could just tack on the scale factor without simplifying, unless we can find the exact inverse of the scale factor in the formula (in which case we simplify to 1). That way we don't have to pick what to scale (ambiguous behavior) and the user knows exactly what happened (recognizable constant multiplying their formula) |
|
@dgramop Okay, I think I get @phkahler's proposal now. Basically when we change display units, we multiply a scale factor onto the expression as displayed to and editable by the user, and then silently divide by the same scale factor internally when we evaluate it. So the geometry doesn't change, but the displayed quantity is in the right units. So in my example, we still show That's relatively low effort, and results in display in correct units. The displayed scale factors are ugly, but a user who always works in the same units will never see them. I don't think that breaks backwards compatibility for any of the fancier options later. So I don't love that, but probably prefer it to "always in mm". |
There should be a way, through the text window, to input a table of parameters. These parameters could then be used in expressions around the sketch, and so the entire sketch could be reconfigured by changing a single parameter value.
There should also be a way to define sets of parameters. E.g. "set A" with a=1, b=10, and "set B" with a=2, b=15. Every set of parameters would define a specific product, with the given dimensions.
For every parameter, there should be the following configuration:
Depends on #75 (since we need to save this table), and #76 (since if changing parameters would break chirality, it's useless).
The text was updated successfully, but these errors were encountered: