5 Commits

Author	SHA1	Message	Date
Danny McGee	e1235d6a8f	Mitigate BVH retargeting jitter (#29) ... The initial BVH retargeting solution produced very jittery results. Much of that jitter was eliminated by using linear interpolation between frames instead of immediate stepped transitions, but some jittering still remained, particularly noticeable in the finger motions. This PR largely fixes remaining jitter issues by making a few changes: #### Frame-time quantization Previously, we had been using the `BvhAnim::timer` field incorrectly, by manually resetting it after `Timer::just_finished` returned `true`, and returning `0.0` as the interpolation parameter for that frame. This resulted in a herky-jerky animation due to misalignment between the BVH animation's frame time and the actual application refresh rate, meaning we would lose fractions of a frame every time the timer elapsed and the frame was incremented. This PR addresses that by never calling `Timer::reset` and always using `Timer::percent` for the interpolation parameter. #### Matrix instability This PR refactors the retargeting system to operate on `Affine3A` matrices instead of `Mat4`s. `Affine3A` represents a SIMD-optimized 3x3 matrix + a translation vector, so using it provides a small performance boost in addition to being slightly more numerically stable. Additionally, we now periodically re-orthonormalize the 3x3 matrices in-between operations to mitigate drifting due to the accumulation of floating-point errors.	2024-01-19 00:11:01 -05:00
Danny McGee	cba70a62ae	Single-object viewer POC (#14) ... This commit implements a Sketchfab-style single-object viewer as a minimal proof-of-concept. ### `@storyteller/studio-web` This is a new package to house web components for interfacing with the `@storyteller/studio` WASM library. It currently includes a single component, `<sts-viewer />`, which is exported from `@storyteller/studio-web/viewer`. ### `react-frontend` This is a new application intended as a proof-of-concept and testbed for React interop with `@storyteller/studio-web`. Web components are currently a little bit fiddly to use in a React application. `react-frontend/src/app/studio-viewer.tsx` demonstrates how a React-idiomatic component can be written as a thin wrapper around a web component, and `react-frontend/src/app/app.tsx` demonstrates that wrapper component in use.	2023-12-07 15:46:32 -05:00
Danny McGee	5fed2b6f59	Transform gizmos (#10) ... This PR adds functional transform gizmos, along with some new frontend UI to configure their state. ## Work Done - [x] Global / Local space toggling - [x] Gizmo type toggling - [x] Translation gizmo - [x] Axis-constrained translation - [x] Plane-constrained translation - [x] Screen-space translation - [x] Rotation gizmo - [x] Axis-constrained rotation - [x] Screen-space rotation - [x] "Trackball" rotation - [ ] Scale gizmo - [ ] Single-axis non-uniform scaling - [ ] Two-axis non-uniform scaling - [ ] Uniform scaling - [ ] Combination gizmos - [x] Translation + Rotation - [ ] Translation + Scale - [ ] Rotation + Scale - [ ] Translation + Rotation + Scale ## Future Enhancements ### Better visual feedback during transformations Most DCCs update the visual representation of the transform gizmo while it's in the process of being actively manipulated. (For example, Blender draws lines in world-space to indicate that the transformation is constrained to a particular axis or plane, hides widgets that aren't participating in the current transformation, and illustrates the angle of difference between the original and updated rotation.) At a minimum, we should indicate the current widget being manipulated with a color change (like we already do when the widget is being hovered). This requires a bit of additional state management effort but shouldn't be overly difficult to add in a future PR. ### Better visual representation for rotation widgets Currently, each axis of rotation is represented on the gizmo with a full-circle, unlit "ring" shape. This can make it difficult to tell which half of the ring is closer to the viewer, and thus to get an accurate understanding of how the transform is currently oriented, without moving the camera around. A [previous version of this work](#4) bisected the rings along a view-oriented plane and rendered the "back-side" ring halves with reduced opacity. This PR uses static meshes instead of an immediate-mode drawing API to render the gizmos, so a custom shader would be the ideal way to reproduce that effect. That effort should be deferred until after upgrading to Bevy 0.12, as it brings some changes which would likely require some updates to that code. ### Better visual representation for translation arrows A [previous version of this work](#4) faded the opacity of the translation arrows when they were very close to parallel with the view direction — an idea that was borrowed from Blender. It's a nice UX enhancement because translating along an axis that's very close to parallel with the view direction can be janky and error-prone, so it makes sense to disallow it and instead provide an unobstructed view of the screen-space translation widget. This would also require a custom shader, in addition to some extra state management logic (to disable the widgets when their opacity is zeroed out). Given that it's only a "nice-to-have," I think it makes sense to backlog this for the time being. ## Known Issues ### Picking There's currently a bug in `bevy_mod_picking` that affects the hit-testing of the gizmo widgets. The gizmos are currently _rendering_ on top of everything else (via a second camera and render-layer configurations), but the picking behavior doesn't take the rendering order into account. This means that portions of the gizmo widgets which are occluded by geometry in the world cannot be interacted with (because the occluding geometry interrupts the picking raycast). > Update: This is fixed in the new release of `bevy_mod_picking` for Bevy 0.12. ### Delay on first-render The first time a new widget shape is spawned, there's a noticeable delay (of 1 to several seconds) before the widget is rendered, during which the UI becomes unresponsive. This is likely the same issue that triggers a much longer delay when the glTF scene is being spawned. I'd like to see if Bevy 0.12 resolves or mitigates this issue before addressing it on our end, but if it doesn't, I think we can simply spawn an instance of each of the gizmo widgets off-screen on application startup to prevent lag spikes from happening while a user is interacting with the scene. ### Non-deterministic hover states The widget colors are currently being updated by, e.g., multiplying on mouser-over and dividing on mouse-out. Occasionally those events happen in quick enough succession that our mouse-out listener is not invoked, so a widget gets "stuck" in its hovered state. The fix for this is trivial but fairly annoying, so I haven't gotten around to it yet. 🙂 > Update: This issue mostly occurs when in world-space mode. The gizmo is torn > down and re-built from scratch once a drag event completes, which can despawn > the gizmo while an element is still hovered. The solution will likely involve > completely separate materials for default and hover states, similar to how > `bevy_mod_picking`'s highlight plugin works. ### Object Selection There's still some jank happening with object selection and camera orbiting, as mentioned in #8. I don't anticipate this being overly difficult to resolve, but I'm deferring that work until more of the core functionality is built out since it's not a blocker for now. ### Skinned Mesh Selection There's also still the issue of the skinned mesh being unselectable — which, it turns out, is [technically not actually the case](https://github.com/bevyengine/bevy/issues/4971). Rather, the picking raycast "sees" the mesh as if it were still in its original rest pose, because the mesh deformations are processed on the GPU and not reflected back to the CPU-side representation. I think the ideal workaround for this will be to attach capsule-shaped Rapier colliders to the skeleton (similar to Unreal Engine's auto-generated "physics assets" for skeletal meshes) and use those for picking instead. This would automatically enable skeletal pose manipulation (by transforming the individual joints), which is already a long term goal. It also makes more sense from a practical standpoint, as the mesh itself cannot be independently transformed while it's bound to the skeleton, so there's little point in directly selecting it.	2023-11-10 15:51:17 -05:00
Danny McGee	06751e54f6	Object picking (#8) ... This PR implements basic object selection, with help from `bevy_mod_picking` and `bevy_mod_outline`. ### Work Done * Click to select objects in the world * Selected objects become visually highlighted * The selected entity is available globally on the `Res<Selection>` resource * Selected entities can also be queried via the `Selected` marker component * Pressing `F` will "focus" the camera on the selected entity * Pressing `Esc` will clear the active selection ### Known Issues * We're currently using `bevy_mod_picking`'s "Selection" feature, which isn't aware of our own input events. As a consequence, it will select the object under the cursor when releasing `LMB` after orbiting the camera, which is not what we want. This should be pretty easily fixable by dropping `bevy_mod_picking`'s selection feature and reading the object under the cursor in our own click listener that only runs if the LMB event is unhandled. * The skinned mesh is not currently selectable. This is likely fixable by adjusting the logic in `scene::mark_scene_objects`... somehow. The `Gltf` data structure is kind of a nightmare to work with, so this will take some investigation. ### Future Enhancements * For parity with other DCC apps, the "Focus" action should also adjust the camera zoom level to "frame" the selected object in the view. Punting on that for now because I'm not super confident about the math involved. * Group selection with Shift/Ctrl and/or marquee selection would be really nice to have, but probably not critical for now.	2023-11-02 13:32:58 -04:00
Danny McGee	ce6db7fc3c	Refactoring, reorganization and cleanup (#7) ... ### New `math` module * Traits for error-tolerant floating-point comparisons * Traits for interpolation and easing * Bevy plugin to manage 3D interpolations with ECS components ### `skybox` module refactor * ECS resource to enable external skybox selection/updates * System run conditions for more idiomatic/ECS-friendly control flow ### Camera controller refactor * Renamed from `orbit_cam` to `camera_controller` * Now delegates to the new interpolation plugin for WASD motion smoothing * Simple API for attaching the `CameraController` component to the camera from another module -- this resolves an awkward separation-of-concerns situation where we had to configure a bunch of render-quality settings in the camera controller module ### Scene module refactor * Renamed from `test_scene` to `scene` * This module is now responsible for configuring the skybox * This module is now responsible for spawning the camera and configuring the render settings	2023-10-31 16:39:10 -04:00