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
This commit does three things:
* Recognizes that BeginFrame()/EndFrame() are badly named, since
BeginFrame() sets up framebuffer, and EndFrame() flushes a frame,
and they do not have to be called in pairs; and so renames them
to NewFrame()/FlushFrame().
* Reduces the amount of frame flushes in GraphicsWindow::Paint()
to two, which is the minimum since we use two different cameras
for geometry and UI;
* Changes the FPS measurement code to only take into account
the time spent rendering our main geometry, and not the UI
rendering or window system interaction time.
Before this commit, tooltips in the text window are drawn under
the red "X" indicating a disabled button. After this commit, they
are moved on top of that.
This commit also alters the OpenGL renderers' SetCamera() method
to clear the depth buffer, as that would interfere with drawing
the UI; the toolbar would get occluded by geometry.
To actually achieve improved performance with the OpenGL 2 renderer,
we have to cache geometry that doesn't change when the viewport does
(note that the rendered pixels can change quite dramatically because
we can reconfigure shaders; e.g. stippling can be drawn in screen
coordinates).
This commit adds a BatchCanvas interface that can be implemented
by renderers, and uses it for drawing entities such as lines and
points.
There are two main reasons to desire an OpenGL 2 renderer:
1. Compatibility. The compatibility profile, ironically, does not
offer a lot of compatibility, and our OpenGL 1 renderer will not
run on Android, iOS, or WebGL.
2. Performance. The immediate mode does not scale, and in fact
becomes very slow with only a moderate amount of lines on screen,
and only a somewhat large amount of triangles.
This commit implements a basic OpenGL 2 renderer that uses only
features from the (OpenGL 3.2) core profile. It is not yet faster
than the OpenGL 1 renderer, primarily because it uses a lot of small
draw calls.
This commit uses OpenGL 2 on Linux and Mac OS X directly (i.e. links
to the GL symbols from version 2+); on Windows this is impossible
with the default drivers, so for now OpenGL 1 is still used there.
OpenGL 2 and newer do not have the glPolygonMode(..., GL_LINES) API,
so produce the wireframe on our side. It's somewhat slow, and draws
every line three times, but it is cached when the OpenGL 2 renderer
is used, and this should do for a debugging feature.
This specific implementation seems to have lingered from the days
before IdList was stored sorted. This commit has resulted in a ~5%
improvement in Generate::DIRTY time for modelisation.slvs on a GCC 6
release build.
gcc 6 displays these when compiling in release mode; all of these
warnings except the rankOk one were benign because there would have
been an error about the incomplete switch statement.
The rankOk warning highlighted a real problem: bailing early to
didnt_converge would have branched on an uninitialized variable.
This is a common and convenient behavior; the basename is
pre-selected, so exporting multiple views requires just one keystroke
to put the cursor after the basename.
This is useful in case one wants to create a workplane based on
one of the reference ones, to be explicit, or to avoid fishing out
again the line segments used to create a workplane at an angle.
If a generated mesh is non-watertight, and this is not noticed for
some reason (e.g. the markers are dismissed), and the mesh is
exported for further processing, it could cause problems down
the line.
Before this commit, every debug message was correctly printed
to stdout, but they were all concatenated onto a single line in
the Visual Studio "Output" pane.
GroupsInOrder is an extremely hot function, especially during object
picking: before this commit, it was easy to get second plus latencies
on picking, and after this commit picking is almost real-time.
Abstract the exact details of the OpenGL renderer in the render.h
header; this allows us to use GL-specific types in the renderer
class and functions without including OpenGL (and Windows, where
applicable) headers in every source file.
We do not support clobbering the source tree with build products,
nor recommend this in any documentation, and this already leads to
weird bugs with the resource system. Show an explicit error in this
case to avoid confusion.
These points can be used for constraining the width of the text
(or to the width of the text).
The main parts of the commit are:
* TtfFont is restructured to be able to return the aspect ratio
for a given string.
* This aspect ratio is written to the savefile, such that even if
the font is missing, the sketch would still be solved correctly.
* The two additional points are constrained via perpendicularly
to the two main points (which form a v vector).
The compatibility features are as follows:
* When the font is missing in old files, 1:1 aspect ratio is used,
which works for the replacement symbol anyhow.
* When the two additional points are missing in old files, their
would-be positions are calculated and they are moved there,
avoiding 'jumping' of underconstrained sketches.
SolveSpace 2.0 used the height of 'A' (i.e. cap height) to determine
the reference height.
SolveSpace 2.1 completely broke that during transition to Freetype,
and used something more or less random, by using FT_Set_Char_Size
with units_per_EM.
SolveSpace 2.2 attempted to fix that, but also used something more
or less random, by using FT_Request_Size with "unit" values.
Turns out that Freetype actually doesn't have a concept of cap height
at all. It is possible to extract it from the TT_OS2 table that is
present in some TrueType fonts, but it is not present in Microsoft
fonts (the msttcorefonts ones), and for those Linux fonts in which
it is present it doesn't appear very reliable.
So instead, use the height of 'A' instead, like version 2.0 did.
This has the advantage that it is quite bulletproof, and also matches
exactly what the old files are measured against.
One downside is that fonts without an 'A' glyph would not render.
We can deal with that when it becomes a problem.
whitequark
EvilSpirit
Elvira Khabirova