line width units, on-screen and export visibility. So now we can
use that to modify the default styles, or to create custom styles.
Also add code to draw fat lines, with round endcaps, since gl
doesn't do that.
Next we need some user interface to assign styles to entities, and
to make all the export file formats support the style attributes.
[git-p4: depot-paths = "//depot/solvespace/": change = 2029]
steps in thisShell or thisMesh, and then let the Boolean proceed as
usual. If everything works, then this is equivalent. And it's less
code, and it makes stuff like stepping the step and repeat work.
Also begin to work on line/entity/constraint styles, but no real
work yet.
[git-p4: depot-paths = "//depot/solvespace/": change = 2018]
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]
the arbitrary-magnitude dot product, to classify regions (inside,
outside, coincident) of surfaces against each other.
That lets me always perturb the point for the normals (inside and
outside the edge) by just a chord tolerance, and nothing bad
happens as that distance varies over a few orders of magnitude.
[git-p4: depot-paths = "//depot/solvespace/": change = 1996]
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]
xyz point that I subtracted off had been refined to lie exactly on
our edge's curve, and the uv point that I started with had not. So
normals got randomly screwed up.
[git-p4: depot-paths = "//depot/solvespace/": change = 1978]
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]
little test app that links against it. I still need to polish a few
things, but this is more or less as it should be.
[git-p4: depot-paths = "//depot/solvespace/": change = 1944]
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]
our specified section plane; we then split them according to the
start and endpoints of each STrimBy, using de Castejau's algorithm.
These sections get projected (possibly in perspective, which I do
correctly) into 2d and exported.
Except, for now they just get pwl'd in the export files. That's the
fallback, since it works for any file format. But that's the place
to add special cases for circles etc., or to export them exactly.
DXF supports the latter, but very painfully since I would need to
write a later-versioned file, which requires thousands of lines of
baggage. I'll probably stick with arcs.
[git-p4: depot-paths = "//depot/solvespace/": change = 1936]
closed form. This is a fairly good speedup, and handles tangency
well.
But that shows that tangency has other problems; need to classify
edges correctly (whether they point to a coincident surface) in
curved surfaces too. I need to tweak SShell::ClassifyPoint().
[git-p4: depot-paths = "//depot/solvespace/": change = 1933]
export. So I calculate lighting for each triangle in the mesh, make
a BSP, and then traverse it in-order and output those as SVG or
EPS. And I test edges against the mesh, removing those portions of
the edge that overlap a triangle in front of them (using the
kd-tree to accelerate).
[git-p4: depot-paths = "//depot/solvespace/": change = 1931]
* 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]
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]
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]
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]
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]
segments in Boolean against the shell, not the intersection
polygon. (We just cast a ray, and use the surface-line intersection
function that already existed.) That's slow, but can be
accelerated later.
[git-p4: depot-paths = "//depot/solvespace/": change = 1911]
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]
is O(n^2), not perfectly robust, and the bridge-finding code is
particularly bad. But it works, triangulates, and shouldn't ever
generate zero-area triangles like gl does.
[git-p4: depot-paths = "//depot/solvespace/": change = 1900]
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]
shell. That seems less prone generating stray lines, though it does
sometimes generate gaps.
[git-p4: depot-paths = "//depot/solvespace/": change = 1876]
in the numerical code.
And clean some other stuff, in particular simplifying whenever I
have to take the maximum (or minimum) of three quantities.
[git-p4: depot-paths = "//depot/solvespace/": change = 1855]
specify the plane from which we want to grab the triangles. Shared
edges are then removed with the same code used to check for
watertight meshes, and the remaining edges are assembled into
polygons.
[git-p4: depot-paths = "//depot/solvespace/": change = 1823]
introduced by the bsp routines. It's usually, though not always,
possible to generate a watertight mesh. The occasions where it's
not look ugly, floating point issues, no quick fix.
And use those to generate a list of edges where two different faces
meet, which I can emphasize for cosmetic reasons (and some UI to
specify whether to do that, and with what color).
And make the right mouse button rotate the model, since that was
previously doing nothing.
[git-p4: depot-paths = "//depot/solvespace/": change = 1821]
(+/-1, 0, 0, 0) to some power; that was failing if the magnitude of
w was slightly greater than 1, so that acos() returned NaN.
[git-p4: depot-paths = "//depot/solvespace/": change = 1820]
which I will shortly revert. gl does a much better job, and I'll
have to spend more time to get something reasonable.
[git-p4: depot-paths = "//depot/solvespace/": change = 1809]
that to try to find them if we can't find them by absolute path.
This is intended to make everything still work if you copy an
entire directory tree of files that import each other.
Also add a mechanism to not paint the scene if we're not sure it's
consistent; otherwise got some crashes on startup. And disable both
text and graphic window when displaying a modal dialog, wasn't
doing that always.
[git-p4: depot-paths = "//depot/solvespace/": change = 1808]
separate groups. The section is swept normal to the trajectory,
producing a mesh. I'm doing the triangles only now, not copying
over any entities.
Also fix a bug in the PNG export; rows are 4-aligned, so that was
breaking when the width of the image wasn't divisible by four. Also
fix a bug in lathes, where it generated overlapping triangles for
one segment.
And change the groups to record both "this mesh", the contribution
due to the extrude/lathe/whatever, and the "running mesh", that we
get after applying the requested Boolean op between "this mesh" and
the previous group's "running mesh". I'll use that to make step and
repeats step the mesh too.
[git-p4: depot-paths = "//depot/solvespace/": change = 1801]
point-line distance equal to line segment length. These are
available in both normal and projected versions, with fancy display
for all of these.
[git-p4: depot-paths = "//depot/solvespace/": change = 1793]
just the mesh, no derived entities (but I suppose that I could turn
all points into circles).
And fix some bugs where equations didn't get unique IDs, and make
it possible to lock on to the group's workplane automatically, if
you press W while free in 3d with no workplane selected.
[git-p4: depot-paths = "//depot/solvespace/": change = 1780]
up more. Also change from stupid linear search lists to sorted
binary search lists, remove a stupid bug where I double-generated
entities, and don't do the triple drawing of entities (since
offsets on the Z buffer were doing the same job already).
[git-p4: depot-paths = "//depot/solvespace/": change = 1776]
metadata. And add point-on-face constraints to go with that. Still
needs some cleanup for the user interface.
[git-p4: depot-paths = "//depot/solvespace/": change = 1766]
create a `new' stack-allocated instance of an object; just From,
possibly different versions with different arg types.
[git-p4: depot-paths = "//depot/solvespace/": change = 1763]
triangle list before adding to the BSP, and check if a point in
plane lies in multiple triangles and choose the one with the
biggest normal magnitude (i.e., area) when testing normal
direction.
[git-p4: depot-paths = "//depot/solvespace/": change = 1745]
for that, and storing the triangles instead of rendering them
immediately. Not sure if that's smart; in theory could change from
implementation to implementation, but the results look much better
than I would get myself.
[git-p4: depot-paths = "//depot/solvespace/": change = 1733]
not very well; I'm doing a b-rep, where the boundaries are complex
polygons, and there's too many special cases. I should probably
replace this with a triangle mesh solution.
[git-p4: depot-paths = "//depot/solvespace/": change = 1731]
as a constraint on the direction cosine, rather than driving the
dot product against a rotated vector to zero. The drawing is the
ugly part; to do that for skew lines, I gave up.
Also add a function to clear non-existent items on the selection
after solving, since that could have caused an oops().
[git-p4: depot-paths = "//depot/solvespace/": change = 1727]
we need something to force the points into plane, and the workplane
supplies that), but otherwise straightforward. And add diameter and
equal radius constraints for the arc.
[git-p4: depot-paths = "//depot/solvespace/": change = 1718]
list, and then adding a new entity to that list, and then looking
at that pointer again. Not okay; the add operation might have
forced a realloc. I have to watch for that.
And add a "distance ratio" constraint, plus a new kind of group
that comes with its own workplane. The workplane is not solved for;
it's generated explicitly in terms of elements that are already
solved.
[git-p4: depot-paths = "//depot/solvespace/": change = 1716]
translation; or equivalently, rotation about an arbitrary axis).
Those will be important for step and repeats, and for imported
parts.
Also fix a terrible memory corruption bug: I was freeing the remap
list after I loaded it from the file, but the code that put that
into the SS.group list made only a shallow copy.
[git-p4: depot-paths = "//depot/solvespace/": change = 1715]
Jonathan Westhues