Walk Teleport and other movements do not take into account the unit scale of the Scene #66713

New Issue

Vyacheslav Kobozev · 2019-07-11T17:26:48+02:00

2019-07-11 17:26:48 +02:00

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.86

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-10 23:46, hash: 676543d91f

Short description of error
If you set Unit scale (scene) 0.1, Walk teleport (Space button in walk mode) jumps to empty nowhere
2019-07-11_18-22-54.mp4

walk to void.blend

**System Information** Operating system: Windows-7-6.1.7601-SP1 64 Bits Graphics card: GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.86 **Blender Version** Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-10 23:46, hash: `676543d91f` **Short description of error** If you set Unit scale (scene) 0.1, Walk teleport (Space button in walk mode) jumps to empty nowhere [2019-07-11_18-22-54.mp4](https://archive.blender.org/developer/F7593454/2019-07-11_18-22-54.mp4) [walk to void.blend](https://archive.blender.org/developer/F7593467/walk_to_void.blend)

Vyacheslav Kobozev commented

2019-07-11 17:26:48 +02:00

Added subscriber: @Vyach

blender-admin commented

2019-07-11 17:26:48 +02:00

#69934 was marked as duplicate of this issue

Enrico Grotto commented

2019-07-11 21:20:01 +02:00

Added subscriber: @enrivector

Enrico Grotto commented

2019-07-11 21:20:01 +02:00

Same here

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 1060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.86

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-11 11:00, hash: d663048696
Worked: (optional)

Same here **System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce GTX 1060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.86 **Blender Version** Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-11 11:00, hash: `d663048696` Worked: (optional)

Sebastian Parborg self-assigned this 2019-07-12 11:38:03 +02:00

Sebastian Parborg was unassigned by Dalai Felinto

2019-12-23 16:33:49 +01:00

Dalai Felinto commented

2019-12-23 16:33:49 +01:00

Added subscriber: @ZedDB

Bastien Montagne changed title from ~~Walk Teleport breaks navigation with 0.1 units scale~~ to Walk Teleport and other movements do not take into account the unit scale of the Scene

2020-01-27 17:03:46 +01:00

Valentin commented

2020-04-10 18:18:16 +02:00

Added subscriber: @Poulpator

Valentin commented

2020-04-10 18:18:16 +02:00

Duplicate from #69934

Vyacheslav Kobozev commented

2020-04-10 18:26:58 +02:00

Those one reported later, but yes, should be merged.

Philipp Oeser commented

2020-06-26 22:08:42 +02:00

Added subscribers: @AlbertoVelazquez, @brecht, @lichtwerk, @JacquesLucke, @WilliamReynish

Marco van den Oever commented

2022-10-17 07:50:50 +02:00

Added subscriber: @crashlog

Marco van den Oever commented

2022-10-17 07:50:50 +02:00

I've found that this is due to the walk navigation incorrectly taking the unit scale into account, in the part where gravity, falling and jumping are handled. In fact, the unit scale is taken into account twice, resulting in the weird behavior.

The falling part works as follows:

When we start to fall, the current viewport position (walk->rv3d->viewinv) is stored (walk->teleport.origin)
During every frame after this, the origin is taken, and a distance is subtracted based on the time since falling start and gravity, to simulate acceleration (z_new)
Because we need a delta and not an absolute value, the delta between the newly calculated z-value and the current z-value is taken (z_cur - z_new)
The delta is then set on the dvec vector
Later on, the dvec is scaled according to the unit scale
This overshoots the fall distance, which is compensated by the next frame (resulting in a negative fall distance). But that is then also overshot, so we're being moved from too far down, to too far up, and so forth.

As I understand the code now, the viewport matrix (walk->rv3d->viewinv) already operates in unit scale-adjusted space, so our delta (z_cur - z_new) is already the scaled value we need, so shouldn't be scaled again.
I've first disabled the dvec scale, which also solves the problem, but makes other parts (walking around with wasd) super slow, since those are scaled too.
So it seems the most correct to me to have the falling distance be done in non-scaled space, same as wasd and jump.

Here's a diff of a version I've been testing that seems to solve the problem, in source\blender\editors\space_view3d\view3d_navigate_walk.c, from line 1232:

I'm still testing this locally.

On a side note, I've been wondering whether it'd be nicer to pull this feature out of the core entirely, and move it to an addon. That way, it would be way easier to debug and make changes, or disable entirely. I'm assuming that by enabling such an addon by default and have it use the same keymap, it shouldn't be a breaking change.

Love to hear what you guys think!

I've found that this is due to the walk navigation incorrectly taking the unit scale into account, in the part where gravity, falling and jumping are handled. In fact, the unit scale is taken into account twice, resulting in the weird behavior. The falling part works as follows: - When we start to fall, the current viewport position (walk->rv3d->viewinv) is stored (walk->teleport.origin) - During every frame after this, the origin is taken, and a distance is subtracted based on the time since falling start and gravity, to simulate acceleration (z_new) - Because we need a delta and not an absolute value, the delta between the newly calculated z-value and the current z-value is taken (z_cur - z_new) - The delta is then set on the dvec vector - Later on, the dvec is scaled according to the unit scale - This overshoots the fall distance, which is compensated by the next frame (resulting in a negative fall distance). But that is then also overshot, so we're being moved from too far down, to too far up, and so forth. As I understand the code now, the viewport matrix (walk->rv3d->viewinv) already operates in unit scale-adjusted space, so our delta (z_cur - z_new) is already the scaled value we need, so shouldn't be scaled again. I've first disabled the dvec scale, which also solves the problem, but makes other parts (walking around with wasd) super slow, since those are scaled too. So it seems the most correct to me to have the falling distance be done in non-scaled space, same as wasd and jump. Here's a diff of a version I've been testing that seems to solve the problem, in source\blender\editors\space_view3d\view3d_navigate_walk.c, from line 1232: ![image.png](https://archive.blender.org/developer/F13697396/image.png) I'm still testing this locally. On a side note, I've been wondering whether it'd be nicer to pull this feature out of the core entirely, and move it to an addon. That way, it would be way easier to debug and make changes, or disable entirely. I'm assuming that by enabling such an addon by default and have it use the same keymap, it shouldn't be a breaking change. Love to hear what you guys think!

Philipp Oeser commented

2022-10-17 10:18:01 +02:00

Thx looking into this.
Mind sharing your fix as a Diff?
See https://wiki.blender.org/wiki/Process/Contributing_Code

Thx looking into this. Mind sharing your fix as a Diff? See https://wiki.blender.org/wiki/Process/Contributing_Code

blender-admin commented

2022-10-21 07:11:07 +02:00

This issue was referenced by a0bbd65d57

This issue was referenced by a0bbd65d57f38344fb71565c3c34396363a4be23

Campbell Barton commented

2022-10-21 07:18:03 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2022-10-21 07:18:03 +02:00

Campbell Barton self-assigned this 2022-10-21 07:18:03 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Walk Teleport and other movements do not take into account the unit scale of the Scene #66713