Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Gamepad Support via GLFW #986

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Add Gamepad Support via GLFW #986

wants to merge 6 commits into from

Conversation

geringsj
Copy link
Contributor

@geringsj geringsj commented Feb 18, 2022

Publishes Gamepads provided by GLFW as frontend resource. This opens up the possibility to control parts of MegaMol via controller (e.g. View3D, Clipping Plane, etc). The new Exotic Inputs Service is supposed to grow up to feed Gamepad Inputs into MegaMol Graph Modules, e.g. for View3D Camera control.

Summary of Changes

  • Pulls Joystick/Gamepad state from GLFW
  • If a Joystick provides a Gamepad layout mapping via GLFW ("is a XBox-like gamepad"), publishes that Gamepad as a resource
  • Exotic Inputs Service shows GUI Window with current Gamepad states

References and Context

Gamepad controlls are an approach to make manipulation of the Clipping Plane Pose suck less. Also may be cool in general, e.g. on Powerwall or other MegaMol PR stunts/demos.

TODOs

  • Need general approach to manipulate Pose of objects in MegaMol (Camera Pose, Dataset Pose, Clipping Plane Pose) in all the different ways (Arcball, First Person, ...)
  • Map controller axes/buttons to Graph Parameters like the Command Service/Hotkey Editor does? How cool is that.

Test Instructions

Start MegaMol and connect your controller. Look at controller state in GLFW Gamepads window.

mmGamepad

@invor
Copy link
Contributor

invor commented Jun 8, 2022

So the idea is that controller input does not use the same call-based propagation as mouse and keyboard with callback functions (OnMouseButtonCallback etc.)?
Mapping controller inputs directly to parameters sound interesting, but some actions require additional context and manipulate more than a single value at once, e.g. orbital camera movement. A generalized concept for pose, including local and global space transforms, could help but mostly to make different implementations look more alike I guess.

@geringsj
Copy link
Contributor Author

geringsj commented Jun 9, 2022

I guess the current On*Callback solution is kind of awkward, I would argue it puts the wrong kind of responsibility on the graph modules. I would like to abstract away the raw input source and think in 'actions' or 'commands' for the graph which are resolved before graph execution. So you could map different input sources to the 'action' of rotating the camera or moving a clipping plane.

Regarding actually using the controller inputs as envisoined, I think it would require to pull the camera controller out of the view into the frontend in some form. Seemed too much work for the gamepad inputs prototype.

@github-actions

This comment was marked as resolved.

@geringsj geringsj marked this pull request as ready for review October 10, 2023 12:35
@github-actions

This comment was marked as resolved.

@github-actions

This comment was marked as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants