engine icon indicating copy to clipboard operation
engine copied to clipboard

Input managment overhaul

Open kpal81xd opened this issue 6 months ago • 2 comments

Overview

This overhaul splits the processing of handling inputs into two categories:

  • Input Frames which contain a collection of deltas generated from one or more input devices. These can range from a mouse movement delta to a gamepad joystick delta.
  • Input Consumers which take these input frames and apply them to perform an action. These can be transformations e.g. orbiting around a particular focus point or camera flying (unconstrained) .

Design

InputDelta

This is an array of values that store the underlying deltas. These can be accumulated added and copied. Once read their values are cleared. E.g. mouse drag gesture would be a delta of size 2.

InputFrame

A group of InputDeltas (deltas). E.g. a transformation could have a move delta of size 3 for a translation and a rotate delta of size 4 for a quaternion.

InputSource

This is an extension on top of InputFrame to represent all the deltas from a particular input source e.g A gamepad with joysticks, buttons and triggers.

InputConsumer

This construct will take an InputFrame and on every update loop consume the current values stored by reading their values and applying them. E.g. A InputFrame consisting of a drag can be used draw a line in a paint program.

InputController

This is an extension on top of InputConsumer that specifically consumes the InputFrame to update a Pose (a construct with a position, rotation and focal distance which can be interpolated). E.g. An orbit controller will attach a particular pose and smoothly update its state to rotate around a focal point.

Feasibility

Pros

  • Since input sources are pure deltas they can be added together into a combined input that includes multiple device types e.g. Gamepad + Mobile touch + Keyboard and mouse. This gives better coverage for input across a range of devices.
  • Controller separation and ownership of its own pose gives better control over how multiple actions can be combined or interpolated before applying it to the target node e.g. switching from orbit mode to fly mode in CameraControls.
  • Input frames can be seralized/deserialized - they can be streamed to recreate precise input for playback or for client prediction / server reconciliation in multiplayer games.

Cons

  • The CameraControls script is now more difficult to understand since controller management and input frame accumulation is managed in here
  • State has to be accumulated manually e.g. button presses
  • No events fired for simple actions (button presses)

Steps

  • [x] Feature creation and use in CameraControls GH-7779
  • [ ] Integration with FPS Controller
  • [ ] Integration into Supersplat Viewer
  • [ ] Extend InputSources to fire events

kpal81xd avatar Jun 18 '25 17:06 kpal81xd

Could you give some sample code to show to use this?

Also if there are multiple InputConsumers which output a pose, is there a way to blend them or weight them?

marklundin avatar Jun 18 '25 18:06 marklundin

Could you give some sample code to show to use this?

Also if there are multiple InputConsumers which output a pose, is there a way to blend them or weight them?

Sample code Ill put into the PR. Blending between InputController poses can be done using the lerp method on the class but can also be done manually

kpal81xd avatar Jun 18 '25 18:06 kpal81xd