zcy
/
solvespace
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
solvespace/src/lib.cpp

264 lines
8.5 KiB
C++
Raw Normal View History

Clean up SolveSpace makefile, and add forgotten copyright notice. [git-p4: depot-paths = "//depot/solvespace/": change = 2213]
2013-07-28 22:53:30 +00:00
//-----------------------------------------------------------------------------
// A library wrapper around SolveSpace, to permit someone to use its constraint
// solver without coupling their program too much to SolveSpace's internals.
//
// Copyright 2008-2013 Jonathan Westhues.
//-----------------------------------------------------------------------------
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
#include "solvespace.h"
Build the demo version of the solver library as a DLL, not a static library. If I understand correctly, that will avoid all the compiler version issues with different required versions of libc. [git-p4: depot-paths = "//depot/solvespace/": change = 2167]
2010-07-10 18:53:30 +00:00
#define EXPORT_DLL
Move library header to include/ directory
2015-03-02 18:06:59 +00:00
#include <slvs.h>
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 15:31:23 +00:00
Sketch SolveSpace::SK = {};
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
static System SYS;
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
static int IsInit = 0;
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
void Group::GenerateEquations(IdList<Equation,hEquation> *l) {
// Nothing to do for now.
}
Refactor Cnf* functions. On Windows, freeze.{cpp,h} was factored into w32main.cpp. The old implementation was too redundant and leaked registry key handles. On all platforms, Cnf* functions now use std::string. This simplifies code everywhere, but will be particularly useful when the Windows port switches to the *W WinAPI functions.
2015-12-26 15:54:26 +00:00
void SolveSpace::CnfFreezeInt(uint32_t v, const std::string &name)
And fix some typos in that documentation for the SolveSpace library, and stub out a function to make it build again. [git-p4: depot-paths = "//depot/solvespace/": change = 2112]
2010-01-23 03:47:00 +00:00
{
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
abort();
}
Refactor Cnf* functions. On Windows, freeze.{cpp,h} was factored into w32main.cpp. The old implementation was too redundant and leaked registry key handles. On all platforms, Cnf* functions now use std::string. This simplifies code everywhere, but will be particularly useful when the Windows port switches to the *W WinAPI functions.
2015-12-26 15:54:26 +00:00
uint32_t SolveSpace::CnfThawInt(uint32_t v, const std::string &name)
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
{
abort();
Compare ((char *)p)[0] against '\0', not (char *)p. Also make the library example compile again under MSVC, and make the perl scripts to build the image tables work.
2013-12-08 08:32:50 +00:00
return 0;
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
}
Pack everything into `namespace SolveSpace`. This is required to avoid name conflicts with the Cocoa libraries on OS X. I renamed the `class SolveSpace` to `class SolveSpaceUI`, because that's what it does, and because otherwise the namespace would have to be called something else than `namespace SolveSpace`.
2015-03-23 17:49:04 +00:00
void SolveSpace::DoMessageBox(const char *str, int rows, int cols, bool error)
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
{
abort();
And fix some typos in that documentation for the SolveSpace library, and stub out a function to make it build again. [git-p4: depot-paths = "//depot/solvespace/": change = 2112]
2010-01-23 03:47:00 +00:00
}
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
extern "C" {
void Slvs_QuaternionU(double qw, double qx, double qy, double qz,
double *x, double *y, double *z)
{
Quaternion q = Quaternion::From(qw, qx, qy, qz);
Vector v = q.RotationU();
*x = v.x;
*y = v.y;
*z = v.z;
}
void Slvs_QuaternionV(double qw, double qx, double qy, double qz,
double *x, double *y, double *z)
{
Quaternion q = Quaternion::From(qw, qx, qy, qz);
Vector v = q.RotationV();
*x = v.x;
*y = v.y;
*z = v.z;
}
void Slvs_QuaternionN(double qw, double qx, double qy, double qz,
double *x, double *y, double *z)
{
Quaternion q = Quaternion::From(qw, qx, qy, qz);
Vector v = q.RotationN();
*x = v.x;
*y = v.y;
*z = v.z;
}
void Slvs_MakeQuaternion(double ux, double uy, double uz,
double vx, double vy, double vz,
double *qw, double *qx, double *qy, double *qz)
{
Vector u = Vector::From(ux, uy, uz),
v = Vector::From(vx, vy, vz);
Quaternion q = Quaternion::From(u, v);
*qw = q.w;
*qx = q.vx;
*qy = q.vy;
*qz = q.vz;
}
void Slvs_Solve(Slvs_System *ssys, Slvs_hGroup shg)
{
if(!IsInit) {
InitHeaps();
IsInit = 1;
}
int i;
for(i = 0; i < ssys->params; i++) {
Slvs_Param *sp = &(ssys->param[i]);
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 15:31:23 +00:00
Param p = {};
Trim trailing whitespace.
2015-03-29 00:30:52 +00:00
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
p.h.v = sp->h;
p.val = sp->val;
SK.param.Add(&p);
if(sp->group == shg) {
SYS.param.Add(&p);
}
}
for(i = 0; i < ssys->entities; i++) {
Slvs_Entity *se = &(ssys->entity[i]);
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 15:31:23 +00:00
EntityBase e = {};
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
switch(se->type) {
Add locked-where-dragged constraint to library interface, and update some copyright dates and bad grammar in comments. [git-p4: depot-paths = "//depot/solvespace/": change = 2137]
2010-05-07 02:13:57 +00:00
case SLVS_E_POINT_IN_3D: e.type = Entity::POINT_IN_3D; break;
case SLVS_E_POINT_IN_2D: e.type = Entity::POINT_IN_2D; break;
case SLVS_E_NORMAL_IN_3D: e.type = Entity::NORMAL_IN_3D; break;
case SLVS_E_NORMAL_IN_2D: e.type = Entity::NORMAL_IN_2D; break;
case SLVS_E_DISTANCE: e.type = Entity::DISTANCE; break;
case SLVS_E_WORKPLANE: e.type = Entity::WORKPLANE; break;
case SLVS_E_LINE_SEGMENT: e.type = Entity::LINE_SEGMENT; break;
case SLVS_E_CUBIC: e.type = Entity::CUBIC; break;
case SLVS_E_CIRCLE: e.type = Entity::CIRCLE; break;
case SLVS_E_ARC_OF_CIRCLE: e.type = Entity::ARC_OF_CIRCLE; break;
default: dbp("bad entity type %d", se->type); return;
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
}
e.h.v = se->h;
e.group.v = se->group;
e.workplane.v = se->wrkpl;
e.point[0].v = se->point[0];
e.point[1].v = se->point[1];
e.point[2].v = se->point[2];
e.point[3].v = se->point[3];
e.normal.v = se->normal;
e.distance.v = se->distance;
e.param[0].v = se->param[0];
e.param[1].v = se->param[1];
e.param[2].v = se->param[2];
e.param[3].v = se->param[3];
SK.entity.Add(&e);
}
for(i = 0; i < ssys->constraints; i++) {
Slvs_Constraint *sc = &(ssys->constraint[i]);
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 15:31:23 +00:00
ConstraintBase c = {};
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
int t;
switch(sc->type) {
case SLVS_C_POINTS_COINCIDENT: t = Constraint::POINTS_COINCIDENT; break;
case SLVS_C_PT_PT_DISTANCE: t = Constraint::PT_PT_DISTANCE; break;
case SLVS_C_PT_PLANE_DISTANCE: t = Constraint::PT_PLANE_DISTANCE; break;
case SLVS_C_PT_LINE_DISTANCE: t = Constraint::PT_LINE_DISTANCE; break;
case SLVS_C_PT_FACE_DISTANCE: t = Constraint::PT_FACE_DISTANCE; break;
case SLVS_C_PT_IN_PLANE: t = Constraint::PT_IN_PLANE; break;
case SLVS_C_PT_ON_LINE: t = Constraint::PT_ON_LINE; break;
case SLVS_C_PT_ON_FACE: t = Constraint::PT_ON_FACE; break;
case SLVS_C_EQUAL_LENGTH_LINES: t = Constraint::EQUAL_LENGTH_LINES; break;
case SLVS_C_LENGTH_RATIO: t = Constraint::LENGTH_RATIO; break;
case SLVS_C_EQ_LEN_PT_LINE_D: t = Constraint::EQ_LEN_PT_LINE_D; break;
case SLVS_C_EQ_PT_LN_DISTANCES: t = Constraint::EQ_PT_LN_DISTANCES; break;
case SLVS_C_EQUAL_ANGLE: t = Constraint::EQUAL_ANGLE; break;
case SLVS_C_EQUAL_LINE_ARC_LEN: t = Constraint::EQUAL_LINE_ARC_LEN; break;
Add a new length-difference constraint. This constraint requires the lengths of two line segments to differ by a constant. It can be useful to define the tolerances when making joints.
2015-10-27 10:28:33 +00:00
case SLVS_C_LENGTH_DIFFERENCE: t = Constraint::LENGTH_DIFFERENCE; break;
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
case SLVS_C_SYMMETRIC: t = Constraint::SYMMETRIC; break;
case SLVS_C_SYMMETRIC_HORIZ: t = Constraint::SYMMETRIC_HORIZ; break;
case SLVS_C_SYMMETRIC_VERT: t = Constraint::SYMMETRIC_VERT; break;
case SLVS_C_SYMMETRIC_LINE: t = Constraint::SYMMETRIC_LINE; break;
case SLVS_C_AT_MIDPOINT: t = Constraint::AT_MIDPOINT; break;
case SLVS_C_HORIZONTAL: t = Constraint::HORIZONTAL; break;
case SLVS_C_VERTICAL: t = Constraint::VERTICAL; break;
case SLVS_C_DIAMETER: t = Constraint::DIAMETER; break;
case SLVS_C_PT_ON_CIRCLE: t = Constraint::PT_ON_CIRCLE; break;
case SLVS_C_SAME_ORIENTATION: t = Constraint::SAME_ORIENTATION; break;
case SLVS_C_ANGLE: t = Constraint::ANGLE; break;
case SLVS_C_PARALLEL: t = Constraint::PARALLEL; break;
case SLVS_C_PERPENDICULAR: t = Constraint::PERPENDICULAR; break;
case SLVS_C_ARC_LINE_TANGENT: t = Constraint::ARC_LINE_TANGENT; break;
case SLVS_C_CUBIC_LINE_TANGENT: t = Constraint::CUBIC_LINE_TANGENT; break;
case SLVS_C_EQUAL_RADIUS: t = Constraint::EQUAL_RADIUS; break;
Add projected point-point distance constraint. [git-p4: depot-paths = "//depot/solvespace/": change = 2115]
2010-01-27 18:15:06 +00:00
case SLVS_C_PROJ_PT_DISTANCE: t = Constraint::PROJ_PT_DISTANCE; break;
Add locked-where-dragged constraint to library interface, and update some copyright dates and bad grammar in comments. [git-p4: depot-paths = "//depot/solvespace/": change = 2137]
2010-05-07 02:13:57 +00:00
case SLVS_C_WHERE_DRAGGED: t = Constraint::WHERE_DRAGGED; break;
Add a constraint for tangency between any combination of arcs and cubics. Also add that to the library interface. It might have been better to use a single constraint for that, plus all the line-curve or line-line cases, but it would break backwards compatibility if I did that now, and perhaps be confusing with the 'other' member (which is meaningless for lines) anyways. [git-p4: depot-paths = "//depot/solvespace/": change = 2141]
2010-05-10 04:14:06 +00:00
case SLVS_C_CURVE_CURVE_TANGENT:t = Constraint::CURVE_CURVE_TANGENT; break;
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
default: dbp("bad constraint type %d", sc->type); return;
}
c.type = t;
c.h.v = sc->h;
c.group.v = sc->group;
c.workplane.v = sc->wrkpl;
c.valA = sc->valA;
c.ptA.v = sc->ptA;
c.ptB.v = sc->ptB;
c.entityA.v = sc->entityA;
c.entityB.v = sc->entityB;
c.entityC.v = sc->entityC;
c.entityD.v = sc->entityD;
c.other = (sc->other) ? true : false;
Add a constraint for tangency between any combination of arcs and cubics. Also add that to the library interface. It might have been better to use a single constraint for that, plus all the line-curve or line-line cases, but it would break backwards compatibility if I did that now, and perhaps be confusing with the 'other' member (which is meaningless for lines) anyways. [git-p4: depot-paths = "//depot/solvespace/": change = 2141]
2010-05-10 04:14:06 +00:00
c.other2 = (sc->other2) ? true : false;
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
SK.constraint.Add(&c);
}
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
for(i = 0; i < (int)arraylen(ssys->dragged); i++) {
Remove arbitrary limits on the selection size, and permit more than one point to be dragged simultaneously. So now a dragged point drags all the selected points and entities, and a dragged entity drags its points (except for circles, which drag the radius). This means that the number of forced points for the solver must now be unlimited, and it is. Also add commands to invert the selection within the active group, and to select an edge chain starting from the current selection. And redo the context menus a bit; still not great, but less cluttered and more systematic. [git-p4: depot-paths = "//depot/solvespace/": change = 2064]
2009-11-03 18:54:49 +00:00
if(ssys->dragged[i]) {
hParam hp = { ssys->dragged[i] };
SYS.dragged.Add(&hp);
}
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
}
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 15:31:23 +00:00
Group g = {};
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
g.h.v = shg;
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 15:31:23 +00:00
List<hConstraint> bad = {};
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
// Now we're finally ready to solve!
Add a solver option to not calculate the failing constraints if we're inconsistent (singular Jacobian). That's slow, so we should provide a library interface to disable it. [git-p4: depot-paths = "//depot/solvespace/": change = 1946]
2009-04-21 07:56:17 +00:00
bool andFindBad = ssys->calculateFaileds ? true : false;
int how = SYS.Solve(&g, &(ssys->dof), &bad, andFindBad, false);
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
switch(how) {
case System::SOLVED_OKAY:
ssys->result = SLVS_RESULT_OKAY;
break;
case System::DIDNT_CONVERGE:
ssys->result = SLVS_RESULT_DIDNT_CONVERGE;
break;
Distinguish overconstrained and redundantly constrained sketches. When a solver error arises after a change to the sketch, it should be easy to understand exactly why it happened. Before this change, two functionally distinct modes of failure were lumped into one: the same "redundant constraints" message was displayed when all degrees of freedom were exhausted and the had a solution, but also when it had not. To understand why this is problematic, let's examine several ways in which we can end up with linearly dependent equations in our system: 0) create a triangle, then constrain two different pairs of edges to be perpendicular 1) add two distinct distance constraints on the same segment 2) add two identical distance constraints on the same segment 3) create a triangle, then constrain edges to lengths a, b, and c so that a+b=c The case (0) is our baseline case: the constraints in it make the system unsolvable yet they do not remove more degrees of freedom than the amount we started with. So the displayed error is "unsolvable constraints". The constraints in case (1) remove one too many degrees of freedom, but otherwise are quite like the case (0): the cause of failure that is useful to the user is that the constraints are mutually incompatible. The constraints in cases (2) and (3) however are not like the others: there is a set of parameters that satisfies all of the constraints, but the constraints still remove one degree of freedom too many. It makes sense to display a different error message for cases (2) and (3) because in practice, cases like this are likely to arise from adjustment of constraint values on sketches corresponding to systems that have a small amount of degenerate solutions, and this is very different from systems arising in cases like (0) where no adjustment of constraint values will ever result in a successful solution. So the error message displayed is "redundant constraints". At last, this commit makes cases (0) and (1) display a message with only a minor difference in wording. This is deliberate. The reason is that the facts "the system is unsolvable" and "the system is unsolvable and also has linearly dependent equations" present no meaningful, actionable difference to the user, and placing emphasis on it would only cause confusion. However, they are still distinguished, because in case (0) we list all relevant constraints (and thus we say they are "mutually incompatible") but in case (1) we only list the ones that constrain the sketch further than some valid solution (and we say they are "unsatisfied").
2016-01-21 09:28:05 +00:00
case System::REDUNDANT_DIDNT_CONVERGE:
case System::REDUNDANT_OKAY:
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
ssys->result = SLVS_RESULT_INCONSISTENT;
break;
case System::TOO_MANY_UNKNOWNS:
ssys->result = SLVS_RESULT_TOO_MANY_UNKNOWNS;
break;
default: oops();
}
// Write the new parameter values back to our caller.
for(i = 0; i < ssys->params; i++) {
Slvs_Param *sp = &(ssys->param[i]);
hParam hp = { sp->h };
sp->val = SK.GetParam(hp)->val;
}
if(ssys->failed) {
// Copy over any the list of problematic constraints.
for(i = 0; i < ssys->faileds && i < bad.n; i++) {
ssys->failed[i] = bad.elem[i].v;
}
ssys->faileds = bad.n;
}
bad.Clear();
SYS.param.Clear();
Oops, forgot to clear out the equations (and the entities, though I don't use them) in the System. [git-p4: depot-paths = "//depot/solvespace/": change = 1949]
2009-04-25 01:27:45 +00:00
SYS.entity.Clear();
SYS.eq.Clear();
Remove arbitrary limits on the selection size, and permit more than one point to be dragged simultaneously. So now a dragged point drags all the selected points and entities, and a dragged entity drags its points (except for circles, which drag the radius). This means that the number of forced points for the solver must now be unlimited, and it is. Also add commands to invert the selection within the active group, and to select an edge chain starting from the current selection. And redo the context menus a bit; still not great, but less cluttered and more systematic. [git-p4: depot-paths = "//depot/solvespace/": change = 2064]
2009-11-03 18:54:49 +00:00
SYS.dragged.Clear();
Oops, forgot to clear out the equations (and the entities, though I don't use them) in the System. [git-p4: depot-paths = "//depot/solvespace/": change = 1949]
2009-04-25 01:27:45 +00:00
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
SK.param.Clear();
SK.entity.Clear();
SK.constraint.Clear();
Oops, fix gross memory leak in SolveSpace library due to failure to destroy temporary heap. [git-p4: depot-paths = "//depot/solvespace/": change = 2210]
2013-03-15 16:43:35 +00:00
FreeAllTemporary();
The constraint solver now compiles as a library, and I have a little test app that links against it. I still need to polish a few things, but this is more or less as it should be. [git-p4: depot-paths = "//depot/solvespace/": change = 1944]
2009-04-20 07:30:09 +00:00
}
Added the exposed/ library and demo program to the Autotools build The libslvs library and CDemo program can now be built by Autotools. A few code changes were needed for this: C++ comments in C code had to be converted, constraint.cpp required some massaging, and fltkutil.cpp needed a stub for InitHeaps().
2013-11-18 07:31:23 +00:00
} /* extern "C" */