caiyu/solvespace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
8aab0160d3
solvespace/src/modify.cpp

669 lines
24 KiB
C++
Raw Normal View History

Changes in preparation for the release of SolveSpace under the GPL, to add that license, and change all copyright notices to me, not Useful Subset, LLC. [git-p4: depot-paths = "//depot/solvespace/": change = 2211]
2013-07-29 06:08:34 +08:00
//-----------------------------------------------------------------------------
// User-initiated (not parametric) operations to modify our sketch, by
// changing the requests, like to round a corner or split curves where they
// intersect.
//
// Copyright 2008-2013 Jonathan Westhues.
//-----------------------------------------------------------------------------
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
#include "solvespace.h"
//-----------------------------------------------------------------------------
Allow removing spline points.
2016-04-07 22:44:56 +08:00
// Replace constraints on oldpt with the same constraints on newpt.
// Useful when splitting, tangent arcing, or removing bezier points.
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
//-----------------------------------------------------------------------------
void GraphicsWindow::ReplacePointInConstraints(hEntity oldpt, hEntity newpt) {
int i;
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
for(i = 0; i < SK.constraint.n; i++) {
Constraint *c = &(SK.constraint.elem[i]);
Allow adding spline points.
2016-04-08 16:20:42 +08:00
if(c->ptA.v == oldpt.v) c->ptA = newpt;
if(c->ptB.v == oldpt.v) c->ptB = newpt;
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
}
Allow removing spline points.
2016-04-07 22:44:56 +08:00
//-----------------------------------------------------------------------------
// Remove constraints on hpt. Useful when removing bezier points.
//-----------------------------------------------------------------------------
void GraphicsWindow::RemoveConstraintsForPointBeingDeleted(hEntity hpt) {
SK.constraint.ClearTags();
for(int i = 0; i < SK.constraint.n; i++) {
Constraint *c = &(SK.constraint.elem[i]);
if(c->ptA.v == hpt.v || c->ptB.v == hpt.v) {
c->tag = 1;
(SS.deleted.constraints)++;
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
if(c->type != Constraint::Type::POINTS_COINCIDENT &&
c->type != Constraint::Type::HORIZONTAL &&
c->type != Constraint::Type::VERTICAL)
Allow removing spline points.
2016-04-07 22:44:56 +08:00
{
(SS.deleted.nonTrivialConstraints)++;
}
}
}
SK.constraint.RemoveTagged();
}
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
//-----------------------------------------------------------------------------
// Let's say that A is coincident with B, and B is coincident with C. This
// implies that A is coincident with C; but if we delete B, then both
// constraints must be deleted too (since they reference B), and A is no
// longer constrained to C. This routine adds back that constraint.
//-----------------------------------------------------------------------------
When deleting a request, rewrite the constraints on its points in such a way as to keep all the points that used to be coincident, still coincident. [git-p4: depot-paths = "//depot/solvespace/": change = 2013]
2009-07-08 17:36:18 +08:00
void GraphicsWindow::FixConstraintsForRequestBeingDeleted(hRequest hr) {
Request *r = SK.GetRequest(hr);
if(r->group.v != SS.GW.activeGroup.v) return;
Entity *e;
for(e = SK.entity.First(); e; e = SK.entity.NextAfter(e)) {
if(!(e->h.isFromRequest())) continue;
if(e->h.request().v != hr.v) continue;
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
if(e->type != Entity::Type::POINT_IN_2D &&
e->type != Entity::Type::POINT_IN_3D)
When deleting a request, rewrite the constraints on its points in such a way as to keep all the points that used to be coincident, still coincident. [git-p4: depot-paths = "//depot/solvespace/": change = 2013]
2009-07-08 17:36:18 +08:00
{
continue;
}
// This is a point generated by the request being deleted; so fix
// the constraints for that.
FixConstraintsForPointBeingDeleted(e->h);
}
}
void GraphicsWindow::FixConstraintsForPointBeingDeleted(hEntity hpt) {
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 23:31:23 +08:00
List<hEntity> ld = {};
When deleting a request, rewrite the constraints on its points in such a way as to keep all the points that used to be coincident, still coincident. [git-p4: depot-paths = "//depot/solvespace/": change = 2013]
2009-07-08 17:36:18 +08:00
Constraint *c;
SK.constraint.ClearTags();
for(c = SK.constraint.First(); c; c = SK.constraint.NextAfter(c)) {
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
if(c->type != Constraint::Type::POINTS_COINCIDENT) continue;
When deleting a request, rewrite the constraints on its points in such a way as to keep all the points that used to be coincident, still coincident. [git-p4: depot-paths = "//depot/solvespace/": change = 2013]
2009-07-08 17:36:18 +08:00
if(c->group.v != SS.GW.activeGroup.v) continue;
if(c->ptA.v == hpt.v) {
ld.Add(&(c->ptB));
c->tag = 1;
}
if(c->ptB.v == hpt.v) {
ld.Add(&(c->ptA));
c->tag = 1;
}
}
Allow removing spline points.
2016-04-07 22:44:56 +08:00
// Remove constraints without waiting for regeneration; this way
// if another point takes the place of the deleted one (e.g. when
// removing control points of a bezier) the constraint doesn't
// spuriously move. Similarly, subsequent calls of this function
// (if multiple coincident points are getting deleted) will work
// correctly.
When deleting a request, rewrite the constraints on its points in such a way as to keep all the points that used to be coincident, still coincident. [git-p4: depot-paths = "//depot/solvespace/": change = 2013]
2009-07-08 17:36:18 +08:00
SK.constraint.RemoveTagged();
// If more than one point was constrained coincident with hpt, then
// those two points were implicitly coincident with each other. By
// deleting hpt (and all constraints that mention it), we will delete
// that relationship. So put it back here now.
int i;
for(i = 1; i < ld.n; i++) {
Constraint::ConstrainCoincident(ld.elem[i-1], ld.elem[i]);
}
ld.Clear();
}
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
//-----------------------------------------------------------------------------
// A curve by its parametric equation, helper functions for computing tangent
// arcs by a numerical method.
//-----------------------------------------------------------------------------
void GraphicsWindow::ParametricCurve::MakeFromEntity(hEntity he, bool reverse) {
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 23:31:23 +08:00
*this = {};
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
Entity *e = SK.GetEntity(he);
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
if(e->type == Entity::Type::LINE_SEGMENT) {
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
isLine = true;
p0 = e->EndpointStart(),
p1 = e->EndpointFinish();
if(reverse) {
Use C++ std::{min,max,swap} instead of custom ones. The main benefit is that std::swap will ensure that the type of arguments is copy-constructible and move-constructible. It is more concise as well. When min and max are defined as macros, they will conflict with STL header files included by other C++ libraries; in this case STL will #undef any other definition.
2015-03-27 23:43:28 +08:00
swap(p0, p1);
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
}
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
} else if(e->type == Entity::Type::ARC_OF_CIRCLE) {
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
isLine = false;
p0 = SK.GetEntity(e->point[0])->PointGetNum();
Vector pe = SK.GetEntity(e->point[1])->PointGetNum();
r = (pe.Minus(p0)).Magnitude();
e->ArcGetAngles(&theta0, &theta1, &dtheta);
if(reverse) {
Use C++ std::{min,max,swap} instead of custom ones. The main benefit is that std::swap will ensure that the type of arguments is copy-constructible and move-constructible. It is more concise as well. When min and max are defined as macros, they will conflict with STL header files included by other C++ libraries; in this case STL will #undef any other definition.
2015-03-27 23:43:28 +08:00
swap(theta0, theta1);
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
dtheta = -dtheta;
}
EntityBase *wrkpln = SK.GetEntity(e->workplane)->Normal();
u = wrkpln->NormalU();
v = wrkpln->NormalV();
Replace all oops() checks with ssassert()s. This includes explanation and context for non-obvious cases and shortens debug cycles when just-in-time debugging is not available (like on Linux) by immediately printing description of the assert as well as symbolized backtrace.
2016-05-19 06:51:36 +08:00
} else ssassert(false, "Unexpected entity type");
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
}
Rewrite declarations of form f(void) as f(). In C++ there is no difference and newly added functions are all declared as f(), so this brings back consistency.
2016-05-05 13:54:05 +08:00
double GraphicsWindow::ParametricCurve::LengthForAuto() {
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
if(isLine) {
// Allow a third of the line to disappear with auto radius
return (p1.Minus(p0)).Magnitude() / 3;
} else {
// But only a twentieth of the arc; shorter means fewer numerical
// problems since the curve is more linear over shorter sections.
return (fabs(dtheta)*r)/20;
}
}
Vector GraphicsWindow::ParametricCurve::PointAt(double t) {
if(isLine) {
return p0.Plus((p1.Minus(p0)).ScaledBy(t));
} else {
double theta = theta0 + dtheta*t;
return p0.Plus(u.ScaledBy(r*cos(theta)).Plus(v.ScaledBy(r*sin(theta))));
}
}
Vector GraphicsWindow::ParametricCurve::TangentAt(double t) {
if(isLine) {
return p1.Minus(p0);
} else {
double theta = theta0 + dtheta*t;
Vector t = u.ScaledBy(-r*sin(theta)).Plus(v.ScaledBy(r*cos(theta)));
t = t.ScaledBy(dtheta);
return t;
}
}
hRequest GraphicsWindow::ParametricCurve::CreateRequestTrimmedTo(double t,
bool extraConstraints, hEntity orig, hEntity arc, bool arcFinish)
{
hRequest hr;
Entity *e;
if(isLine) {
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hr = SS.GW.AddRequest(Request::Type::LINE_SEGMENT, false),
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
e = SK.GetEntity(hr.entity(0));
SK.GetEntity(e->point[0])->PointForceTo(PointAt(t));
SK.GetEntity(e->point[1])->PointForceTo(PointAt(1));
ConstrainPointIfCoincident(e->point[0]);
ConstrainPointIfCoincident(e->point[1]);
if(extraConstraints) {
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
Constraint::Constrain(Constraint::Type::PT_ON_LINE,
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
hr.entity(1), Entity::NO_ENTITY, orig);
}
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
Constraint::Constrain(Constraint::Type::ARC_LINE_TANGENT,
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
Entity::NO_ENTITY, Entity::NO_ENTITY,
arc, e->h, arcFinish, false);
} else {
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hr = SS.GW.AddRequest(Request::Type::ARC_OF_CIRCLE, false),
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
e = SK.GetEntity(hr.entity(0));
SK.GetEntity(e->point[0])->PointForceTo(p0);
if(dtheta > 0) {
SK.GetEntity(e->point[1])->PointForceTo(PointAt(t));
SK.GetEntity(e->point[2])->PointForceTo(PointAt(1));
} else {
SK.GetEntity(e->point[2])->PointForceTo(PointAt(t));
SK.GetEntity(e->point[1])->PointForceTo(PointAt(1));
}
ConstrainPointIfCoincident(e->point[0]);
ConstrainPointIfCoincident(e->point[1]);
ConstrainPointIfCoincident(e->point[2]);
// The tangency constraint alone is enough to fully constrain it,
// so there's no need for more.
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
Constraint::Constrain(Constraint::Type::CURVE_CURVE_TANGENT,
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
Entity::NO_ENTITY, Entity::NO_ENTITY,
arc, e->h, arcFinish, (dtheta < 0));
}
return hr;
}
//-----------------------------------------------------------------------------
// If a point in the same group as hpt, and numerically coincident with hpt,
// happens to exist, then constrain that point coincident to hpt.
//-----------------------------------------------------------------------------
void GraphicsWindow::ParametricCurve::ConstrainPointIfCoincident(hEntity hpt) {
Entity *e, *pt;
pt = SK.GetEntity(hpt);
Vector ev, ptv;
ptv = pt->PointGetNum();
for(e = SK.entity.First(); e; e = SK.entity.NextAfter(e)) {
if(e->h.v == pt->h.v) continue;
if(!e->IsPoint()) continue;
if(e->group.v != pt->group.v) continue;
if(e->workplane.v != pt->workplane.v) continue;
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
ev = e->PointGetNum();
if(!ev.Equals(ptv)) continue;
Constraint::ConstrainCoincident(hpt, e->h);
break;
}
}
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
//-----------------------------------------------------------------------------
// A single point must be selected when this function is called. We find two
// non-construction line segments that join at this point, and create a
// tangent arc joining them.
//-----------------------------------------------------------------------------
Rewrite declarations of form f(void) as f(). In C++ there is no difference and newly added functions are all declared as f(), so this brings back consistency.
2016-05-05 13:54:05 +08:00
void GraphicsWindow::MakeTangentArc() {
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
if(!LockedInWorkplane()) {
Error("Must be sketching in workplane to create tangent "
"arc.");
return;
}
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// The point corresponding to the vertex to be rounded.
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Vector pshared = SK.GetEntity(gs.point[0])->PointGetNum();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
ClearSelection();
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// First, find two requests (that are not construction, and that are
// in our group and workplane) that generate entities that have an
// endpoint at our vertex to be rounded.
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
int i, c = 0;
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
Entity *ent[2];
Request *req[2];
hRequest hreq[2];
hEntity hent[2];
bool pointf[2];
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
for(i = 0; i < SK.request.n; i++) {
Request *r = &(SK.request.elem[i]);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
if(r->group.v != activeGroup.v) continue;
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
if(r->workplane.v != ActiveWorkplane().v) continue;
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
if(r->construction) continue;
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
if(r->type != Request::Type::LINE_SEGMENT &&
r->type != Request::Type::ARC_OF_CIRCLE)
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
{
continue;
}
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Entity *e = SK.GetEntity(r->h.entity(0));
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
Vector ps = e->EndpointStart(),
pf = e->EndpointFinish();
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
if(ps.Equals(pshared) || pf.Equals(pshared)) {
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
if(c < 2) {
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// We record the entity and request and their handles,
// and whether the vertex to be rounded is the start or
// finish of this entity.
ent[c] = e;
hent[c] = e->h;
req[c] = r;
hreq[c] = r->h;
pointf[c] = (pf.Equals(pshared));
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
c++;
}
}
if(c != 2) {
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
Error("To create a tangent arc, select a point where two "
"non-construction lines or cicles in this group and "
"workplane join.");
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
return;
}
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Entity *wrkpl = SK.GetEntity(ActiveWorkplane());
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Vector wn = wrkpl->Normal()->NormalN();
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// Based on these two entities, we make the objects that we'll use to
// numerically find the tangent arc.
ParametricCurve pc[2];
pc[0].MakeFromEntity(ent[0]->h, pointf[0]);
pc[1].MakeFromEntity(ent[1]->h, pointf[1]);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// And thereafter we mustn't touch the entity or req ptrs,
// because the new requests/entities we add might force a
// realloc.
memset(ent, 0, sizeof(ent));
memset(req, 0, sizeof(req));
Vector pinter;
Quash "variable may be used uninitialized" warnings Whether or not there is any actual danger of these variables being used without initialization, the warnings are noise, and getting rid of them is trivial.
2013-08-27 03:36:00 +08:00
double r = 0.0, vv = 0.0;
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// We now do Newton iterations to find the tangent arc, and its positions
// t back along the two curves, starting from shared point of the curves
// at t = 0. Lots of iterations helps convergence, and this is still
// ~10 ms for everything.
int iters = 1000;
double t[2] = { 0, 0 }, tp[2];
for(i = 0; i < iters + 20; i++) {
Vector p0 = pc[0].PointAt(t[0]),
p1 = pc[1].PointAt(t[1]),
t0 = pc[0].TangentAt(t[0]),
t1 = pc[1].TangentAt(t[1]);
pinter = Vector::AtIntersectionOfLines(p0, p0.Plus(t0),
p1, p1.Plus(t1),
NULL, NULL, NULL);
// The sign of vv determines whether shortest distance is
// clockwise or anti-clockwise.
Vector v = (wn.Cross(t0)).WithMagnitude(1);
vv = t1.Dot(v);
double dot = (t0.WithMagnitude(1)).Dot(t1.WithMagnitude(1));
double theta = acos(dot);
if(SS.tangentArcManual) {
r = SS.tangentArcRadius;
} else {
r = 200/scale;
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
// Set the radius so that no more than one third of the
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// line segment disappears.
r = min(r, pc[0].LengthForAuto()*tan(theta/2));
r = min(r, pc[1].LengthForAuto()*tan(theta/2));;
}
// We are source-stepping the radius, to improve convergence. So
// ramp that for most of the iterations, and then do a few at
// the end with that constant for polishing.
if(i < iters) {
r *= 0.1 + 0.9*i/((double)iters);
}
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// The distance from the intersection of the lines to the endpoint
// of the arc, along each line.
double el = r/tan(theta/2);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// Compute the endpoints of the arc, for each curve
Vector pa0 = pinter.Plus(t0.WithMagnitude(el)),
pa1 = pinter.Plus(t1.WithMagnitude(el));
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
tp[0] = t[0];
tp[1] = t[1];
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
// And convert those points to parameter values along the curve.
t[0] += (pa0.Minus(p0)).DivPivoting(t0);
t[1] += (pa1.Minus(p1)).DivPivoting(t1);
}
// Stupid check for convergence, and for an out of range result (as
// we would get, for example, if the line is too short to fit the
// rounding arc).
if(fabs(tp[0] - t[0]) > 1e-3 || fabs(tp[1] - t[1]) > 1e-3 ||
t[0] < 0.01 || t[1] < 0.01 ||
t[0] > 0.99 || t[1] > 0.99 ||
isnan(t[0]) || isnan(t[1]))
{
Error("Couldn't round this corner. Try a smaller radius, or try "
"creating the desired geometry by hand with tangency "
"constraints.");
return;
}
// Compute the location of the center of the arc
Vector center = pc[0].PointAt(t[0]),
v0inter = pinter.Minus(center);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
int a, b;
if(vv < 0) {
a = 1; b = 2;
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
center = center.Minus(v0inter.Cross(wn).WithMagnitude(r));
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
} else {
a = 2; b = 1;
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
center = center.Plus(v0inter.Cross(wn).WithMagnitude(r));
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
SS.UndoRemember();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hRequest harc = AddRequest(Request::Type::ARC_OF_CIRCLE, false);
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
Entity *earc = SK.GetEntity(harc.entity(0));
hEntity hearc = earc->h;
SK.GetEntity(earc->point[0])->PointForceTo(center);
SK.GetEntity(earc->point[a])->PointForceTo(pc[0].PointAt(t[0]));
SK.GetEntity(earc->point[b])->PointForceTo(pc[1].PointAt(t[1]));
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Improve the non-parametric rounding. It now works on both lines and circles, using a numerical method. And the user can specify a radius, instead of letting us choose automatically, and specify whether the original lines should be kept and made construction, or deleted. [git-p4: depot-paths = "//depot/solvespace/": change = 2146]
2010-05-17 00:36:23 +08:00
earc = NULL;
pc[0].CreateRequestTrimmedTo(t[0], !SS.tangentArcDeleteOld,
hent[0], hearc, (b == 1));
pc[1].CreateRequestTrimmedTo(t[1], !SS.tangentArcDeleteOld,
hent[1], hearc, (a == 1));
// Now either make the original entities construction, or delete them
// entirely, according to user preference.
Request *re;
SK.request.ClearTags();
for(re = SK.request.First(); re; re = SK.request.NextAfter(re)) {
if(re->h.v == hreq[0].v || re->h.v == hreq[1].v) {
if(SS.tangentArcDeleteOld) {
re->tag = 1;
} else {
re->construction = true;
}
}
}
if(SS.tangentArcDeleteOld) {
DeleteTaggedRequests();
}
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Add a GTK2/3 port. In principle, GTK3 is the way forward, and GTK2 is officially deprecated, though still maintained. In practice however, GTK3 is often unbearably buggy; e.g. on my system, combo boxes don't ever roll up in GTK3 windows. So I have added support for both. This required a few minor changes to the core, namely: * GTK wants to know beforehand whether a menu item is a check menu item or a regular one. * GTK doesn't give us an easy way to execute something after any event is processed, so an explicit idle timer is added. This is a no-op on Win32. * A few function signatures were const'ed, since GTK expects immutable strings when converting to Glib::ustring.
2015-03-19 01:02:11 +08:00
SS.ScheduleGenerateAll();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
hEntity GraphicsWindow::SplitLine(hEntity he, Vector pinter) {
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
// Save the original endpoints, since we're about to delete this entity.
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Entity *e01 = SK.GetEntity(he);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
hEntity hep0 = e01->point[0], hep1 = e01->point[1];
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Vector p0 = SK.GetEntity(hep0)->PointGetNum(),
p1 = SK.GetEntity(hep1)->PointGetNum();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
// Add the two line segments this one gets split into.
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hRequest r0i = AddRequest(Request::Type::LINE_SEGMENT, false),
ri1 = AddRequest(Request::Type::LINE_SEGMENT, false);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
// Don't get entities till after adding, realloc issues
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Entity *e0i = SK.GetEntity(r0i.entity(0)),
*ei1 = SK.GetEntity(ri1.entity(0));
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
SK.GetEntity(e0i->point[0])->PointForceTo(p0);
SK.GetEntity(e0i->point[1])->PointForceTo(pinter);
SK.GetEntity(ei1->point[0])->PointForceTo(pinter);
SK.GetEntity(ei1->point[1])->PointForceTo(p1);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
ReplacePointInConstraints(hep0, e0i->point[0]);
ReplacePointInConstraints(hep1, ei1->point[1]);
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Constraint::ConstrainCoincident(e0i->point[1], ei1->point[0]);
return e0i->point[1];
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
hEntity GraphicsWindow::SplitCircle(hEntity he, Vector pinter) {
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Entity *circle = SK.GetEntity(he);
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
if(circle->type == Entity::Type::CIRCLE) {
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
// Start with an unbroken circle, split it into a 360 degree arc.
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Vector center = SK.GetEntity(circle->point[0])->PointGetNum();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
circle = NULL; // shortly invalid!
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hRequest hr = AddRequest(Request::Type::ARC_OF_CIRCLE, false);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Entity *arc = SK.GetEntity(hr.entity(0));
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
SK.GetEntity(arc->point[0])->PointForceTo(center);
SK.GetEntity(arc->point[1])->PointForceTo(pinter);
SK.GetEntity(arc->point[2])->PointForceTo(pinter);
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Constraint::ConstrainCoincident(arc->point[1], arc->point[2]);
return arc->point[1];
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
} else {
// Start with an arc, break it in to two arcs
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
hEntity hc = circle->point[0],
hs = circle->point[1],
hf = circle->point[2];
Vector center = SK.GetEntity(hc)->PointGetNum(),
start = SK.GetEntity(hs)->PointGetNum(),
finish = SK.GetEntity(hf)->PointGetNum();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
circle = NULL; // shortly invalid!
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hRequest hr0 = AddRequest(Request::Type::ARC_OF_CIRCLE, false),
hr1 = AddRequest(Request::Type::ARC_OF_CIRCLE, false);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Entity *arc0 = SK.GetEntity(hr0.entity(0)),
*arc1 = SK.GetEntity(hr1.entity(0));
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
SK.GetEntity(arc0->point[0])->PointForceTo(center);
SK.GetEntity(arc0->point[1])->PointForceTo(start);
SK.GetEntity(arc0->point[2])->PointForceTo(pinter);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
SK.GetEntity(arc1->point[0])->PointForceTo(center);
SK.GetEntity(arc1->point[1])->PointForceTo(pinter);
SK.GetEntity(arc1->point[2])->PointForceTo(finish);
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
ReplacePointInConstraints(hs, arc0->point[1]);
ReplacePointInConstraints(hf, arc1->point[2]);
Constraint::ConstrainCoincident(arc0->point[2], arc1->point[1]);
return arc0->point[2];
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
}
hEntity GraphicsWindow::SplitCubic(hEntity he, Vector pinter) {
// Save the original endpoints, since we're about to delete this entity.
Entity *e01 = SK.GetEntity(he);
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 23:31:23 +08:00
SBezierList sbl = {};
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
e01->GenerateBezierCurves(&sbl);
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
hEntity hep0 = e01->point[0],
hep1 = e01->point[3+e01->extraPoints],
hep0n = Entity::NO_ENTITY, // the new start point
hep1n = Entity::NO_ENTITY, // the new finish point
hepin = Entity::NO_ENTITY; // the intersection point
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
// The curve may consist of multiple cubic segments. So find which one
// contains the intersection point.
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
double t;
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
int i, j;
for(i = 0; i < sbl.l.n; i++) {
SBezier *sb = &(sbl.l.elem[i]);
Replace all oops() checks with ssassert()s. This includes explanation and context for non-obvious cases and shortens debug cycles when just-in-time debugging is not available (like on Linux) by immediately printing description of the assert as well as symbolized backtrace.
2016-05-19 06:51:36 +08:00
ssassert(sb->deg == 3, "Expected a cubic bezier");
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
sb->ClosestPointTo(pinter, &t, false);
if(pinter.Equals(sb->PointAt(t))) {
// Split that segment at the intersection.
SBezier b0i, bi1, b01 = *sb;
b01.SplitAt(t, &b0i, &bi1);
// Add the two cubic segments this one gets split into.
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hRequest r0i = AddRequest(Request::Type::CUBIC, false),
ri1 = AddRequest(Request::Type::CUBIC, false);
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
// Don't get entities till after adding, realloc issues
Entity *e0i = SK.GetEntity(r0i.entity(0)),
*ei1 = SK.GetEntity(ri1.entity(0));
for(j = 0; j <= 3; j++) {
SK.GetEntity(e0i->point[j])->PointForceTo(b0i.ctrl[j]);
}
for(j = 0; j <= 3; j++) {
SK.GetEntity(ei1->point[j])->PointForceTo(bi1.ctrl[j]);
}
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
Constraint::ConstrainCoincident(e0i->point[3], ei1->point[0]);
if(i == 0) hep0n = e0i->point[0];
hep1n = ei1->point[3];
hepin = e0i->point[3];
} else {
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
hRequest r = AddRequest(Request::Type::CUBIC, false);
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
Entity *e = SK.GetEntity(r.entity(0));
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
for(j = 0; j <= 3; j++) {
SK.GetEntity(e->point[j])->PointForceTo(sb->ctrl[j]);
}
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
if(i == 0) hep0n = e->point[0];
hep1n = e->point[3];
}
}
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
sbl.Clear();
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
ReplacePointInConstraints(hep0, hep0n);
ReplacePointInConstraints(hep1, hep1n);
return hepin;
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
}
hEntity GraphicsWindow::SplitEntity(hEntity he, Vector pinter) {
Entity *e = SK.GetEntity(he);
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
Entity::Type entityType = e->type;
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
hEntity ret;
if(e->IsCircle()) {
ret = SplitCircle(he, pinter);
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
} else if(e->type == Entity::Type::LINE_SEGMENT) {
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
ret = SplitLine(he, pinter);
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
} else if(e->type == Entity::Type::CUBIC || e->type == Entity::Type::CUBIC_PERIODIC) {
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
ret = SplitCubic(he, pinter);
} else {
Error("Couldn't split this entity; lines, circles, or cubics only.");
return Entity::NO_ENTITY;
}
// Finally, delete the request that generated the original entity.
Convert all enumerations to use `enum class`. Specifically, take the old code that looks like this: class Foo { enum { X = 1, Y = 2 }; int kind; } ... foo.kind = Foo::X; ... and convert it to this: class Foo { enum class Kind : uint32_t { X = 1, Y = 2 }; Kind kind; } ... foo.kind = Foo::Kind::X; (In some cases the enumeration would not be in the class namespace, such as when it is generally useful.) The benefits are as follows: * The type of the field gives a clear indication of intent, both to humans and tools (such as binding generators). * The compiler is able to automatically warn when a switch is not exhaustive; but this is currently suppressed by the default: ssassert(false, ...) idiom. * Integers and plain enums are weakly type checked: they implicitly convert into each other. This can hide bugs where type conversion is performed but not intended. Enum classes are strongly type checked. * Plain enums pollute parent namespaces; enum classes do not. Almost every defined enum we have already has a kind of ad-hoc namespacing via `NAMESPACE_`, which is now explicit. * Plain enums do not have a well-defined ABI size, which is important for bindings. Enum classes can have it, if specified. We specify the base type for all enums as uint32_t, which is a safe choice and allows us to not change the numeric values of any variants. This commit introduces absolutely no functional change to the code, just renaming and change of types. It handles almost all cases, except GraphicsWindow::pending.operation, which needs minor functional change.
2016-05-20 16:31:20 +08:00
Request::Type reqType = EntReqTable::GetRequestForEntity(entityType);
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
SK.request.ClearTags();
Put information about which requests generate which entities, and how many points are associated with each, into a single table. [git-p4: depot-paths = "//depot/solvespace/": change = 2056]
2009-10-22 22:02:08 +08:00
for(int i = 0; i < SK.request.n; i++) {
A monster change; move the parameter, entity, group, and constraint tables from SolveSpace to their own class. This is intended to simplify use of the constraint solver in a library. [git-p4: depot-paths = "//depot/solvespace/": change = 1942]
2009-04-19 13:53:16 +08:00
Request *r = &(SK.request.elem[i]);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
if(r->group.v != activeGroup.v) continue;
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
if(r->type != reqType) continue;
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
// If the user wants to keep the old entities around, they can just
// mark them construction first.
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
if(he.v == r->h.entity(0).v && !r->construction) {
r->tag = 1;
break;
}
}
DeleteTaggedRequests();
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
return ret;
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
Rewrite declarations of form f(void) as f(). In C++ there is no difference and newly added functions are all declared as f(), so this brings back consistency.
2016-05-05 13:54:05 +08:00
void GraphicsWindow::SplitLinesOrCurves() {
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
if(!LockedInWorkplane()) {
Error("Must be sketching in workplane to split.");
return;
}
GroupSelection();
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
if(!(gs.n == 2 &&(gs.lineSegments +
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
gs.circlesOrArcs +
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
gs.cubics +
gs.periodicCubics) == 2))
{
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Error("Select two entities that intersect each other (e.g. two lines "
"or two circles or a circle and a line).");
return;
}
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
hEntity ha = gs.entity[0],
hb = gs.entity[1];
Entity *ea = SK.GetEntity(ha),
*eb = SK.GetEntity(hb);
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
// Compute the possibly-rational Bezier curves for each of these entities
SBezierList sbla, sblb;
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 23:31:23 +08:00
sbla = {};
sblb = {};
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
ea->GenerateBezierCurves(&sbla);
eb->GenerateBezierCurves(&sblb);
// and then compute the points where they intersect, based on those curves.
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 23:31:23 +08:00
SPointList inters = {};
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
sbla.AllIntersectionsWith(&sblb, &inters);
if(inters.l.n > 0) {
Quash "variable may be used uninitialized" warnings Whether or not there is any actual danger of these variables being used without initialization, the warnings are noise, and getting rid of them is trivial.
2013-08-27 03:36:00 +08:00
Vector pi = Vector::From(0, 0, 0);
When curves to be split intersect at multiple points, don't just choose arbitrarily. Instead, split at the point closest to the mouse pointer. [git-p4: depot-paths = "//depot/solvespace/": change = 2170]
2010-07-12 14:47:14 +08:00
// If there's multiple points, then take the one closest to the
// mouse pointer.
double dmin = VERY_POSITIVE;
SPoint *sp;
for(sp = inters.l.First(); sp; sp = inters.l.NextAfter(sp)) {
double d = ProjectPoint(sp->p).DistanceTo(currentMousePosition);
if(d < dmin) {
dmin = d;
pi = sp->p;
}
}
Split cubic splines and periodic splines too; which is a pain, because it can't be C2 continuous after splitting (since I'm doing uniform splines only, and the parametrization changes). So just knock everything down to cubic Beziers. Also draw lines to indicate angle and origin when Ctrl+dragging to rotate in plane of screen. [git-p4: depot-paths = "//depot/solvespace/": change = 2075]
2009-11-10 11:57:24 +08:00
SS.UndoRemember();
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
hEntity hia = SplitEntity(ha, pi),
hib = SplitEntity(hb, pi);
// SplitEntity adds the coincident constraints to join the split halves
// of each original entity; and then we add the constraint to join
// the two entities together at the split point.
if(hia.v && hib.v) {
Constraint::ConstrainCoincident(hia, hib);
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
} else {
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
Error("Can't split; no intersection found.");
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
Replace the closed-form solutions for entity-entity splitting with a method that works on the piecewise linear segments, and then refines any intersections that it finds by Newton's method. So now I support cubics too, and circle-circle intersections, and the code is much simpler. [git-p4: depot-paths = "//depot/solvespace/": change = 2012]
2009-07-07 16:21:59 +08:00
// All done, clean up and regenerate.
inters.Clear();
sbla.Clear();
sblb.Clear();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
ClearSelection();
Add a GTK2/3 port. In principle, GTK3 is the way forward, and GTK2 is officially deprecated, though still maintained. In practice however, GTK3 is often unbearably buggy; e.g. on my system, combo boxes don't ever roll up in GTK3 windows. So I have added support for both. This required a few minor changes to the core, namely: * GTK wants to know beforehand whether a menu item is a check menu item or a regular one. * GTK doesn't give us an easy way to execute something after any event is processed, so an explicit idle timer is added. This is a no-op on Win32. * A few function signatures were const'ed, since GTK expects immutable strings when converting to Glib::ustring.
2015-03-19 01:02:11 +08:00
SS.ScheduleGenerateAll();
Add a trim command. I can now do circles (or arcs) against lines, or lines against lines. The constraints get rather screwed up afterwards, of course. So make arcs with the endpoints coincident into circles, instead of nothings; since the first split of a circle produces that. And don't warn after deleting just point-coincident or horiz/vert constraints as a dependency; that's just a nuisance, because it happens too often. [git-p4: depot-paths = "//depot/solvespace/": change = 1884]
2009-01-03 20:27:33 +08:00
}
Reference in New Issue Copy Permalink