Points #82

Merged
glen merged 16 commits from Vectornaut/dyna3:points into main 2025-05-01 19:25:14 +00:00
Member

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
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.
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.
Also add a new test assembly, "Pointed," to try out the new element.
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.
In the process, make points round, since the highlighting works better
visually that way.
AddRemove: Make a button that adds points
All checks were successful
/ test (pull_request) Successful in 2m25s
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
@ -46,3 +46,3 @@
height: 32px;
font-size: large;
/*font-size: large;*/
}
Owner

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".

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".
Author
Member

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
All checks were successful
/ test (pull_request) Successful in 2m22s
35689e3241
Author
Member

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
Vectornaut added this to the Demo project 2025-05-10 05:29:53 +00:00
Sign in to join this conversation.
No description provided.