caiyu/solvespace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
89da072427
solvespace/src/srf/surfinter.cpp

527 lines
19 KiB
C++
Raw Normal View History

Split line-surface intersection and shell raycasting stuff into its own file. [git-p4: depot-paths = "//depot/solvespace/": change = 1992]
2009-06-21 17:14:49 +08:00
//-----------------------------------------------------------------------------
// How to intersect two surfaces, to get some type of curve. This is either
// an exact special case (e.g., two planes to make a line), or a numerical
// thing.
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
//
// Copyright 2008-2013 Jonathan Westhues.
Split line-surface intersection and shell raycasting stuff into its own file. [git-p4: depot-paths = "//depot/solvespace/": change = 1992]
2009-06-21 17:14:49 +08:00
//-----------------------------------------------------------------------------
More poking at Booleans; generate the unsplit intersection curves for planes against planes. [git-p4: depot-paths = "//depot/solvespace/": change = 1907]
2009-01-27 15:59:58 +08:00
#include "solvespace.h"
Add Newton iterations to intersect a line with a surface at a point, and to intersect three surfaces at a point. So now when we split an edge, we can refine the split point to lie exactly on the trim curve, so I can do certain Booleans on curved surfaces. But surface-line intersection is globally broken, since I don't correctly detect the number of intersections or provide a good first guess. I maybe should test by bounding boxes and subdivision. [git-p4: depot-paths = "//depot/solvespace/": change = 1920]
2009-02-27 21:04:36 +08:00
extern int FLAG;
void SSurface::AddExactIntersectionCurve(SBezier *sb, SSurface *srfB,
Add const qualifiers to functions where trivially possible. This will allow us in future to accept `const T &` anywhere it's necessary to reduce the amount of copying. This commit is quite conservative: it does not attempt very hard to refactor code that performs incidental mutation. In particular dogd and caches are not marked with the `mutable` keyword. dogd will be eliminated later, opening up more opportunities to add const qualifiers. This commit also doesn't introduce any uses of the newly added const qualifers. This will be done later.
2016-05-21 13:18:00 +08:00
SShell *agnstA, SShell *agnstB, SShell *into)
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
{
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 23:31:23 +08:00
SCurve sc = {};
Many changes: * Rewrite surface handles in curves, so that Booleans beyond the first don't screw up. * If an intersection curve is identical to an existing curve (as happens when faces are coincident), take the piecewise linearization of the existing curve; this stops us from screwing up when different shells are pwl'd at different chord tols. * Hook up the plane faces again. * Remove coincident (parallel or anti-parallel) edges from the coincident-face edge lists when doing Booleans; those may happen if two faces are coincident with ours. * Miscellaneous bugfixes. It doesn't seem to screw up very much now, although tangent edges (and insufficient pwl resolution) may still cause problems. [git-p4: depot-paths = "//depot/solvespace/": change = 1929]
2009-03-16 07:04:45 +08:00
// Important to keep the order of (surfA, surfB) consistent; when we later
// rewrite the identifiers, we rewrite surfA from A and surfB from B.
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
sc.surfA = h;
Add Newton iterations to intersect a line with a surface at a point, and to intersect three surfaces at a point. So now when we split an edge, we can refine the split point to lie exactly on the trim curve, so I can do certain Booleans on curved surfaces. But surface-line intersection is globally broken, since I don't correctly detect the number of intersections or provide a good first guess. I maybe should test by bounding boxes and subdivision. [git-p4: depot-paths = "//depot/solvespace/": change = 1920]
2009-02-27 21:04:36 +08:00
sc.surfB = srfB->h;
Many changes: * Rewrite surface handles in curves, so that Booleans beyond the first don't screw up. * If an intersection curve is identical to an existing curve (as happens when faces are coincident), take the piecewise linearization of the existing curve; this stops us from screwing up when different shells are pwl'd at different chord tols. * Hook up the plane faces again. * Remove coincident (parallel or anti-parallel) edges from the coincident-face edge lists when doing Booleans; those may happen if two faces are coincident with ours. * Miscellaneous bugfixes. It doesn't seem to screw up very much now, although tangent edges (and insufficient pwl resolution) may still cause problems. [git-p4: depot-paths = "//depot/solvespace/": change = 1929]
2009-03-16 07:04:45 +08:00
sc.exact = *sb;
sc.isExact = true;
// Now we have to piecewise linearize the curve. If there's already an
// identical curve in the shell, then follow that pwl exactly, otherwise
// calculate from scratch.
SCurve split, *existing = NULL, *se;
SBezier sbrev = *sb;
sbrev.Reverse();
bool backwards = false;
for(se = into->curve.First(); se; se = into->curve.NextAfter(se)) {
if(se->isExact) {
if(sb->Equals(&(se->exact))) {
existing = se;
break;
}
if(sbrev.Equals(&(se->exact))) {
existing = se;
backwards = true;
break;
}
}
}
if(existing) {
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
SCurvePt *v;
Many changes: * Rewrite surface handles in curves, so that Booleans beyond the first don't screw up. * If an intersection curve is identical to an existing curve (as happens when faces are coincident), take the piecewise linearization of the existing curve; this stops us from screwing up when different shells are pwl'd at different chord tols. * Hook up the plane faces again. * Remove coincident (parallel or anti-parallel) edges from the coincident-face edge lists when doing Booleans; those may happen if two faces are coincident with ours. * Miscellaneous bugfixes. It doesn't seem to screw up very much now, although tangent edges (and insufficient pwl resolution) may still cause problems. [git-p4: depot-paths = "//depot/solvespace/": change = 1929]
2009-03-16 07:04:45 +08:00
for(v = existing->pts.First(); v; v = existing->pts.NextAfter(v)) {
sc.pts.Add(v);
}
if(backwards) sc.pts.Reverse();
split = sc;
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
sc = {};
Many changes: * Rewrite surface handles in curves, so that Booleans beyond the first don't screw up. * If an intersection curve is identical to an existing curve (as happens when faces are coincident), take the piecewise linearization of the existing curve; this stops us from screwing up when different shells are pwl'd at different chord tols. * Hook up the plane faces again. * Remove coincident (parallel or anti-parallel) edges from the coincident-face edge lists when doing Booleans; those may happen if two faces are coincident with ours. * Miscellaneous bugfixes. It doesn't seem to screw up very much now, although tangent edges (and insufficient pwl resolution) may still cause problems. [git-p4: depot-paths = "//depot/solvespace/": change = 1929]
2009-03-16 07:04:45 +08:00
} else {
sb->MakePwlInto(&(sc.pts));
// and split the line where it intersects our existing surfaces
split = sc.MakeCopySplitAgainst(agnstA, agnstB, this, srfB);
sc.Clear();
}
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
// Test if the curve lies entirely outside one of the
Discard intersection curves that lie entirely outside of one surface's domain of u, v in [0, 1]. Cache the starting guess when projecting a point into a ratpoly surface, to avoid brute force searching for a good one every time. Split edges even if they aren't quite inside the trim curve, since the trim boundaries are pwl, not exact; unnecessary splits won't hurt, but failure to split when necessary will. Make the triangulation code use a better (but not perfect) epsilon, to avoid "can't find ear" failures on very fine meshes. And turn on compiler optimization! I had somehow forgotten about that, and it's a ~2x improvement. [git-p4: depot-paths = "//depot/solvespace/": change = 2026]
2009-08-21 12:58:28 +08:00
SCurvePt *scpt;
bool withinA = false, withinB = false;
for(scpt = split.pts.First(); scpt; scpt = split.pts.NextAfter(scpt)) {
double tol = 0.01;
Point2d puv;
ClosestPointTo(scpt->p, &puv);
if(puv.x > -tol && puv.x < 1 + tol &&
puv.y > -tol && puv.y < 1 + tol)
{
withinA = true;
}
srfB->ClosestPointTo(scpt->p, &puv);
if(puv.x > -tol && puv.x < 1 + tol &&
puv.y > -tol && puv.y < 1 + tol)
{
withinB = true;
}
// Break out early, no sense wasting time if we already have the answer.
if(withinA && withinB) break;
}
if(!(withinA && withinB)) {
// Intersection curve lies entirely outside one of the surfaces, so
// it's fake.
split.Clear();
return;
}
Various fixes for warnings and minutia This commit consists of numerous small changes, none significant enough to merit a commit on their own: * Added extra braces to quash for-loop variable scoping issues for older compilers (or "g++ -fno-for-scope") * Appeased "unreachable code" warnings, spurious or otherwise * Added casts to fix integer-variable signedness warnings * Added a dummy virtual method to the VectorFileWriter class to silence the -Wweak-vtables warning from Clang++ * Renamed some parameters in the Expr and GraphicsWindow classes to eliminate "parameter shadows a field" warnings * Removed an inert "0 ||" from a conditional, and changed a "&& 0" into an "#if 0" * Added missing elements to array/struct/class initializers to zap further warnings * Indented some cpp conditionals where appropriate * Qualified some variables and functions as static to quiet "no previous declaration" warnings * toolbar.cpp needed to #include<icons-proto.h> to fix those same "no previous declaration" warnings from icons.h * Added some casts and const qualifiers to the Win32 code to address warnings produced by g++ when compiling under MinGW * Rewrote Cnf{Freeze,Thaw}Float() to use a union rather than pointer aliasing; this makes g++ a lot happier * Removed redundant #includes from win32/w32util.cpp * With Jonathan's blessing, shortened the last line of the About dialog text to better match the preceding lines
2013-10-19 13:36:45 +08:00
#if 0
if(sb->deg == 2) {
Add code to subdivide (with de Castljau's algorithm) a surface, and use that for surface-line intersections. That has major problems with the heuristic on when to stop and do Newton polishing. There's also an issue with all the Newton stuff when surfaces join tangent. And update the wishlist to reflect current needs. [git-p4: depot-paths = "//depot/solvespace/": change = 1925]
2009-03-08 18:59:57 +08:00
dbp(" ");
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
SCurvePt *prev = NULL, *v;
Discard intersection curves that lie entirely outside of one surface's domain of u, v in [0, 1]. Cache the starting guess when projecting a point into a ratpoly surface, to avoid brute force searching for a good one every time. Split edges even if they aren't quite inside the trim curve, since the trim boundaries are pwl, not exact; unnecessary splits won't hurt, but failure to split when necessary will. Make the triangulation code use a better (but not perfect) epsilon, to avoid "can't find ear" failures on very fine meshes. And turn on compiler optimization! I had somehow forgotten about that, and it's a ~2x improvement. [git-p4: depot-paths = "//depot/solvespace/": change = 2026]
2009-08-21 12:58:28 +08:00
dbp("split.pts.n = %d", split.pts.n);
Add code to subdivide (with de Castljau's algorithm) a surface, and use that for surface-line intersections. That has major problems with the heuristic on when to stop and do Newton polishing. There's also an issue with all the Newton stuff when surfaces join tangent. And update the wishlist to reflect current needs. [git-p4: depot-paths = "//depot/solvespace/": change = 1925]
2009-03-08 18:59:57 +08:00
for(v = split.pts.First(); v; v = split.pts.NextAfter(v)) {
if(prev) {
Discard intersection curves that lie entirely outside of one surface's domain of u, v in [0, 1]. Cache the starting guess when projecting a point into a ratpoly surface, to avoid brute force searching for a good one every time. Split edges even if they aren't quite inside the trim curve, since the trim boundaries are pwl, not exact; unnecessary splits won't hurt, but failure to split when necessary will. Make the triangulation code use a better (but not perfect) epsilon, to avoid "can't find ear" failures on very fine meshes. And turn on compiler optimization! I had somehow forgotten about that, and it's a ~2x improvement. [git-p4: depot-paths = "//depot/solvespace/": change = 2026]
2009-08-21 12:58:28 +08:00
Vector e = (prev->p).Minus(v->p).WithMagnitude(0);
Add code to identify planes and cylindrical surfaces from a solid of revolution, and put them in the same form as if they had been draw by an extrusion (so that we can use all the same special case intersection curves). And add code to merge coincident faces into one. That turns out to be more than a cosmetic/efficiency thing, since edge splitting fails at the join between two coincident faces. [git-p4: depot-paths = "//depot/solvespace/": change = 1965]
2009-06-05 13:38:41 +08:00
SS.nakedEdges.AddEdge((prev->p).Plus(e), (v->p).Minus(e));
Add code to subdivide (with de Castljau's algorithm) a surface, and use that for surface-line intersections. That has major problems with the heuristic on when to stop and do Newton polishing. There's also an issue with all the Newton stuff when surfaces join tangent. And update the wishlist to reflect current needs. [git-p4: depot-paths = "//depot/solvespace/": change = 1925]
2009-03-08 18:59:57 +08:00
}
prev = v;
}
Add plane-plane intersection as a special case (to generate the trimmed line), and plane-line intersection. Terminate the Bezier surface subdivision on a chord tolerance, and that seems okay now. And print info about the graphics adapter in the text window, could be useful. Also have a cylinder-detection routine that works; should special case those surfaces in closed form since they are common, but not doing it yet. [git-p4: depot-paths = "//depot/solvespace/": change = 1928]
2009-03-15 04:01:20 +08:00
}
Various fixes for warnings and minutia This commit consists of numerous small changes, none significant enough to merit a commit on their own: * Added extra braces to quash for-loop variable scoping issues for older compilers (or "g++ -fno-for-scope") * Appeased "unreachable code" warnings, spurious or otherwise * Added casts to fix integer-variable signedness warnings * Added a dummy virtual method to the VectorFileWriter class to silence the -Wweak-vtables warning from Clang++ * Renamed some parameters in the Expr and GraphicsWindow classes to eliminate "parameter shadows a field" warnings * Removed an inert "0 ||" from a conditional, and changed a "&& 0" into an "#if 0" * Added missing elements to array/struct/class initializers to zap further warnings * Indented some cpp conditionals where appropriate * Qualified some variables and functions as static to quiet "no previous declaration" warnings * toolbar.cpp needed to #include<icons-proto.h> to fix those same "no previous declaration" warnings from icons.h * Added some casts and const qualifiers to the Win32 code to address warnings produced by g++ when compiling under MinGW * Rewrote Cnf{Freeze,Thaw}Float() to use a union rather than pointer aliasing; this makes g++ a lot happier * Removed redundant #includes from win32/w32util.cpp * With Jonathan's blessing, shortened the last line of the About dialog text to better match the preceding lines
2013-10-19 13:36:45 +08:00
#endif // 0
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->Start()).Equals(sb->Finish()),
"Unexpected zero-length edge");
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +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
split.source = SCurve::Source::INTERSECTION;
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
into->curve.AddAndAssignId(&split);
}
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
void SSurface::IntersectAgainst(SSurface *b, SShell *agnstA, SShell *agnstB,
More work on Booleans. This works only for planes, and only for non-coincident faces. There's also a problem when I don't generate the full intersection polygon of shell B against a given surface in shell A; I need to modify the code to not require that. [git-p4: depot-paths = "//depot/solvespace/": change = 1910]
2009-02-01 13:13:43 +08:00
SShell *into)
{
More poking at Booleans; generate the unsplit intersection curves for planes against planes. [git-p4: depot-paths = "//depot/solvespace/": change = 1907]
2009-01-27 15:59:58 +08:00
Vector amax, amin, bmax, bmin;
GetAxisAlignedBounding(&amax, &amin);
b->GetAxisAlignedBounding(&bmax, &bmin);
if(Vector::BoundingBoxesDisjoint(amax, amin, bmax, bmin)) {
// They cannot possibly intersect, no curves to generate
return;
}
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
Vector alongt, alongb;
SBezier oft, ofb;
bool isExtdt = this->IsExtrusion(&oft, &alongt),
isExtdb = b->IsExtrusion(&ofb, &alongb);
Add plane-plane intersection as a special case (to generate the trimmed line), and plane-line intersection. Terminate the Bezier surface subdivision on a chord tolerance, and that seems okay now. And print info about the graphics adapter in the text window, could be useful. Also have a cylinder-detection routine that works; should special case those surfaces in closed form since they are common, but not doing it yet. [git-p4: depot-paths = "//depot/solvespace/": change = 1928]
2009-03-15 04:01:20 +08:00
if(degm == 1 && degn == 1 && b->degm == 1 && b->degn == 1) {
// Line-line intersection; it's a plane or nothing.
Vector na = NormalAt(0, 0).WithMagnitude(1),
nb = b->NormalAt(0, 0).WithMagnitude(1);
double da = na.Dot(PointAt(0, 0)),
db = nb.Dot(b->PointAt(0, 0));
Vector dl = na.Cross(nb);
if(dl.Magnitude() < LENGTH_EPS) return; // parallel planes
dl = dl.WithMagnitude(1);
Vector p = Vector::AtIntersectionOfPlanes(na, da, nb, db);
// Trim it to the region 0 <= {u,v} <= 1 for each plane; not strictly
// necessary, since line will be split and excess edges culled, but
// this improves speed and robustness.
int i;
double tmax = VERY_POSITIVE, tmin = VERY_NEGATIVE;
for(i = 0; i < 2; i++) {
SSurface *s = (i == 0) ? this : b;
Vector tu, tv;
s->TangentsAt(0, 0, &tu, &tv);
double up, vp, ud, vd;
s->ClosestPointTo(p, &up, &vp);
ud = (dl.Dot(tu)) / tu.MagSquared();
vd = (dl.Dot(tv)) / tv.MagSquared();
// so u = up + t*ud
// v = vp + t*vd
if(ud > LENGTH_EPS) {
tmin = max(tmin, -up/ud);
tmax = min(tmax, (1 - up)/ud);
} else if(ud < -LENGTH_EPS) {
tmax = min(tmax, -up/ud);
tmin = max(tmin, (1 - up)/ud);
} else {
if(up < -LENGTH_EPS || up > 1 + LENGTH_EPS) {
// u is constant, and outside [0, 1]
tmax = VERY_NEGATIVE;
}
}
if(vd > LENGTH_EPS) {
tmin = max(tmin, -vp/vd);
tmax = min(tmax, (1 - vp)/vd);
} else if(vd < -LENGTH_EPS) {
tmax = min(tmax, -vp/vd);
tmin = max(tmin, (1 - vp)/vd);
} else {
if(vp < -LENGTH_EPS || vp > 1 + LENGTH_EPS) {
// v is constant, and outside [0, 1]
tmax = VERY_NEGATIVE;
}
}
}
Many changes: * Rewrite surface handles in curves, so that Booleans beyond the first don't screw up. * If an intersection curve is identical to an existing curve (as happens when faces are coincident), take the piecewise linearization of the existing curve; this stops us from screwing up when different shells are pwl'd at different chord tols. * Hook up the plane faces again. * Remove coincident (parallel or anti-parallel) edges from the coincident-face edge lists when doing Booleans; those may happen if two faces are coincident with ours. * Miscellaneous bugfixes. It doesn't seem to screw up very much now, although tangent edges (and insufficient pwl resolution) may still cause problems. [git-p4: depot-paths = "//depot/solvespace/": change = 1929]
2009-03-16 07:04:45 +08:00
if(tmax > tmin + LENGTH_EPS) {
Add plane-plane intersection as a special case (to generate the trimmed line), and plane-line intersection. Terminate the Bezier surface subdivision on a chord tolerance, and that seems okay now. And print info about the graphics adapter in the text window, could be useful. Also have a cylinder-detection routine that works; should special case those surfaces in closed form since they are common, but not doing it yet. [git-p4: depot-paths = "//depot/solvespace/": change = 1928]
2009-03-15 04:01:20 +08:00
SBezier bezier = SBezier::From(p.Plus(dl.ScaledBy(tmin)),
p.Plus(dl.ScaledBy(tmax)));
AddExactIntersectionCurve(&bezier, b, agnstA, agnstB, into);
}
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
} else if((degm == 1 && degn == 1 && isExtdb) ||
(b->degm == 1 && b->degn == 1 && isExtdt))
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
{
// The intersection between a plane and a surface of extrusion
SSurface *splane, *sext;
if(degm == 1 && degn == 1) {
splane = this;
sext = b;
} else {
splane = b;
sext = this;
}
More poking at Booleans; generate the unsplit intersection curves for planes against planes. [git-p4: depot-paths = "//depot/solvespace/": change = 1907]
2009-01-27 15:59:58 +08:00
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
Vector n = splane->NormalAt(0, 0).WithMagnitude(1), along;
double d = n.Dot(splane->PointAt(0, 0));
SBezier bezier;
(void)sext->IsExtrusion(&bezier, &along);
if(fabs(n.Dot(along)) < LENGTH_EPS) {
// Direction of extrusion is parallel to plane; so intersection
// is zero or more lines. Build a line within the plane, and
// normal to the direction of extrusion, and intersect that line
// against the surface; each intersection point corresponds to
// a line.
Vector pm, alu, p0, dp;
// a point halfway along the extrusion
pm = ((sext->ctrl[0][0]).Plus(sext->ctrl[0][1])).ScaledBy(0.5);
alu = along.WithMagnitude(1);
dp = (n.Cross(along)).WithMagnitude(1);
// n, alu, and dp form an orthogonal csys; set n component to
// place it on the plane, alu component to lie halfway along
// extrusion, and dp component doesn't matter so zero
p0 = n.ScaledBy(d).Plus(alu.ScaledBy(pm.Dot(alu)));
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<SInter> inters = {};
Annotate constants passed as boolean function arguments. This is to ensure that: * it is clear, when looking at the point of usage, what is the purpose of "true" or "false"; * when refactoring, a simple search will bring up any places that need to be changed. Also, argument names were synchronized between declaration and implementation. As an exception, these are not annotated: * Printf(/*halfLine=*/), to avoid pointless churn.
2016-05-25 20:08:19 +08:00
sext->AllPointsIntersecting(p0, p0.Plus(dp), &inters,
/*asSegment=*/false, /*trimmed=*/false, /*inclTangent=*/true);
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
SInter *si;
for(si = inters.First(); si; si = inters.NextAfter(si)) {
Vector al = along.ScaledBy(0.5);
SBezier bezier;
bezier = SBezier::From((si->p).Minus(al), (si->p).Plus(al));
Add Newton iterations to intersect a line with a surface at a point, and to intersect three surfaces at a point. So now when we split an edge, we can refine the split point to lie exactly on the trim curve, so I can do certain Booleans on curved surfaces. But surface-line intersection is globally broken, since I don't correctly detect the number of intersections or provide a good first guess. I maybe should test by bounding boxes and subdivision. [git-p4: depot-paths = "//depot/solvespace/": change = 1920]
2009-02-27 21:04:36 +08:00
AddExactIntersectionCurve(&bezier, b, agnstA, agnstB, into);
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
}
More poking at Booleans; generate the unsplit intersection curves for planes against planes. [git-p4: depot-paths = "//depot/solvespace/": change = 1907]
2009-01-27 15:59:58 +08:00
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
inters.Clear();
} else {
// Direction of extrusion is not parallel to plane; so
Add code to subdivide (with de Castljau's algorithm) a surface, and use that for surface-line intersections. That has major problems with the heuristic on when to stop and do Newton polishing. There's also an issue with all the Newton stuff when surfaces join tangent. And update the wishlist to reflect current needs. [git-p4: depot-paths = "//depot/solvespace/": change = 1925]
2009-03-08 18:59:57 +08:00
// intersection is projection of extruded curve into our plane.
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
int i;
for(i = 0; i <= bezier.deg; i++) {
Vector p0 = bezier.ctrl[i],
p1 = p0.Plus(along);
bezier.ctrl[i] =
Vector::AtIntersectionOfPlaneAndLine(n, d, p0, p1, NULL);
}
More poking at Booleans; generate the unsplit intersection curves for planes against planes. [git-p4: depot-paths = "//depot/solvespace/": change = 1907]
2009-01-27 15:59:58 +08:00
Add Newton iterations to intersect a line with a surface at a point, and to intersect three surfaces at a point. So now when we split an edge, we can refine the split point to lie exactly on the trim curve, so I can do certain Booleans on curved surfaces. But surface-line intersection is globally broken, since I don't correctly detect the number of intersections or provide a good first guess. I maybe should test by bounding boxes and subdivision. [git-p4: depot-paths = "//depot/solvespace/": change = 1920]
2009-02-27 21:04:36 +08:00
AddExactIntersectionCurve(&bezier, b, agnstA, agnstB, into);
Compute surface intersections in a way that is closer to what I will do for real; now handling the special cases of plane against a surface of extrusion. Still need to fix up line-surface intersection to work for curved things, but then some simple curved cases should work (as well as plane-plane). [git-p4: depot-paths = "//depot/solvespace/": change = 1919]
2009-02-23 18:06:02 +08:00
}
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
} else if(isExtdt && isExtdb &&
sqrt(fabs(alongt.Dot(alongb))) >
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
sqrt(alongt.Magnitude() * alongb.Magnitude()) - LENGTH_EPS)
{
// Two surfaces of extrusion along the same axis. So they might
// intersect along some number of lines parallel to the axis.
Vector axis = alongt.WithMagnitude(1);
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Replace all ZERO and memset with C++11 brace-initialization. This will allow us to use non-POD classes inside these objects in future and is otherwise functionally equivalent, as well as more concise. Note that there are some subtleties with handling of brace-initialization. Specifically: On aggregates (e.g. simple C-style structures) using an empty brace-initializer zero-initializes the aggregate, i.e. it makes all members zero. On non-aggregates an empty brace-initializer calls the default constructor. And if the constructor doesn't explicitly initialize the members (which the auto-generated constructor doesn't) then the members will be constructed but otherwise uninitialized. So, what is an aggregate class? To quote the C++ standard (C++03 8.5.1 §1): An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). In SolveSpace, we only have to handle the case of base classes; Constraint and Entity have those. Thus, they had to gain a default constructor that does nothing but initializes the members to zero.
2015-03-27 23:31:23 +08:00
List<SInter> inters = {};
List<Vector> lv = {};
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
Revamp the edge classification for Booleans. I no longer make a separate polygon of coincident (with same or opposite normal) faces; I instead test all the edges against the other shell, and have extended the classify-against-shell stuff to handle those cases. And the normals are now perturbed a bit numerically, to either side of the edge, to distinguish tangency from a coincident surface. This seems to work fairly well, although things still tend to fail when the piecewise linear tolerance is too coarse. [git-p4: depot-paths = "//depot/solvespace/": change = 1964]
2009-06-04 11:59:40 +08:00
double a_axis0 = ( ctrl[0][0]).Dot(axis),
a_axis1 = ( ctrl[0][1]).Dot(axis),
b_axis0 = (b->ctrl[0][0]).Dot(axis),
b_axis1 = (b->ctrl[0][1]).Dot(axis);
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
if(a_axis0 > a_axis1) swap(a_axis0, a_axis1);
if(b_axis0 > b_axis1) swap(b_axis0, b_axis1);
Revamp the edge classification for Booleans. I no longer make a separate polygon of coincident (with same or opposite normal) faces; I instead test all the edges against the other shell, and have extended the classify-against-shell stuff to handle those cases. And the normals are now perturbed a bit numerically, to either side of the edge, to distinguish tangency from a coincident surface. This seems to work fairly well, although things still tend to fail when the piecewise linear tolerance is too coarse. [git-p4: depot-paths = "//depot/solvespace/": change = 1964]
2009-06-04 11:59:40 +08:00
double ab_axis0 = max(a_axis0, b_axis0),
ab_axis1 = min(a_axis1, b_axis1);
if(fabs(ab_axis0 - ab_axis1) < LENGTH_EPS) {
// The line would be zero-length
return;
}
Vector axis0 = axis.ScaledBy(ab_axis0),
axis1 = axis.ScaledBy(ab_axis1),
axisc = (axis0.Plus(axis1)).ScaledBy(0.5);
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
oft.MakePwlInto(&lv);
int i;
for(i = 0; i < lv.n - 1; i++) {
Vector pa = lv.elem[i], pb = lv.elem[i+1];
pa = pa.Minus(axis.ScaledBy(pa.Dot(axis)));
pb = pb.Minus(axis.ScaledBy(pb.Dot(axis)));
pa = pa.Plus(axisc);
pb = pb.Plus(axisc);
Annotate constants passed as boolean function arguments. This is to ensure that: * it is clear, when looking at the point of usage, what is the purpose of "true" or "false"; * when refactoring, a simple search will bring up any places that need to be changed. Also, argument names were synchronized between declaration and implementation. As an exception, these are not annotated: * Printf(/*halfLine=*/), to avoid pointless churn.
2016-05-25 20:08:19 +08:00
b->AllPointsIntersecting(pa, pb, &inters,
/*asSegment=*/true,/*trimmed=*/false, /*inclTangent=*/false);
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
}
SInter *si;
for(si = inters.First(); si; si = inters.NextAfter(si)) {
Vector p = (si->p).Minus(axis.ScaledBy((si->p).Dot(axis)));
double ub, vb;
Annotate constants passed as boolean function arguments. This is to ensure that: * it is clear, when looking at the point of usage, what is the purpose of "true" or "false"; * when refactoring, a simple search will bring up any places that need to be changed. Also, argument names were synchronized between declaration and implementation. As an exception, these are not annotated: * Printf(/*halfLine=*/), to avoid pointless churn.
2016-05-25 20:08:19 +08:00
b->ClosestPointTo(p, &ub, &vb, /*mustConverge=*/true);
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
SSurface plane;
plane = SSurface::FromPlane(p, axis.Normal(0), axis.Normal(1));
b->PointOnSurfaces(this, &plane, &ub, &vb);
p = b->PointAt(ub, vb);
SBezier bezier;
Revamp the edge classification for Booleans. I no longer make a separate polygon of coincident (with same or opposite normal) faces; I instead test all the edges against the other shell, and have extended the classify-against-shell stuff to handle those cases. And the normals are now perturbed a bit numerically, to either side of the edge, to distinguish tangency from a coincident surface. This seems to work fairly well, although things still tend to fail when the piecewise linear tolerance is too coarse. [git-p4: depot-paths = "//depot/solvespace/": change = 1964]
2009-06-04 11:59:40 +08:00
bezier = SBezier::From(p.Plus(axis0), p.Plus(axis1));
Generate intersection curves for surfaces of extrusion along a parallel axis (which are always lines parallel to that axis). Remove short pwl segments when possible, to avoid short edges that get misclassified. [git-p4: depot-paths = "//depot/solvespace/": change = 1952]
2009-05-18 15:26:51 +08:00
AddExactIntersectionCurve(&bezier, b, agnstA, agnstB, into);
}
inters.Clear();
lv.Clear();
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
} else {
// Try intersecting the surfaces numerically, by a marching algorithm.
// First, we find all the intersections between a surface and the
// boundary of the other surface.
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 spl = {};
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
int a;
for(a = 0; a < 2; a++) {
Enable and mollify -Wunused-variable. In my (whitequark's) experience this warning tends to expose copy-paste errors with a high SNR, so making a few fragments slightly less symmetric is worth it. Also mollify -Wlogical-op-parentheses while we're at it.
2016-02-14 08:36:54 +08:00
SShell *shA = (a == 0) ? agnstA : agnstB;
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
SSurface *srfA = (a == 0) ? this : b,
*srfB = (a == 0) ? b : this;
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
SEdgeList el = {};
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
srfA->MakeEdgesInto(shA, &el, MakeAs::XYZ, NULL);
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
SEdge *se;
for(se = el.l.First(); se; se = el.l.NextAfter(se)) {
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<SInter> lsi = {};
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
srfB->AllPointsIntersecting(se->a, se->b, &lsi,
Annotate constants passed as boolean function arguments. This is to ensure that: * it is clear, when looking at the point of usage, what is the purpose of "true" or "false"; * when refactoring, a simple search will bring up any places that need to be changed. Also, argument names were synchronized between declaration and implementation. As an exception, these are not annotated: * Printf(/*halfLine=*/), to avoid pointless churn.
2016-05-25 20:08:19 +08:00
/*asSegment=*/true, /*trimmed=*/true, /*inclTangent=*/false);
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
if(lsi.n == 0) continue;
// Find the other surface that this curve trims.
Use C99 integer types and C++ boolean types/values This change comprehensively replaces the use of Microsoft-standard integer and boolean types with their C99/C++ standard equivalents, as the latter is more appropriate for a cross-platform application. With matter-of-course exceptions in the Win32-specific code, the types/values have been converted as follows: QWORD --> uint64_t SQWORD --> int64_t DWORD --> uint32_t SDWORD --> int32_t WORD --> uint16_t SWORD --> int16_t BYTE --> uint8_t BOOL --> bool TRUE --> true FALSE --> false The following related changes are also included: * Added C99 integer type definitions for Windows, as stdint.h is not available prior to Visual Studio 2010 * Changed types of some variables in the SolveSpace class from 'int' to 'bool', as they actually represent boolean settings * Implemented new Cnf{Freeze,Thaw}Bool() functions to support boolean variables in the Registry * Cnf{Freeze,Thaw}DWORD() are now Cnf{Freeze,Thaw}Int() * TtfFont::Get{WORD,DWORD}() are now TtfFont::Get{USHORT,ULONG}() (names inspired by the OpenType spec) * RGB colors are packed into an integer of type uint32_t (nee DWORD), but in a few places, these were represented by an int; these have been corrected to uint32_t
2013-10-02 13:45:13 +08:00
hSCurve hsc = { (uint32_t)se->auxA };
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
SCurve *sc = shA->curve.FindById(hsc);
hSSurface hother = (sc->surfA.v == srfA->h.v) ?
sc->surfB : sc->surfA;
SSurface *other = shA->surface.FindById(hother);
SInter *si;
for(si = lsi.First(); si; si = lsi.NextAfter(si)) {
Vector p = si->p;
double u, v;
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
srfB->ClosestPointTo(p, &u, &v);
srfB->PointOnSurfaces(srfA, other, &u, &v);
p = srfB->PointAt(u, v);
if(!spl.ContainsPoint(p)) {
SPoint sp;
sp.p = p;
// We also need the edge normal, so that we know in
// which direction to march.
srfA->ClosestPointTo(p, &u, &v);
Vector n = srfA->NormalAt(u, v);
sp.auxv = n.Cross((se->b).Minus(se->a));
sp.auxv = (sp.auxv).WithMagnitude(1);
spl.l.Add(&sp);
}
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
}
lsi.Clear();
}
el.Clear();
}
More poking at Booleans; generate the unsplit intersection curves for planes against planes. [git-p4: depot-paths = "//depot/solvespace/": change = 1907]
2009-01-27 15:59:58 +08:00
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
while(spl.l.n >= 2) {
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
SCurve sc = {};
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
sc.surfA = h;
sc.surfB = b->h;
sc.isExact = false;
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
sc.source = SCurve::Source::INTERSECTION;
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
Vector start = spl.l.elem[0].p,
startv = spl.l.elem[0].auxv;
spl.l.ClearTags();
spl.l.elem[0].tag = 1;
spl.l.RemoveTagged();
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
// Our chord tolerance is whatever the user specified
double maxtol = SS.ChordTolMm();
Use a separate value of chord tolerance for exporting. Before this commit, a single chord tolerance was used for both displaying and exporting geometry. Moreover, this chord tolerance was specified in screen pixels, and as such depended on zoom level. This was inconvenient: exporting geometry with a required level of precision required awkward manipulations of viewport. Moreover, since some operations, e.g. mesh watertightness checking, were done on triangle meshes which are generated differently depending on the zoom level, these operations could report wildly different and quite confusing results depending on zoom level. The chord tolerance for display and export pursue completely distinct goals: display chord tolerance should be set high enough to achieve both fast regeneration and legible rendering, whereas export chord tolerance should be set to match the dimension tolerance of the fabrication process. This commit introduces two distinct chord tolerances: a display and an export one. Both chord tolerances are absolute and expressed in millimeters; this is inappropriate for display purposes but will be fixed in the next commits. After exporting, the geometry is redrawn with the chord tolerance configured for the export and an overlay message is displayed; pressing Esc clears the message and returns the display back to normal.
2016-01-27 12:07:54 +08:00
int maxsteps = max(300, SS.GetMaxSegments()*3);
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
// The curve starts at our starting point.
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
SCurvePt padd = {};
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
padd.vertex = true;
padd.p = start;
sc.pts.Add(&padd);
Point2d pa, pb;
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 np, npc = Vector::From(0, 0, 0);
bool fwd = false;
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
// Better to start with a too-small step, so that we don't miss
// features of the curve entirely.
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
double tol, step = maxtol;
for(a = 0; a < maxsteps; a++) {
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
ClosestPointTo(start, &pa);
b->ClosestPointTo(start, &pb);
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Vector na = NormalAt(pa).WithMagnitude(1),
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
nb = b->NormalAt(pb).WithMagnitude(1);
if(a == 0) {
Vector dp = nb.Cross(na);
if(dp.Dot(startv) < 0) {
// We want to march in the more inward direction.
fwd = true;
} else {
fwd = false;
}
}
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
int i;
for(i = 0; i < 20; i++) {
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
Vector dp = nb.Cross(na);
if(!fwd) dp = dp.ScaledBy(-1);
dp = dp.WithMagnitude(step);
np = start.Plus(dp);
npc = ClosestPointOnThisAndSurface(b, np);
tol = (npc.Minus(np)).Magnitude();
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
if(tol > maxtol*0.8) {
I had been using LENGTH_EPS as the tolerance on both xyz points and uv points. This is inconsistent, unless the surface happens to be a plane square with side length one. So modify the SBspUv tests to take a surface, and measure distance linearized in that surface. That fixes at least one mis-classification bug, and doesn't seem to break anything. [git-p4: depot-paths = "//depot/solvespace/": change = 2005]
2009-07-02 11:32:17 +08:00
step *= 0.90;
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
} else {
I had been using LENGTH_EPS as the tolerance on both xyz points and uv points. This is inconsistent, unless the surface happens to be a plane square with side length one. So modify the SBspUv tests to take a surface, and measure distance linearized in that surface. That fixes at least one mis-classification bug, and doesn't seem to break anything. [git-p4: depot-paths = "//depot/solvespace/": change = 2005]
2009-07-02 11:32:17 +08:00
step /= 0.90;
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
}
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
if((tol < maxtol) && (tol > maxtol/2)) {
// If we meet the chord tolerance test, and we're
// not too fine, then we break out.
break;
}
}
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
SPoint *sp;
for(sp = spl.l.First(); sp; sp = spl.l.NextAfter(sp)) {
if((sp->p).OnLineSegment(start, npc, 2*SS.ChordTolMm())) {
sp->tag = 1;
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
a = maxsteps;
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
npc = sp->p;
}
}
padd.p = npc;
Clean up the marching step size / chord tol stuff, and add code to export an inexact curve by approximating it with piecwise cubic segments (whose endpoints lie exactly on the curve, and with exact tangent directions at the endpoints). [git-p4: depot-paths = "//depot/solvespace/": change = 1995]
2009-06-22 10:54:09 +08:00
padd.vertex = (a == maxsteps);
Now we are actually marching. There seems to be either a numerical problem or a tendency to generate backwards edges or both, need to debug that. But it generates the curve, and begins to work. And change the edge classification. Now instead of testing for point-on-surface using the results of the raycasting, test for point-on-surface as a separate step. That stops us from picking up the additional numerical error from the surface-line intersection, which may be significant if the ray is parallel or almost parallel to the surface. [git-p4: depot-paths = "//depot/solvespace/": change = 1991]
2009-06-21 17:02:36 +08:00
sc.pts.Add(&padd);
start = npc;
}
spl.l.RemoveTagged();
// And now we split and insert the curve
Add beginnings of marching surface intersection; I can find all the boundary points, at least. That required some changes to what gets passed around (for example because to project a point onto this inexact curve, we need to know which two surfaces it trims so that we can do a Newton's method on them). And fix stupidity in the way that I calculated edge normals; I just did normal in uv space, and there's no particular reason why that would be normal in xyz. So edges in long skinny surfaces failed, for example. [git-p4: depot-paths = "//depot/solvespace/": change = 1990]
2009-06-19 15:56:33 +08:00
SCurve split = sc.MakeCopySplitAgainst(agnstA, agnstB, this, b);
sc.Clear();
into->curve.AddAndAssignId(&split);
}
spl.Clear();
}
More poking at Booleans; generate the unsplit intersection curves for planes against planes. [git-p4: depot-paths = "//depot/solvespace/": change = 1907]
2009-01-27 15:59:58 +08:00
}
Make Boolean union work when the shells have coincident plane faces. Still on planes only, no curved surface intersections. [git-p4: depot-paths = "//depot/solvespace/": change = 1912]
2009-02-09 20:40:48 +08:00
//-----------------------------------------------------------------------------
// Are two surfaces coincident, with the same (or with opposite) normals?
// Currently handles planes only.
//-----------------------------------------------------------------------------
Add const qualifiers to functions where trivially possible. This will allow us in future to accept `const T &` anywhere it's necessary to reduce the amount of copying. This commit is quite conservative: it does not attempt very hard to refactor code that performs incidental mutation. In particular dogd and caches are not marked with the `mutable` keyword. dogd will be eliminated later, opening up more opportunities to add const qualifiers. This commit also doesn't introduce any uses of the newly added const qualifers. This will be done later.
2016-05-21 13:18:00 +08:00
bool SSurface::CoincidentWith(SSurface *ss, bool sameNormal) const {
Make Boolean union work when the shells have coincident plane faces. Still on planes only, no curved surface intersections. [git-p4: depot-paths = "//depot/solvespace/": change = 1912]
2009-02-09 20:40:48 +08:00
if(degm != 1 || degn != 1) return false;
if(ss->degm != 1 || ss->degn != 1) return false;
Vector p = ctrl[0][0];
Vector n = NormalAt(0, 0).WithMagnitude(1);
double d = n.Dot(p);
if(!ss->CoincidentWithPlane(n, d)) return false;
Vector n2 = ss->NormalAt(0, 0);
if(sameNormal) {
if(n2.Dot(n) < 0) return false;
} else {
if(n2.Dot(n) > 0) return false;
}
return true;
}
Add const qualifiers to functions where trivially possible. This will allow us in future to accept `const T &` anywhere it's necessary to reduce the amount of copying. This commit is quite conservative: it does not attempt very hard to refactor code that performs incidental mutation. In particular dogd and caches are not marked with the `mutable` keyword. dogd will be eliminated later, opening up more opportunities to add const qualifiers. This commit also doesn't introduce any uses of the newly added const qualifers. This will be done later.
2016-05-21 13:18:00 +08:00
bool SSurface::CoincidentWithPlane(Vector n, double d) const {
Make Boolean union work when the shells have coincident plane faces. Still on planes only, no curved surface intersections. [git-p4: depot-paths = "//depot/solvespace/": change = 1912]
2009-02-09 20:40:48 +08:00
if(degm != 1 || degn != 1) return false;
if(fabs(n.Dot(ctrl[0][0]) - d) > LENGTH_EPS) return false;
if(fabs(n.Dot(ctrl[0][1]) - d) > LENGTH_EPS) return false;
if(fabs(n.Dot(ctrl[1][0]) - d) > LENGTH_EPS) return false;
if(fabs(n.Dot(ctrl[1][1]) - d) > LENGTH_EPS) return false;
Trim trailing whitespace.
2015-03-29 08:30:52 +08:00
Make Boolean union work when the shells have coincident plane faces. Still on planes only, no curved surface intersections. [git-p4: depot-paths = "//depot/solvespace/": change = 1912]
2009-02-09 20:40:48 +08:00
return true;
}
//-----------------------------------------------------------------------------
// In our shell, find all surfaces that are coincident with the prototype
// surface (with same or opposite normal, as specified), and copy all of
// their trim polygons into el. The edges are returned in uv coordinates for
// the prototype surface.
//-----------------------------------------------------------------------------
void SShell::MakeCoincidentEdgesInto(SSurface *proto, bool sameNormal,
Many changes: * Rewrite surface handles in curves, so that Booleans beyond the first don't screw up. * If an intersection curve is identical to an existing curve (as happens when faces are coincident), take the piecewise linearization of the existing curve; this stops us from screwing up when different shells are pwl'd at different chord tols. * Hook up the plane faces again. * Remove coincident (parallel or anti-parallel) edges from the coincident-face edge lists when doing Booleans; those may happen if two faces are coincident with ours. * Miscellaneous bugfixes. It doesn't seem to screw up very much now, although tangent edges (and insufficient pwl resolution) may still cause problems. [git-p4: depot-paths = "//depot/solvespace/": change = 1929]
2009-03-16 07:04:45 +08:00
SEdgeList *el, SShell *useCurvesFrom)
Make Boolean union work when the shells have coincident plane faces. Still on planes only, no curved surface intersections. [git-p4: depot-paths = "//depot/solvespace/": change = 1912]
2009-02-09 20:40:48 +08:00
{
SSurface *ss;
for(ss = surface.First(); ss; ss = surface.NextAfter(ss)) {
if(proto->CoincidentWith(ss, sameNormal)) {
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
ss->MakeEdgesInto(this, el, SSurface::MakeAs::XYZ, useCurvesFrom);
Make Boolean union work when the shells have coincident plane faces. Still on planes only, no curved surface intersections. [git-p4: depot-paths = "//depot/solvespace/": change = 1912]
2009-02-09 20:40:48 +08:00
}
}
SEdge *se;
for(se = el->l.First(); se; se = el->l.NextAfter(se)) {
double ua, va, ub, vb;
proto->ClosestPointTo(se->a, &ua, &va);
proto->ClosestPointTo(se->b, &ub, &vb);
if(sameNormal) {
se->a = Vector::From(ua, va, 0);
se->b = Vector::From(ub, vb, 0);
} else {
// Flip normal, so flip all edge directions
se->b = Vector::From(ua, va, 0);
se->a = Vector::From(ub, vb, 0);
}
}
}
Reference in New Issue Copy Permalink