Design

Elements

For spheres and polygons in a 3D view, the idea is to have a relatively straightforward idealized perspective view of the element, typically translucent to allow other entities to be visible. Planes present challenges, because they necessarily either fill the view or "disappear" into a line for views in specific directions.

Once we have 2D views, they will straightforwardly show 1D elements, lines and curves, presumably along with cross-sections of 2D elements that cut the view-plane.

However, the display of lower-dimensional items presents some choices: Should a point be presented like a small sphere? That can create confusion when there are actual small spheres present. Or should they appear more disk-like, but always facing the viewer? A strategy is to avoid partial shading or occlusion, to emphasize that the points only exist at an idealized point, so hence it is impossible for "part" of a point to be visible (after all, Euclid begins with "a point is that which has no part".)

Regulators

It should be possible to turn on display of a regulator(s), so that what they are regulating is indicated graphically, along with their current value. For example, a straight-up Euclidean distance regulator between two points could be represented as a "dimension bar" as in technical drawings, showing the distance. (These sorts of things should likely typically be lighter-weight/fainter/smaller/smaller type-size than element representations.) A curvature regulator could conceivably be represented by its inverse, i.e. a radius dimension, although that breaks down for planes and near-planes.

Constraints

Insofar as constraints remain just fixing the values of regulators, the existence of a constraint could be displayed just by a lock icon on the display of the associated regulator, and/or some distinctive styling: heavier/brighter/redder/bolder, or something like that.

However we anticipate eventually going beyond such constraints, which may create the need for new visual metaphors.

One worthwhile example to consider consists of equality constraints. It seems certain, for example, that we will want to constrain two distiances to be equal without constraining this common value.

In traditional synthetic geometry diagrams, the state that two segments are/must be equal is often indicated by a decoration on the segment, such as (one or more) tick mark(s), etc. To make dyna3 useful for producing such diagrams, we certainly want to allow such decorations. So one possibility to consider is that dyna3 might make such decorations precisely the representation of equality constraints. In other words, line segments are shown with ticks (and/or other such decorations) if and only if they are constrained to be equal and display of that constraint is turned on. Flipped around, adding tick marks would amount to imposing an equality constraint. If there is an intuitive way to "add tick marks" in the user interface, that could provide a very convenient way to impose and manipulate such equality constraints.

Implementation

Right now, we're drawing all the spheres in a single fragment shader. For each pixel, we do ray-casting to get a fragment for each sphere, and then we depth-sort the fragments to handle translucency.

Performance limits

• Array size. As of commit a34fd0f, the SPHERE_MAX array size seems to affect frame rate a lot, even though we should only be using the first few elements of each array. Not sure whether this is coming from a depth-sorting bug, a memory handling detail, or something else.
  • The logistics of initializing the arrays and working around register limits could be the problem, as described in this forum post.
  • Commit ec48592 adds a crude frame time monitor, so we can see how changes affect timing. In commit f62f44b, we can adjust the size of the internal fragment arrays (controlled by SPHERE_MAX_INTERNAL) while keeping the size of the uniforms (controlled by SPHERE_MAX_UNIFORM) at 12. The rough measurements below confirm that the internal array size can affect frame rate a lot, even though we only use the first three spheres' worth of elements.

    SPHERE_MAX_INTERNAL	Frame time (ms)
    3	16.7
    4	16.7
    5	16.7
    6	16.8
    8	19.7
    10	22.4
    12	25.1
    14	28.6

• Shader variables. Browsers seem to limit the number of variables that fragment shaders can store. For example, see this vulnerability report and code review for Chromium. This limit doesn't seem to be part of the OpenGL standard, so it's hard to pin down.

References

This tutorial on metaballs describes various ways to pass object data into a fragment shader that draws many objects.