glen/dyna3
1
0
Fork 0
Code Issues 14 Pull Requests 1 Actions Projects Releases 2 Wiki Activity

Application prototype #14

Merged
glen merged 101 commits from app-proto into main 2024-10-21 23:38:28 +00:00
Conversation 1 Commits 101 Files Changed 12 +1428
Vectornaut commented 2024-10-21 23:13:11 +00:00
Collaborator
Copy Link

On the branch to be merged, I've started prototyping a user interface for dyna3 in the app-proto folder. The interface is dynamically constructed using Sycamore. Since it's written in Rust and compiled to WebAssembly, just like the engine will be, it should connect to the engine seamlessly.

The prototype includes:

  • An application state model (the AppState type)
    • A constraint problem model (the Assembly type), used in the application state
  • Two views
    • A 3D rendering of the assembly (the Display component)
    • A list of elements and constraints (the Outline component)

The following features confirm that the views can reflect and send input to the model:

  • You can select elements by clicking and shift-clicking them in the outline. The selected elements are highlighted in the display.
  • You can add elements using a button above the outline. The new elements appear in the display.
On the branch to be merged, I've started prototyping a user interface for dyna3 in the `app-proto` folder. The interface is dynamically constructed using [Sycamore](https://sycamore.dev). Since it's written in Rust and compiled to WebAssembly, just like the engine will be, it should connect to the engine seamlessly. The prototype includes: * An application state model (the `AppState` type) * A constraint problem model (the `Assembly` type), used in the application state * Two views * A 3D rendering of the assembly (the `Display` component) * A list of elements and constraints (the `Outline` component) The following features confirm that the views can reflect and send input to the model: * You can select elements by clicking and shift-clicking them in the outline. The selected elements are highlighted in the display. * You can add elements using a button above the outline. The new elements appear in the display.
Vectornaut added 101 commits 2024-10-21 23:13:11 +00:00 
In the process, find and correct an error in the --+ vertex, which was
miswritten as ---.
To get the right order, flip the sign of the `z` component in the output
of the projection map.
Change the base color and default opacity to keep the picture looking
broadly the same.
This properly reflects the modularity of the code, and it simplifies
indentation and syntax highlighting.
The ray-caster triangles cover the whole viewport, so they'll completely
overdraw the previous frame.
This is a first step toward general depth sorting.
Switch from a hard-coded sorting network for four fragments to an
insertion sort, which should work for any number of fragments.
This helps confirm that the generalized depth-sorting is working.
Keep the hard-coded spheres for comparison.
In the process, start exploring array size limits of various kinds.
This wastes a lot of CPU time, as explained on lines 253--258 of
`main.rs`, but it's better than the previous version, which could block
graphics updates system-wide for seconds on end.
It's time to start optimizing. Frame time is easy to measure, and we can
use it to gauge responsiveness.
This is how I typically schedule draw calls in JavaScript applications.
The baseline CPU activity for the display prototype is now in line with
other pages (though perhaps a bit higher), and the profiler shows little
time being spent in draw calls, even when I'm continually moving a
slider. The interface feels pretty responsive overall, although the
sliders seem to be lagging a bit.
In the process, write code to make updates that depend on the time
between frames.
At the higher frequency we were using earlier, the overhead from
updating the readout contributed significantly to the frame interval.
In debug mode, show the layer count instead of the shaded image. This
reveals a bug: testing whether the hit depth is NaN doesn't actually
detect sphere misses, because `sphere_cast` returns -1 rather than NaN
to indicate a miss.
This doesn't affect GPU performance noticeably, so benchmarks before and
after the change should be comparable.
No noticeable effect on GPU performance.
In debug mode, assign most of the color scale to even layer counts. Odd
layer counts are topologically prohibited, so we should rarely see bugs
severe enough to produce them.
This seems to increase graphics pipe use from 50--60% to 55--65%.
This seems to weaken the intersection disk illusion.
Also add infrastructure for switching between constructions.
In the process, add a way to build a sphere by offset and curvature.
The low-curvature construction admits odd layer counts.
You can now switch tabs from the keyboard using the usual radio button
interaction.
Remove GPU code and uniforms that were used as scaffolding during
initial development, but have now been replaced by CPU analogues.
The size of the internal fragment arrays is what really matters, as
discussed in the "Display" page on the wiki.
Update variable names and comments in code from the display prototype.
Switch `Assembly.elements` to a hash map too, since that's probably
closer to what we'll want in the future.
When we access an element, we always have its key, either because the
slab iterator yielded it along side the element or because we used it to
get the element from the slab.
Draft listing of constraints in outline view.
Also, write constructors for state objects.
Use `details` elements to hide and show constraints.
This makes profiling more comparable with `inversive-display`.
This tells Sycamore that the outline view of an element should update
when the element's constraint set has changed. To make the constraint
set hashable, so we can include it in the diff key, we store it as a
`BTreeSet` instead of an `FxHashSet`.
Since we're using `BTreeSet` for element constraint sets now, we might
as well use it for the selection set too. This removes the `rustc-hash`
dependency.
In the process, switch selection storage back to `FxHashSet`, reverting
commit b3afd6f.
This moves us toward dropping the separate display prototype.
Calling `try_insert_element` or `insert_new_element` in a responsive
context shouldn't make the context track `elements_by_id`.
Together with 25fa108 and 4f8f360, this lets us do a benchmarking
routine for `full-interface` which is comparable to the one we've been
using for `inversive-display`.
This reduces register pressure significantly. This stepping stone commit
temporarily removes highlighting of intersections and cusps.
This increases resource use a bit, because we now have to hold two
fragments in memory at once instead of just one. It's still much better
than holding all of the top twelve fragments, though!
Incorporate the engine prototype from pull request #13, which just got
merged into `main`.
glen commented 2024-10-21 23:35:26 +00:00
Owner
Copy Link

Runs as advertised. Merging.

Runs as advertised. Merging.
glen merged commit 86fa682b31 into main 2024-10-21 23:38:28 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
question

More information is needed

  
todo

Planned step in implementation

  
wontfix

This won't be fixed

No Label
bug
duplicate
enhancement
question
todo
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: glen/dyna3#14
No description provided.
Delete Branch "app-proto"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?