-
-
Notifications
You must be signed in to change notification settings - Fork 56
Add QEP 341: add 3D pedestrian view #341
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
base: master
Are you sure you want to change the base?
Changes from all commits
719598b
681b690
73263de
17908c2
ea1f493
370c97c
00a8fd5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,99 @@ | ||
| # QGIS Enhancement: Pedestrian walk mode in the 3D Map View | ||
|
|
||
| **Date** 2025/06/18 | ||
|
|
||
| **Author** Benoit De Mezzo ([@benoitdm-oslandia](https://github.com/benoitdm-oslandia)), Jean Felder ([@ptitjano](https://github.com/ptitjano)) | ||
|
|
||
| **Contact** benoit dot de dot mezzo at oslandia dot com, jean dot felder at oslandia dot com | ||
|
|
||
| **Version** QGIS 4.X | ||
|
|
||
| ## Summary | ||
|
|
||
| This QGIS enhancement adds a human-level navigation mode to the 3D view (like Google Street View). It complements the two existing navigation modes. | ||
|
|
||
| This mode can be activated by selecting a specific point or by default from the center of the map. Once this navigation mode is activated, the camera's elevation is locked at 1.80 meters above the ground. This height can be configured in the 3D view configuration dialog. | ||
|
|
||
| ## Proposed Solution | ||
|
|
||
| ### Enabling and disabling this tool | ||
|
|
||
| A drop-down menu (with the 3 navigation modes) in the "camera" tool in the toolbar to easy the switching from one mode to another. | ||
|
|
||
| Once this mode is activated, the user will select where to begin navigation: a marker will be placed vertically above the center of the 3D view. The user moves the marker to the desired location and confirms with a left mouse click or the Enter key. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you clarify how the marker is moved? Is this via drag and drop? (And from a technical perspective, how will you handle the marker and interaction with it?)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The marker follows the mouse moves and is placed on the ground where the mouse cursor is located. There is no need to keep the left mouse button to move the marker and the left mouse click validates the starting point.
The marker is a vertical rubberband going upward from the ground with a fixed length (2 points, but it could be a triangle). Each time the user move the mouse, the marker position is updated. |
||
|
|
||
| Once the user click to select the starting point: | ||
|
|
||
| * the camera moves to a human-like height above the terrain at the selected location | ||
| * the camera is facing the same direction as before activation | ||
benoitdm-oslandia marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * the movement mode changes (see below) | ||
|
|
||
| The user exits this mode by switching to another navigation mode or by pressing the *Esc* key. | ||
|
|
||
| ### Movements | ||
|
|
||
| Movements can be done using the keyboard or mouse and are free: unconstrained by obstacles or roads. The user moves are restricted in the current extent. | ||
|
|
||
| Forward and backward movement will be controlled by the `up` and `down` keys. Lateral movement will be controlled by the `left` and right keys. Lateral mouse movements will allow you to turn without moving. Vertical mouse movements allow you to look up or down. | ||
|
|
||
| Here is the whole key mapping: | ||
|
|
||
| * ARROW and WASD : forward/backward/shift left/shift right | ||
| * `Ctrl`: temporary decrease speed | ||
| * `Shift`: temporary increase speed | ||
|
|
||
| Here is the whole mouse mapping: | ||
|
|
||
| * mouse move: move look at (up, down, left, right) | ||
| * Wheel : permanent speed factor (as in current walk mode) | ||
|
|
||
| ### Existing navigation modes | ||
|
|
||
| The current **Walk** mode will be renamed **Fly** as the pedestrian view is more a real walk mode. | ||
|
|
||
| As we will have 3 navigation modes, the 3D UI should display the current mode in use and a way to switch from one to another. | ||
|
|
||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's still technical details missing here. I would like to see in depth details on how you propose to handle the fixed height-above-ground requirement. @wonder-sk pointed out earlier that
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also: how will you handle walking into the edges of the terrain/nodata areas?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Indeed. @benoitdm-oslandia has been been working on a prototype to improve
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not much can be done in that case, except a fallback to
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Well, you could keep the pedestrian's last elevation so he doesn't fall in potholes/fall off the edge of flat earth 🤣 but rather "float" over them. Another option would be to interpolate missing values.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you add these missing technical details please? Include the proposed changes @benoitdm-oslandia has been testing for heightAt so that voters can make an informed decision.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I made a small fix as the elevation fixes are external to this PR. Does it look good to you @nyalldawson?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's ok for me -- but you may want to get those fixes reviewed and merged first, as this proposal depends on them. Your choice though, we can put this to voting when you're ready.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the elevation fixes are available in this PR
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The PR is ready for review here! |
||
| ### Elevation | ||
|
|
||
| Elevation will be computed with the `heightAt` function. When the user moves in a no-data area the previous valid elevation will be used. | ||
|
|
||
| As the actual implementation is to coarse, we are working on a QGIS pull request (outside this QEP) in order to improve it. It mostly involves two changes: | ||
|
|
||
| * listen to the DTM texture generation in `QgsTerrainGenerator` and store them in a cache. The cache has some logic to only keep the highest level when available. | ||
| * in `Qgs3DMapScene`, when a better level is stored, reload the relevant vector tiles if necessary | ||
|
|
||
| ### Integration | ||
|
|
||
| The pedestrian view map tool will handle the location picking stage (with a rubberband) in its dedicated class file (something like `QgsWalkModeMapTool`) and this map tool will call API functions at the "app" level to activate the walk mode at the user specified location (and set it back at the previous mode when it quits). | ||
|
|
||
| ## Deliverables | ||
|
|
||
| * new maptool class | ||
| * new toolbar button image | ||
|
|
||
| ### Example(s) | ||
|
|
||
| See associated [PR](https://github.com/qgis/QGIS-Enhancement-Proposals/pull/341). | ||
|
|
||
| ### Affected Files | ||
|
|
||
| * QgsCameraController | ||
| * map3dconfigwidget.ui | ||
| * Qgs3DMapConfigWidget | ||
|
|
||
| ## Risks | ||
|
|
||
| None | ||
|
|
||
| ## Performance Implications | ||
|
|
||
| None | ||
|
|
||
| ## Further Considerations/Improvements | ||
|
|
||
| * identification without changing of maptool | ||
| * add a configuration panel to set key/mouse bindings according to user needs | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| Yes | ||
Uh oh!
There was an error while loading. Please reload this page.