turned out straightforward, in great part because the planes are
workplanes (6 DOF, represented by a unit quaternion and a point),
and therefore make it easy to get a vector in the plane, as well as
a normal.
And on that subject, replace the previous hack for parallel vector
constraints with a better hack: pivot on the initial numerical
guess, to choose which components of the cross product to drive to
zero. Ugly, but I think that will be as robust as I can get.
[git-p4: depot-paths = "//depot/solvespace/": change = 1699]
not have much motivation behind them, but they seem to work. And
make sure that we don't solve multiple times without repainting in
between, and tweak the text window a bit more.
[git-p4: depot-paths = "//depot/solvespace/": change = 1696]
foreground and background colours are now specified separately, and
it's possible to insert half-line spaces. So now I have a window
that lets me show/hide groups, and select the active one.
[git-p4: depot-paths = "//depot/solvespace/": change = 1695]
issues, when the points are not all in the same coordinate system.
All painful, of course. Also add continuous line drawing, and
auto-constraining of line segments as I draw.
[git-p4: depot-paths = "//depot/solvespace/": change = 1683]
determine what goes in front (e.g. put a drawn line in front of the
reference plane, even if the z order would want the opposite), and
some tweaks to the mouse behaviour, and a function to modify
constraints like dimensions so that the are initially satisfied.
[git-p4: depot-paths = "//depot/solvespace/": change = 1681]
the label associated with a constraint. And that even works,
changes the length of the line.
[git-p4: depot-paths = "//depot/solvespace/": change = 1678]
and point-in-plane. These work, but the equation is still stupid,
solving everything at once and not substituting trivial equations.
[git-p4: depot-paths = "//depot/solvespace/": change = 1677]
points are now entities like any others; so a line segment request
will generate three entities, the line segment and its endpoints. I
think that's cleaner.
When I do step and repeats (and imports, and other similar), I'll
need a consistent way to assign those entity ids. That assignment
must not change if the sketch is edited. I don't have a clean way
to do that; best thought right now is to keep a record of what maps
have been used previously, and not pick a new map as long as it's
possible to use one that was used previously.
This all means that more crap gets pushed in to the Entity
structure, so that they can keep track of what solver variables
define them. Still seems better, though. I'm closer to ready
to start solving.
[git-p4: depot-paths = "//depot/solvespace/": change = 1673]
expressions that we wish to keep around. And make the 2d coordinate
system (that causes points to generate 2 unknowns, not 3) an
attribute of the request, not the group, and add user interface to
change that.
[git-p4: depot-paths = "//depot/solvespace/": change = 1670]
on-screen, and I can drag the label. That's progress. Also
implement a bunch of untested expression stuff, since I'll need
that for the values of the dimensions, for example.
[git-p4: depot-paths = "//depot/solvespace/": change = 1668]
Jonathan Westhues