It's a deprecated platform that has weird OpenGL-related bugs and
is incompatible with using EGL anyway. It was clear we're going
to drop it, the only question was when. Answer: now.
Before this commit, when an entity is clicked at or dragged, and it
shares a place with other entities, which of them is selected is
decided more or less at random. This is particularly annoying when
dragging.
After this commit, when clicking, an entity from the current group
is given preference, and when dragging, an entity from a request
is given preference. This allows e.g. dragging points of a sketch
even when an extrusion of that sketch is active.
Before this commit, it was possible to add some redundant constraints
(e.g. vertical, horizontal or midpoint) without failing the sketch,
because SolveBySubstitution() removed the redundant equations.
However, this could result in the solve failing later because
the system didn't converge, without any pointers as to the true
cause of the failure.
After this commit, any transparent triangles are drawn last, which
causes them to not clobber the depth buffer, and so if they overlap
some opaque triangles, then these opaque triangles will be visible.
There are still issues with overlapping transparent triangles,
and with transparent triangles overlapping outlines and entities.
It was broken because of three bugs:
* Uninitialized variables in RunCommand;
* Trying to use (OEM-encoded) main() argc/argv arguments instead
of GetCommandLineW();
* Trying to pass relative paths directly into ssfopen.
This commit fixes four issues:
* Instead of WRITE,APPEND, resource.rc was generated using
WRITE,WRITE, which erased #include <windows.h> and prevented
any symbolic definitions (like RT_MANIFEST) from working.
This silently included them using a string type instead,
which did nothing.
* WINVER is bumped to Win7, since that's what we target now.
* Index of RT_MANIFEST is changed to 2, since that's what
it has to be when ISOLATION_AWARE_ENABLED is defined.
* Platform is not restricted to X86 in manifest, since there
is no point in doing so.
Before this commit, if constraints with newly introduced params were
loaded from a file that linked other files, the upgrade code would
attempt to look up a non-existent entity.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.
Before this commit, inserting into BSP tree could easily overflow
the stack because we allocate very large stack frames and, on
convex geometries (e.g. a sphere), the BSP tree degenerates into
a "BSP list", thus requiring one large stack frame per triangle.
This can be reproduced by exporting a 2d shaded view of sphere.
After this commit, the stack frames only contan a pointer to
a supplementary data structure, and moreover it only allocates
its fields on demand, conserving heap memory as well.
As a side effect, an arbitrary classifier limit of 50 vertices
is removed.
This commit implements two improvements. First, it rewrites
SMesh::FirstIntersectionWith() to use an optimal (as currently known)
ray tracing algorithm. Second, it rejects triangles without
an associated face entity outright.
This partially reverts commit 3a585ea.
We no longer need this because the VectorsParallel() is gone, and
there is no chance of pivoting wrong when solving.
Before this commit, parallel constraints in 3d are fragile:
constraints that are geometrically fine can end up singular anyway
because VectorsParallel() pivots wrong but converges anyway.
After this commit, much like in cc07058, the constraints are written
in a different form: instead of trying to remove two degrees of
freedom out of three, all three are removed, and one added; namely,
the constraint introduces a free parameter, signed length ratio.
Before this commit, pt-on-line constraints are buggy. To reproduce,
extrude a circle, then add a datum point and constrain it to the
axis of the circle, then move it. The cylinder will collapse.
To quote Jonathan:
> On investigation, I (a) confirm that the problem is
> the unconstrained extrusion depth going to zero, and (b) retract
> my earlier statement blaming extrude and other similar non-entity
> parameter treatment for this problem; you can easily reproduce it
> with a point in 3d constrained to lie on any line whose length
> is free.
>
> PT_ON_LINE is written using VectorsParallel, for no obvious reason.
> Rewriting that constraint to work on two projected distances (using
> any two basis vectors perpendicular to the line) should fix that
> problem, since replacing the "point on line in 3d" constraint with
> two "point on line in 2d" constraints works. That still has
> the hairy ball problem of choosing the basis vectors, which you
> can't do with a continuous function; you'd need Vector::Normal()
> or equivalent.
>
> You could write three equations and make the constraint itself
> introduce one new parameter for t. I don't know how well that
> would work numerically, but it would avoid the hairy ball problem,
> perhaps elegant at the cost of speed.
Indeed, this commit implements the latter solution: it introduces
an additional free parameter. The point being coincident with
the start of the line corresponds to the parameter being zero, and
point being coincident with the end corresponds to one).
In effect, instead of constraining two of three degrees of freedom
(for which the equations do not exist because of the hairy ball
theorem), it constrains three and adds one more.
Before this commit, polylines got flattened but all other entities
got exported with the proper Z coordinate. After this commit, all
entities are exported with proper Z coordinate.
Also, instead of exporting LWPOLYLINE (2d only), POLYLINE (2d/3d)
is exported; as a bonus it is more compatible with 3rd party
software, since it is older.
The only thing we need it anymore is the package version and platform
configuration, so only include it for that. As a result, less files
are rebuilt when the git commit changes and config.h is regenerated.
Before this commit, any visibility toggle would cause a regeneration.
After this commit, toggling visibility of normals and points never
causes a regeneration, and toggling visibility of edges and outlines
only causes a regeneration when they weren't already generated.
FromTransformationOf is called with an identity rotation or
translation for translation and rotation groups, and for every
group that doesn't produce a solid model. This commit omits any
calculations from it when the relevant part of transformation
would change nothing.
This commit results in a ~10% improvement on testcase
woodworking/big-big-big-woodworking-asm, and splitting the condition
into three parts results in a ~5% improvement on testcase
stress/rotate_groups_0.
SSurface::TriangulateInto first populates the mesh with triangles
that have no color, and then paints them, which confused the code
that detects if a mesh is transparent into thinking that all of them
are; and that broke the "draw back faces in red" feature, since it
is disabled for transparent meshes.
The configuration option "draw back faces in red" aids debugging,
in that it allows to visually identify a non-watertight mesh.
When it is disabled, or when the mesh is transparent, we used to not
draw them at all before this commit; after, they are drawn just like
the front faces.
This has two consequences:
1. Inner surfaces of non-watertight meshes are not see-through
anymore. That used to be the behavior in version 2.0, and it
was accidentally broken in 2.1.
2. Transparent meshes look *much* better.
3. Solids made from a union of a non-transparent and a transparent
one look sensibly at all.
This commit also updates the OpenGL 1 renderer to let it render
such meshes correctly.
This commit performs two main changes:
* Alters the shaders to use only strictly conformant GLSL 2.0.
* Alters the Windows UI to use ANGLE via GL ES 2.0 and EGL 1.4.
This commit also drops official support for Windows XP, since ANGLE
requires a non-XP toolset to build. It is still possible to build
SolveSpace for Windows XP using:
cmake -T v120_xp -DOPENGL=1
whitequark
EvilSpirit
Elvira Khabirova