Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
99 changes: 99 additions & 0 deletions qep-341-3d-pedestrian-view.md
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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

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.

how will you handle the marker and interaction with it?

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
* 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.

Copy link
Contributor

@nyalldawson nyalldawson Jul 9, 2025

Choose a reason for hiding this comment

The 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 QgsTerrainGenerator::heightAt() may be inappropriate due to the coarseness of this API -- have you tested to see whether it works and can give a smooth navigation result?

Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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 QgsTerrainGenerator::heightAt() may be inappropriate due to the coarseness of this API -- have you tested to see whether it works and can give a smooth navigation result?

Indeed. @benoitdm-oslandia has been been working on a prototype to improve QgsTerrainGenerator::heightAt() . 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. This replaces,
  • in Qgs3DMapScene, when a better level is stored, reload the relevant vector tiles if necessary

Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Not much can be done in that case, except a fallback to 0 + terrainOffset

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not much can be done in that case, except a fallback to 0 + terrainOffset

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.

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the elevation fixes are available in this PR

Copy link
Contributor Author

@benoitdm-oslandia benoitdm-oslandia Sep 9, 2025

Choose a reason for hiding this comment

The 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