hlorus
Use official solvespace python package
This switches the solver from the inofficial binding to the official python binding of solvespace which has the benefit of being more uptodate as well as being stateful. There are currently some remaining issues:
- The SolveResult's bad field is just a number, what does this represent? Is it the handle of the failed constraint? If so, can't there be more than one failed constraints?
- What is the SolveResult's 'rank' field for?
- SlvsArc and SlvsCircle take a 3d normal as input, shouldn't that be a 2d normal?
- How is the 'distance_proj' ment to be used? Shouldn't it have an input to defone the direction of the projection?
- The tangent constraint fails in some cases:
- between a curve and a line if they are not connected
- between two curves
@vespakoen congrats on the progress on the python binding, this is a great improvement!
This switches the solver from the inofficial binding to the official python binding of solvespace [...]
Note that you also need to update the following definition, as the errors that the solver returns have changed (in this PR you're using dev24, which just removed values 4 and 5, but dev28 added back REDUNDANT_OKAY, although with a value of 4 instead of 5):
https://github.com/hlorus/CAD_Sketcher/blob/3fb273c1d346450f7f6e458840ab3e3a6a1cefff/global_data.py#L39-L95
- The SolveResult's bad field is just a number, what does this represent? Is it the handle of the failed constraint? If so, can't there be more than one failed constraints?
It represents the number of bad constraints. To get the list of bad constraint you'll need to use the system solve function rather than the sketch solve one, but this one unfortunately isn't exposed in the Python bindings (and for good reason, as for now building the system involves much more manual work compared to adding entities to the sketch which has a proper API).
- What is the SolveResult's 'rank' field for?
I suppose it was originally meant for exposing the rank of the Jacobian matrix, so that it could be used to calulate DoF, but all of this is now internal to the solver, and the rank member is never actually set anyway, so it probably should be removed now.
@iscgar Thanks alot for your help and the work on the bindings!
It represents the number of bad constraints. To get the list of bad constraint you'll need to use the system solve function rather than the sketch solve one, but this one unfortunately isn't exposed in the Python bindings (and for good reason, as for now building the system involves much more manual work compared to adding entities to the sketch which has a proper API).
That's indeed really unfortunate! Is it planned to be added to a later version of the python bindings? I'm afraid this is a showstopper since it's quite a big regression.
On a similar note: People often ask for DOF per entity, is this something that migth be added to the bindings as well?
It represents the number of bad constraints. To get the list of bad constraint you'll need to use the system solve function rather than the sketch solve one, but this one unfortunately isn't exposed in the Python bindings (and for good reason, as for now building the system involves much more manual work compared to adding entities to the sketch which has a proper API).
That's indeed really unfortunate! Is it planned to be added to a later version of the python bindings? I'm afraid this is a showstopper since it's quite a big regression.
I've only recently started working on SolveSpace because I was interested in CAD Sketcher and started looking into the underlying solver, so @vespakoen is likely much more qualified than me to answer that, though I can think of a few ways this can be done, with minimal changes to the library (the easier way would probably be to add an optional out parameter to the sketch solve function that points to a list that could be populated with the bad constraints, if there are any).
On a similar note: People often ask for DOF per entity, is this something that migth be added to the bindings as well?
SolveSpace itself doesn't do DoF calculation per entity, only per group, so this requires some work on the solver to allow it to calculate DoF per entity (although that would likely slow things down).
Yes, there is an open PR waiting for review. It is linked in the issue https://github.com/solvespace/solvespace/issues/1546
