Points #82

Vectornaut · 2025-04-28T19:54:27Z

Vectornaut commented

2025-04-28 19:54:27 +00:00

Summary

On the main branch, there's only one kind of element, which for many purposes is assumed to be a sphere. The branch to be merged creates distinct structures for spheres and points, which are unified under a new element trait. It pursues some of the future directions laid out in pull request #80, and it starts addressing issue #27 by adding rudimentary rendering for points.

Organization

Elements

The `Element` trait

Each kind of element must implement the assembly::Element trait, which is analogous to the Regulator trait introduced in pull request #80. The branch to be merged has two Element implementations: Sphere and Point. You can think of Sphere as the successor to the Element structure from the main branch, where we often assumed that all elements were spheres.

Display

The `Scene` structure

The display::Scene structure from this pull request does for the display component what the engine::ConstraintProblem structure from pull request #80 does for the engine: it holds assembly data in a format that's easy for low-level operations to consume.

The `DisplayItem` trait

Anything that can be displayed has to implement the display::DisplayItem trait. It currently provides methods for two tasks:

Writing element data to the Scene structure.
Ray-casting for click-to-select.

The ray-casting method for spheres is taken from the assembly module on the main branch. The method for points is new.

The shaders

Each point is individually rendered with the newly introduced vertex and fragment shaders point.vert and point.frag. The fragment shader that ray-casts all of the assembly's spheres has been renamed from inversive.frag to spheres.frag, since it's no longer intended to handle every type of element.

Future directions

Nudging for points seems to work out of the box, because deformations are described in uniform coordinates, and engine::local_unif_to_std is already implemented for both point and sphere representation vectors. However, I've occasionally seen engine crashes during nudging.
There are now simple, natural ways to set up constraints that can't be satisfied. For example, you can confine two points to the surface of a sphere, fix the distance between them, and then fix the sphere's radius at a value too small to accommodate the points. We should start thinking more seriously about how to handle this.
Implementing occlusion for points would make the display much easier to read.
An assembly's elements are now stored as reference-counted pointers. This opens the door to referring to elements using pointers instead of collection keys, so we wouldn't have to supply the element collection to every method that needs to refer to elements.

## Summary On the main branch, there's only one kind of element, which for many purposes is assumed to be a sphere. The branch to be merged creates distinct structures for spheres and points, which are unified under a new element trait. It pursues some of the [future directions](pulls/80/#future-directions) laid out in pull request #80, and it starts addressing issue #27 by adding rudimentary rendering for points. ## Organization ### Elements #### The `Element` trait Each kind of element must implement the `assembly::Element` trait, which is analogous to the `Regulator` trait introduced in pull request #80. The branch to be merged has two `Element` implementations: `Sphere` and `Point`. You can think of `Sphere` as the successor to the `Element` structure from the main branch, where we often assumed that all elements were spheres. ### Display #### The `Scene` structure The `display::Scene` structure from this pull request does for the display component what the `engine::ConstraintProblem` structure from pull request #80 does for the engine: it holds assembly data in a format that's easy for low-level operations to consume. #### The `DisplayItem` trait Anything that can be displayed has to implement the `display::DisplayItem` trait. It currently provides methods for two tasks: - Writing element data to the `Scene` structure. - Ray-casting for click-to-select. The ray-casting method for spheres is taken from the `assembly` module on the main branch. The method for points is new. #### The shaders Each point is individually rendered with the newly introduced vertex and fragment shaders `point.vert` and `point.frag`. The fragment shader that ray-casts all of the assembly's spheres has been renamed from `inversive.frag` to `spheres.frag`, since it's no longer intended to handle every type of element. ### Future directions - Nudging for points seems to work out of the box, because deformations are described in uniform coordinates, and `engine::local_unif_to_std` is already implemented for both point and sphere representation vectors. However, I've occasionally seen engine crashes during nudging. - There are now simple, natural ways to set up constraints that can't be satisfied. For example, you can confine two points to the surface of a sphere, fix the distance between them, and then fix the sphere's radius at a value too small to accommodate the points. We should start thinking more seriously about how to handle this. - Implementing occlusion for points would make the display much easier to read. - An assembly's elements are now stored as reference-counted pointers. This opens the door to referring to elements using pointers instead of collection keys, so we wouldn't have to supply the element collection to every method that needs to refer to elements.

Vectornaut added 15 commits 2025-04-28 19:54:28 +00:00

Encapsulate rendering program setup 8a82fe457f

Drop unused vertex array object 3590b1ad4e

Sketch a point rendering pipeline 23f395331a

Only recreate buffers when their contents change 5a1d8bc201

Name attribute sizes d5eaf11a17

Encapsulate scene data cedb1d5b83

Simplify sphere data passing 68abc2ad44

Rename the Element structure to Sphere a1e23543cb

This makes way for an `Element` trait. Some `Sphere` variables, like the
arguments of the sphere insertion methods, have been renamed to show
that they refer specifically to spheres. Others, like the argument of
`ElementOutlineItem`, have kept their general names, because I expect
them to become `Element` trait objects.

Introduce an element trait f9df459a0d

For now, this is just a thin wrapper around the old element structure,
which was renamed to `Sphere` in the previous commit. The biggest
organizational change is moving `cast` into the `DisplayItem` trait.

Generalize the element insertion methods 873de78f2d

Add a point element 1945086586

Also add a new test assembly, "Pointed," to try out the new element.

Color points 0fbb071506

In the process, find and correct a misunderstanding about vertex
attributes. Here's my current understanding. Vertex attributes are
program-independent. When you make a draw call, every enabled attribute
has to have a vertex buffer object bound to it. A simple way to make
sure this happens is to enable only the attributes used by the active
program.

Highlight selected points bbd4ee08b6

In the process, make points round, since the highlighting works better
visually that way.

Click the display to select points b7375e7101

AddRemove: Make a button that adds points

/ test (pull_request) Successful in 2m25s

Details

07a415843d

Vectornaut changed title from ~~points~~ to Points

2025-04-28 19:59:01 +00:00

glen reviewed 2025-04-29 14:40:07 +00:00

app-proto/main.css Outdated

					
				@ -46,3 +46,3 @@

				  height: 32px;

				  font-size: large;

				  /*font-size: large;*/

				}

glen commented

2025-04-29 14:40:07 +00:00

Sorry I am on a mobile device and so will have to make individual comments instead of a single review, polluting your inbox. Anyhow, why are we leaving this css block in place now that it is empty? It is easy to restore in the future if we need it again. Not a fan of "dead code".

Vectornaut commented

2025-04-29 17:10:11 +00:00

Whoops, I forgot to remove those before committing. Removed in commit 35689e3.

Whoops, I forgot to remove those before committing. Removed in commit 35689e3.

glen marked this conversation as resolved

Vectornaut added 1 commit 2025-04-29 17:09:07 +00:00

Drop commented-out CSS declarations

/ test (pull_request) Successful in 2m22s

Details

35689e3241

Vectornaut commented

2025-04-29 18:09:47 +00:00

I've expanded and corrected the pull request description a bit. Summary of changes:

The shaders

Described shader reorganization

Future directions

Corrected the discussion of point nudging. I previously thought it was working by accident, but on closer inspection, it seems to be working because the deformation code was already set up to handle both points and spheres.
Mentioned the possibility of referring to elements by pointer instead of collection key.

I've expanded and corrected the pull request description a bit. Summary of changes: #### The shaders - Described shader reorganization #### Future directions - Corrected the discussion of point nudging. I previously thought it was working by accident, but on closer inspection, it seems to be working because the deformation code was already set up to handle both points and spheres. - Mentioned the possibility of referring to elements by pointer instead of collection key.

glen merged commit a2478febc1 into main

2025-05-01 19:25:14 +00:00

glen referenced this pull request from a commit

2025-05-01 19:25:16 +00:00

feat: Points (#82)

Vectornaut added this to the Demo project 2025-05-10 05:29:53 +00:00

Vectornaut referenced this pull request

2025-05-19 08:20:27 +00:00

Regression in stability of curvature while nudging position #86

Vectornaut referenced this pull request

2025-05-20 01:06:05 +00:00

Regression in stability of curvature while nudging position #86