Improve camera control

[yungyuc]

The current camera control uses vanilla Qt3DExtras::QOrbitCameraController and should be improved. The camera control is a critical component in the viewer. It at least needs the following functions and more:

• Resetting.
• WSAD.
• Change of origin.

---

Amended on 27th July 2024

• "Up" and "w" should move toward the top of the window. "Down" and "s" should move toward the bottom of the window. "Q" and "e" should change to move along the z axis (perpendicular to the window).
  • I am not sure about the binding to page up/down. We can use discussions.
  • Implemented with PR Camera: Add movement items to view menu #408.
• Camera reset/original position to be configurable and exposed through Python API. More information: Camera: Add movement items to view menu #408 (comment)
  • Done with PR Camera Controller: expose complete API to python #418

[yanagiragi]

Please let me have a try.

[yungyuc]

@tychuang1211 and @YenPeiChen07 are working on it

[yungyuc]

@Tucchhaa Thanks for the PR #385. After testing I found w and q should swap and s and e should swap. For a simulation / cad code, it is unintuitive for "up" and "down" to move along the z axis (perpendicular to the screen/window). "Up" should go toward the top of window and "down" should go toward the bottom of the window.

We should also add the movements as items in the "View" menu. Could you please help it?

[Tucchhaa]

We should also add the movements as items in the "View" menu. Could you please help it?

@yungyuc do you mean assigning custom keys to the camera's movement?

[yungyuc]

We should also add the movements as items in the "View" menu. Could you please help it?

@yungyuc do you mean assigning custom keys to the camera's movement?

No, but that is also an important feature. It is substantial work and will need a separate issue to track. The ultimate form may be like how vscode and clion (JetBrains IntelliJ-series IDE) work.

---

The "View" menu is like below, and it should contain the movements with hotkey labeled:

[Tucchhaa]

@yungyuc should the movement hotkey items be clickable or disabled?

[yungyuc]

@yungyuc should the movement hotkey items be clickable or disabled?

I was thinking they should be clickable (enabled). I didn't think of a use case for the movement menu items to be disabled. But perhaps I missed something?

[Tucchhaa]

I think of what is the use case of clickable items. When it's clicked we move the camera, but I don't understand why somebody would like to use the camera this way. Like arrows and WASD are pretty intuitive, except forward/backward movement.

But if items are disabled, they are used only in the way to inform the user of hotkeys. And making them clickable, feels like an overkill.

And because there are many ways to move the camera translation in x,y,z + rotation, I worry about not overloading the interface

[yungyuc]

I think of what is the use case of clickable items. When it's clicked we move the camera, but I don't understand why somebody would like to use the camera this way. Like arrows and WASD are pretty intuitive, except forward/backward movement.

The primary reason is for completeness. Anything that can be controlled through keystrokes should be available in the menu. (But menu items may not need to have corresponding keyboard shortcuts.) That is what we are expecting from a GUI program.

And there is an irreplaceable use case of the movement menu item: when keyboard is missing or broken. It frequently happens when operating in a remote desktop.

[yungyuc]

@Tucchhaa Any additional items for this issue?

[Tucchhaa]

I think the main issue was achieved: camera's control was improved. I suggest to close this issue. If we want to add more functionality in the future, we can create a new one 🙂

[yungyuc]

@Tucchhaa sounds good. Let's close this issue. If you have concrete ideas to do something please file an issue. If you just want to discuss please create a discussion conversion. And we can do free chat in discord.