Fixed startup.blend default Viewport view tilt #113751

Jonas Holzman · 2023-10-15T22:59:44+02:00

Jonas Holzman commented

2023-10-15 22:59:44 +02:00

Problem Description

This Pull Request addresses a long-standing (since Blender 2.5!) "bug", or UI/UX inconsistency where the default Blender viewport view is tilted by around ~0.8 degrees to the right.

While this issue might seems strange, or even unbelievable to some, you can learn more about it in this archived issue I originally created 2 years ago, which contains more details and videos showcasing the problem, as well as some information about the possible historical source of this problem.

While this inconsistency is minor, here are a few reasons why it should be fixed:

Inconsistency between the Blender default viewport view roll, and the roll it will have after being snapped/aligned to any XYZ axis.
Will affect a user final render if he uses the Align Active Camera to View operator without having aligned his view to an axis first.
General aesthetic issues, as shown in the video in the original issue (Viewport Gizmos being slightly skewed, Cameras not being aligned with the world axis, etc...)
Correctness, if the default viewport view seems to be levelled, it probably should be.

While this issue will probably almost never affect proficient Blender users, who through the use a custom startup.blend and advanced camera setups probably won't encounter this problem, this might affect novice users a lot more, who might rely unknowingly on the fact that the default viewport view seems to be levelled, even though it's not.

Fix / Solution

This new startup.blend was generated on a fresh Blender release build (from commit b6131cc338ab) using the following Python script:

import mathutils
import bpy


# Port of GLM's quatLookAtRH using Blender's mathutils, all input vectors must be normalized.
def quat_lookat_rh(direction: mathutils.Vector, up: mathutils.Vector):
    result = mathutils.Matrix(((0, 0, 0), (0, 0, 0), (0, 0, 0)))
    
    result[2] = -direction
    right = up.cross(result[2])
    result[0] = right * (max(0.0001, right.dot(right)))**(-1/2)
    result[1] = result[2].cross(result[0])
    
    return result.to_quaternion()


def fix_viewport_tilt(area_3d_region: bpy.types.RegionView3D, view_matrix: mathutils.Matrix, target: mathutils.Vector):
    cam_loc, cam_rot, cam_scale = view_matrix.decompose()
    print("Current Camera Rotation:", cam_rot)
        
    # Invert the view matrix to get the position of the camera
    viewport_cam_position = view_matrix.inverted().to_translation()
    
    cam_direction = target - viewport_cam_position
    cam_direction.normalize()
    up_vec = mathutils.Vector((0, 0, 1))

    new_quat = quat_lookat_rh(cam_direction, up_vec)
    new_quat.invert()
    
    print("New Camera Rotation:", new_quat, "\n")

    region.view_rotation = new_quat
    

# This script is meant to be executed in headless mode to generate a new startup.blend
# Loading Factory Settings (default startup.blend)
bpy.ops.wm.read_factory_settings()

# The default viewport cameras always points to the world origin (0, 0, 0) in every workspaces
# Note: Running this script with a viewport camera not targeted towards 0, 0, 0 will cause jumps
cam_target = mathutils.Vector((0, 0, 0))

# For every workspaces, we iterate over their areas, and if we find a 3D viewport we fix its orientation
for workspace in bpy.data.workspaces:
    workspace_areas = workspace.screens[0].areas
    
    for area in workspace_areas:
        # Apply the fix to all workspaces that have a 3D Viewport
        if area.type == 'VIEW_3D':
            print("Fixing 3D Viewport Camera in Workspace:", workspace.name)
            region = area.spaces[0].region_3d
            view_matrix = region.view_matrix
            
            fix_viewport_tilt(region, view_matrix, cam_target)


# We're done, write the new startup.blend
bpy.ops.wm.save_homefile()

This script uses a port of GLM's quatLookAtRH for Blender mathutils to compute a new camera view matrix using the original camera location, the camera direction vector (the inverse of its location since we're always targeting (0, 0, 0) and the up vector. The resulting function is then applied to every viewport area present in the startup.blend file by iterating over the workspaces it contains.

This script is then ran using Blender in headless mode using a custom empty config directory to which Blender outputs the resulting modified startup.blend using the following command:
BLENDER_USER_CONFIG=./output <path_to_blender>/blender -b --python ./viewport_tilt_fix.py

Note: Thanks @HooglyBoogly for the heads up in commit b646846646 that only Release builds should be used when modifying the startup.blend file to prevent overriding other settings

Before/After gif

Also see the original report for videos better showcasing the original issue

Possible shortcomings of this solution

The method used to apply the fix (Using a Python script ran in headless mode with a custom config directory) seems to be the simplest and most elegant one, but regarding the actual fix, there exist other ways to solve this problem, such as:

Setting a Camera to the active view, using constraints to level it, setting the view to the camera, then deleting it.
Pre-computing rotational value and applying them (non-replicable and needs to be pre-computed for different workspaces)
Other Linear Algebra techniques, like directly modifying the quaternion extracted from the Camera view matrix for example.

After trying variants of the aforementioned methods, the one that seemed to work best and give the most precise result was the GLM quatLookAtRH mathutils port I ended up using, but there are definitely other ways to solve this problem.

## Problem Description This Pull Request addresses a long-standing (since Blender 2.5!) "bug", or UI/UX inconsistency where the default Blender viewport view is tilted by around ~0.8 degrees to the right. While this issue might seems strange, or even unbelievable to some, you can learn more about it in [this archived issue](https://archive.blender.org/developer/T86325) I originally created 2 years ago, which contains more details and videos showcasing the problem, as well as some information about the possible historical source of this problem. While this inconsistency is minor, here are a few reasons why it should be fixed: - Inconsistency between the Blender default viewport view roll, and the roll it will have after being snapped/aligned to any XYZ axis. - Will affect a user final render if he uses the `Align Active Camera to View` operator without having aligned his view to an axis first. - General aesthetic issues, as shown in [the video in the original issue](https://archive.blender.org/developer/T86325) (Viewport Gizmos being slightly skewed, Cameras not being aligned with the world axis, etc...) - Correctness, if the default viewport view seems to be levelled, it probably should be. While this issue will probably almost never affect proficient Blender users, who through the use a custom startup.blend and advanced camera setups probably won't encounter this problem, this might affect novice users a lot more, who might rely unknowingly on the fact that the default viewport view seems to be levelled, even though it's not. ## Fix / Solution This new startup.blend was generated on a fresh Blender release build (from commit `b6131cc338ab`) using the following Python script: ```py import mathutils import bpy # Port of GLM's quatLookAtRH using Blender's mathutils, all input vectors must be normalized. def quat_lookat_rh(direction: mathutils.Vector, up: mathutils.Vector): result = mathutils.Matrix(((0, 0, 0), (0, 0, 0), (0, 0, 0))) result[2] = -direction right = up.cross(result[2]) result[0] = right * (max(0.0001, right.dot(right)))**(-1/2) result[1] = result[2].cross(result[0]) return result.to_quaternion() def fix_viewport_tilt(area_3d_region: bpy.types.RegionView3D, view_matrix: mathutils.Matrix, target: mathutils.Vector): cam_loc, cam_rot, cam_scale = view_matrix.decompose() print("Current Camera Rotation:", cam_rot) # Invert the view matrix to get the position of the camera viewport_cam_position = view_matrix.inverted().to_translation() cam_direction = target - viewport_cam_position cam_direction.normalize() up_vec = mathutils.Vector((0, 0, 1)) new_quat = quat_lookat_rh(cam_direction, up_vec) new_quat.invert() print("New Camera Rotation:", new_quat, "\n") region.view_rotation = new_quat # This script is meant to be executed in headless mode to generate a new startup.blend # Loading Factory Settings (default startup.blend) bpy.ops.wm.read_factory_settings() # The default viewport cameras always points to the world origin (0, 0, 0) in every workspaces # Note: Running this script with a viewport camera not targeted towards 0, 0, 0 will cause jumps cam_target = mathutils.Vector((0, 0, 0)) # For every workspaces, we iterate over their areas, and if we find a 3D viewport we fix its orientation for workspace in bpy.data.workspaces: workspace_areas = workspace.screens[0].areas for area in workspace_areas: # Apply the fix to all workspaces that have a 3D Viewport if area.type == 'VIEW_3D': print("Fixing 3D Viewport Camera in Workspace:", workspace.name) region = area.spaces[0].region_3d view_matrix = region.view_matrix fix_viewport_tilt(region, view_matrix, cam_target) # We're done, write the new startup.blend bpy.ops.wm.save_homefile() ``` This script uses a port of GLM's quatLookAtRH for Blender mathutils to compute a new camera view matrix using the original camera location, the camera direction vector (the inverse of its location since we're always targeting `(0, 0, 0)` and the up vector. The resulting function is then applied to every viewport area present in the startup.blend file by iterating over the workspaces it contains. This script is then ran using Blender in headless mode using a custom empty config directory to which Blender outputs the resulting modified startup.blend using the following command: `BLENDER_USER_CONFIG=./output <path_to_blender>/blender -b --python ./viewport_tilt_fix.py` *Note: Thanks @HooglyBoogly for the heads up in commit [b646846646](https://projects.blender.org/blender/blender/commit/b646846646c2adfe38a585f024f34ff388e221b8) that only Release builds should be used when modifying the startup.blend file to prevent overriding other settings* ### Before/After gif ![viewport-before-after.gif](/attachments/0afac794-bb8d-4d6c-9ab1-2e01e21c2cab) *Also see [the original report](https://archive.blender.org/developer/T86325) for videos better showcasing the original issue* ## Possible shortcomings of this solution The method used to apply the fix (Using a Python script ran in headless mode with a custom config directory) seems to be the simplest and most elegant one, but regarding the actual fix, there exist other ways to solve this problem, such as: - Setting a Camera to the active view, using constraints to level it, setting the view to the camera, then deleting it. - Pre-computing rotational value and applying them (non-replicable and needs to be pre-computed for different workspaces) - Other Linear Algebra techniques, like directly modifying the quaternion extracted from the Camera view matrix for example. After trying variants of the aforementioned methods, the one that seemed to work best and give the most precise result was the GLM quatLookAtRH mathutils port I ended up using, but there are definitely other ways to solve this problem.

viewport-before-after.gif

413 KiB

👍 6 👀 2

Jonas Holzman added 1 commit 2023-10-15 23:00:03 +02:00

188cc27fcf Fixed startup.blend Viewport tilt

This commit fixes a long-standing (since Blender 2.5!) "bug", or UI
inconsistency where the default Blender viewport view is tilted ~0.8
degrees to the right.

This new startup.blend was generated on a fresh Blender release build
(b6131cc338) using a Python script.

See the PR for the script, command used, and more details.

Jonas Holzman changed title from ~~Fixed startup.blend Viewport tilt~~ to Fixed startup.blend default Viewport view tilt

2023-10-15 23:02:39 +02:00

Harley Acheson added this to the User Interface project 2023-10-15 23:16:10 +02:00

Jonas Holzman commented

2023-10-15 23:23:21 +02:00

Pinging @ideasman42 @JulianEisel @brecht @pablovazquez as potential reviewers.

Jonas Holzman changed title from ~~Fixed startup.blend default Viewport view tilt~~ to WIP: Fixed startup.blend default Viewport view tilt

2023-10-15 23:28:07 +02:00

Campbell Barton requested changes 2023-10-16 03:46:35 +02:00

Campbell Barton left a comment

This should be corrected by versioning code in source/blender/blenloader/intern/versioning_defaults.cc see: blo_update_defaults_screen.

This should be corrected by versioning code in `source/blender/blenloader/intern/versioning_defaults.cc` see: `blo_update_defaults_screen`.

Jonas Holzman added 3 commits 2023-11-05 23:42:32 +01:00

6c93a8cabc Revert "Fixed startup.blend Viewport tilt"

This reverts commit 188cc27fcf.

77d6c00036 Merge remote-tracking branch 'origin/main' into viewport-tilt-fix

e8966574e3 Correct the default viewport camera rotation using versioning code

Jonas Holzman commented

2023-11-05 23:46:25 +01:00

This should be corrected by versioning code in source/blender/blenloader/intern/versioning_defaults.cc see: blo_update_defaults_screen.

Right! This indeed makes more sense and is way cleaner. I've reverted the startup.blend commit and implemented the corresponding versioning code instead. Let me know what you think.

> This should be corrected by versioning code in `source/blender/blenloader/intern/versioning_defaults.cc` see: `blo_update_defaults_screen`. Right! This indeed makes more sense and is way cleaner. I've reverted the `startup.blend` commit and implemented the corresponding versioning code instead. Let me know what you think.

Jonas Holzman requested review from Campbell Barton 2023-11-05 23:46:36 +01:00

Campbell Barton requested changes 2023-11-06 00:01:05 +01:00

Campbell Barton left a comment

Thinking on this further, I rather use a replacement table for versioning, since differences in floating point math between systems shouldn't result in a different users startup.blend.

This means loading the starup.blend, printing values before/after correction. Then adding the values with a significant differences to a lookup table, double checking they apply properly.

Previous comment:

Much better, some requests...

Move this logic to a reusable function ED_view3d_clear_horizon_tilt(..)

Don't assume the target is (0, 0, 0), see RegionView3D::ofs.

Don't rely on rv3d->viewinv, as the rv3d->viewquat is where the rotation is stored, rv3d->viewinv is run-time data which could get out of sync.

Note in code-comments the function is used in versioning code and can't assume run-time members to be updated.

Call this function from versioning instead of in-lining the logic.

Thinking on this further, I rather use a replacement table for versioning, since differences in floating point math between systems shouldn't result in a different users `startup.blend`. This means loading the `starup.blend`, printing values before/after correction. Then adding the values with a significant differences to a lookup table, double checking they apply properly. ---- Previous comment: > Much better, some requests... > > - Move this logic to a reusable function `ED_view3d_clear_horizon_tilt(..)` > - Don't assume the target is (0, 0, 0), see `RegionView3D::ofs`. > - Don't rely on `rv3d->viewinv`, as the `rv3d->viewquat` is where the rotation is stored, `rv3d->viewinv` is run-time data which could get out of sync. > - Note in code-comments the function is used in versioning code and can't assume run-time members to be updated. > - Call this function from versioning instead of in-lining the logic.

Jonas Holzman added 2 commits 2023-12-17 23:13:59 +01:00

de86250adc Merge branch 'main' into viewport-tilt-fix

0fa4fbf647 Viewport Tilt Fix: Implemented Requested Changes

Jonas Holzman commented

2023-12-17 23:44:57 +01:00

@ideasman42 I implemented your requested changes, except for the floating-point math lookup/replacement tables on which I need a little more details. I took the opportunity to add a quaternion lookat function to the broader math_rotation.c library, let me know what you think.

Regarding the floating point lookup tables, they are indeed a necessity, but I'm not quite sure I understand the way you want them to be implemented.

This means loading the starup.blend, printing values before/after correction. Then adding the values with a significant differences to a lookup table, double checking they apply properly

Would this be more about building and using a levelled camera quaternion lookup table? Or more about filling and using a replacement table to identify viewport cameras whose resulting quaternion values are close to each other in the same startup.blend and make sure they get the same values? Or perhaps a mix of both?

@ideasman42 I implemented your requested changes, except for the floating-point math lookup/replacement tables on which I need a little more details. I took the opportunity to add a quaternion lookat function to the broader `math_rotation.c` library, let me know what you think. Regarding the floating point lookup tables, they are indeed a necessity, but I'm not quite sure I understand the way you want them to be implemented. >This means loading the starup.blend, printing values before/after correction. Then adding the values with a significant differences to a lookup table, double checking they apply properly Would this be more about building and using a levelled camera quaternion lookup table? Or more about filling and using a replacement table to identify viewport cameras whose resulting quaternion values are close to each other in the same `startup.blend` and make sure they get the same values? Or perhaps a mix of both?

Jonas Holzman requested review from Campbell Barton 2023-12-18 06:57:06 +01:00

Campbell Barton commented

2024-02-22 22:40:41 +01:00

Regarding lookups I was thinking of something like this:

float quat_replacement_table[][2][4] = {
    {{..from values..}, {..to values..}},
    {{..from values..}, {..to values..}},
};
/* Apply the replacement this to all RegionView3D's in the startup blend file. */

This can all be done in source/blender/blenloader/intern/versioning_defaults.cc.

Regarding lookups I was thinking of something like this: ``` float quat_replacement_table[][2][4] = { {{..from values..}, {..to values..}}, {{..from values..}, {..to values..}}, }; /* Apply the replacement this to all RegionView3D's in the startup blend file. */ ``` This can all be done in `source/blender/blenloader/intern/versioning_defaults.cc`.

Jonas Holzman added 1 commit 2024-03-21 20:55:06 +01:00

5411f698bb Merge branch 'main' into viewport-tilt-fix

# Conflicts:
#	source/blender/blenloader/intern/versioning_defaults.cc

Jonas Holzman force-pushed viewport-tilt-fix from c7a4fc5973 to 5b97af4a57

2024-03-21 21:20:18 +01:00

Compare

Jonas Holzman force-pushed viewport-tilt-fix from 5b97af4a57 to 467d2f8295

2024-03-21 21:23:17 +01:00

Compare

Jonas Holzman force-pushed viewport-tilt-fix from 467d2f8295 to 3c7a0cb960

2024-03-22 12:02:20 +01:00

Compare

Jonas Holzman force-pushed viewport-tilt-fix from 3c7a0cb960 to de3fa3cc66

2024-03-23 14:51:14 +01:00

Compare

Jonas Holzman force-pushed viewport-tilt-fix from de3fa3cc66 to 4a8b9461b1

2024-03-23 16:09:51 +01:00

Compare

Jonas Holzman force-pushed viewport-tilt-fix from 4a8b9461b1 to 00f857d3b9

2024-03-23 23:03:55 +01:00

Compare

Jonas Holzman commented

2024-03-24 00:33:36 +01:00

This is the before/after comparaison data used to create the LUT, printed out in hexadecimal floating-point format:

Versioning workspace: Animation
Original Quaternion: {0x1.8f9b6cp-1, -0x1.ef2414p-2, -0x1.ab6ccep-3, -0x1.58f4ep-2}
Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0}
New Quaternion: {0x1.8f9b6cp-1, -0x1.ef2414p-2, -0x1.ab6cd2p-3, -0x1.58f4ep-2}

Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2}
Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0}
New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2}

Versioning workspace: Compositing
Versioning workspace: Geometry Nodes
Original Quaternion: {0x1.6e7cb6p-1, -0x1.c17476p-2, -0x1.2997dep-2, -0x1.d5d80cp-2}
Orbit Pivot: {0x1.afc5p-4, -0x1.7d68p-5, 0x1.d618p-5}
New Quaternion: {0x1.6cbc86p-1, -0x1.c3a5c8p-2, -0x1.26413ep-2, -0x1.db430ep-2}

Versioning workspace: Layout
Original Quaternion: {0x1.6e7cb8p-1, -0x1.c17478p-2, -0x1.2997dcp-2, -0x1.d5d80cp-2}
Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0}
New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c8p-2, -0x1.26413ep-2, -0x1.db430ap-2}

Versioning workspace: Modeling
Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2}
Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0}
New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2}

Versioning workspace: Rendering
Versioning workspace: Scripting
Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2}
Orbit Pivot: {0x1.87bbf2p-1, -0x1.79a30ap-2, -0x1.b45f3ap+0}
New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2}

Versioning workspace: Sculpting
Original Quaternion: {0x1.885b28p-1, -0x1.2d10cp-1, -0x1.42ae54p-3, -0x1.a486a2p-3}
Orbit Pivot: {-0x1p-24, 0x1p-23, -0x0p+0}
New Quaternion: {0x1.885b24p-1, -0x1.2d10cp-1, -0x1.42ae52p-3, -0x1.a486ap-3}

Versioning workspace: Shading
Original Quaternion: {0x1.71e61ap-1, -0x1.eaf406p-2, -0x1.1a1454p-2, -0x1.a90e0ap-2}
Orbit Pivot: {0x1.0d6e76p-3, -0x1.a25278p-2, -0x1.3de4d2p+0}
New Quaternion: {0x1.71e61ep-1, -0x1.eaf4p-2, -0x1.1a146p-2, -0x1.a90dfap-2}

Versioning workspace: Texture Paint
Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2}
Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0}
New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2}

Versioning workspace: UV Editing
Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2}
Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0}
New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2}

Note: If you want to print this out on your own build of Blender to verify it, you can pull the commit a07ab99e1c from this PR's branch.

In this data, we can see that a lot of viewports end up having values that are very close to each other, basically having the same viewpoint. The UV Editing, Texture Paint, Animation, Scripting and Modeling workspaces have the same original quaternions, and the Layout and Geometry Nodes workspaces are really close. I thus took the opportunity to "unify" them under one unique corrected quaternion, which I chose to be the one of the Layout, due to it being the default workspace.

We can also see that the Geometry Nodes and Sculpting workspaces both have a very close to 0 pivot point offset. In an effort to clean up these values, and to also uniformize the Geometry Nodes workspace with the other workspaces as stated above, I added logic to clear out these values to 0.

I've also left the viewport of the Shading, Sculpting and the first viewport of the Animation workspace as-is due to them being already leveled.

This went through quite a few iterations, from using a simple float[][2][4] table, to using a full blown blender::Map with the workspace names as keys to handle all sorts of edge cases. In the end, I managed to simplify it down to using two simple float[][4] quaternion lists, one being the list of viewports to correct to the unified quaternion, and the other the list of viewports to clear the pivot point offset of.

You'll find this new LUT implementation in the last commit of this branch, which has been soft-reseted to main to keep its previous history. Tell me if this solving strategy looks good to you, and if so, I'll update the PR description with it.

This is the before/after comparaison data used to create the LUT, printed out in hexadecimal floating-point format: ``` Versioning workspace: Animation Original Quaternion: {0x1.8f9b6cp-1, -0x1.ef2414p-2, -0x1.ab6ccep-3, -0x1.58f4ep-2} Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0} New Quaternion: {0x1.8f9b6cp-1, -0x1.ef2414p-2, -0x1.ab6cd2p-3, -0x1.58f4ep-2} Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2} Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0} New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2} Versioning workspace: Compositing Versioning workspace: Geometry Nodes Original Quaternion: {0x1.6e7cb6p-1, -0x1.c17476p-2, -0x1.2997dep-2, -0x1.d5d80cp-2} Orbit Pivot: {0x1.afc5p-4, -0x1.7d68p-5, 0x1.d618p-5} New Quaternion: {0x1.6cbc86p-1, -0x1.c3a5c8p-2, -0x1.26413ep-2, -0x1.db430ep-2} Versioning workspace: Layout Original Quaternion: {0x1.6e7cb8p-1, -0x1.c17478p-2, -0x1.2997dcp-2, -0x1.d5d80cp-2} Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0} New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c8p-2, -0x1.26413ep-2, -0x1.db430ap-2} Versioning workspace: Modeling Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2} Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0} New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2} Versioning workspace: Rendering Versioning workspace: Scripting Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2} Orbit Pivot: {0x1.87bbf2p-1, -0x1.79a30ap-2, -0x1.b45f3ap+0} New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2} Versioning workspace: Sculpting Original Quaternion: {0x1.885b28p-1, -0x1.2d10cp-1, -0x1.42ae54p-3, -0x1.a486a2p-3} Orbit Pivot: {-0x1p-24, 0x1p-23, -0x0p+0} New Quaternion: {0x1.885b24p-1, -0x1.2d10cp-1, -0x1.42ae52p-3, -0x1.a486ap-3} Versioning workspace: Shading Original Quaternion: {0x1.71e61ap-1, -0x1.eaf406p-2, -0x1.1a1454p-2, -0x1.a90e0ap-2} Orbit Pivot: {0x1.0d6e76p-3, -0x1.a25278p-2, -0x1.3de4d2p+0} New Quaternion: {0x1.71e61ep-1, -0x1.eaf4p-2, -0x1.1a146p-2, -0x1.a90dfap-2} Versioning workspace: Texture Paint Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2} Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0} New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2} Versioning workspace: UV Editing Original Quaternion: {0x1.6e7cb8p-1, -0x1.c1747p-2, -0x1.2997dap-2, -0x1.d5d806p-2} Orbit Pivot: {0x0p+0, 0x0p+0, 0x0p+0} New Quaternion: {0x1.6cbc88p-1, -0x1.c3a5c6p-2, -0x1.264138p-2, -0x1.db4312p-2} ``` *Note: If you want to print this out on your own build of Blender to verify it, you can pull the commit a07ab99e1c from this PR's branch.* In this data, we can see that a lot of viewports end up having values that are very close to each other, basically having the same viewpoint. The UV Editing, Texture Paint, Animation, Scripting and Modeling workspaces have the same original quaternions, and the Layout and Geometry Nodes workspaces are really close. I thus took the opportunity to "unify" them under one unique corrected quaternion, which I chose to be the one of the Layout, due to it being the default workspace. We can also see that the Geometry Nodes and Sculpting workspaces both have a very close to 0 pivot point offset. In an effort to clean up these values, and to also uniformize the Geometry Nodes workspace with the other workspaces as stated above, I added logic to clear out these values to 0. I've also left the viewport of the Shading, Sculpting and the first viewport of the Animation workspace as-is due to them being already leveled. This went through quite a few iterations, from using a simple `float[][2][4]` table, to using a full blown `blender::Map` with the workspace names as keys to handle all sorts of edge cases. In the end, I managed to simplify it down to using two simple `float[][4]` quaternion lists, one being the list of viewports to correct to the unified quaternion, and the other the list of viewports to clear the pivot point offset of. You'll find this new LUT implementation in the last commit of this branch, which has been soft-reseted to main to keep its previous history. Tell me if this solving strategy looks good to you, and if so, I'll update the PR description with it.

Jonas Holzman force-pushed viewport-tilt-fix from 7b5b5f19f2 to 0b0df93741

2024-03-24 00:47:37 +01:00

Compare

Jonas Holzman force-pushed viewport-tilt-fix from 0b0df93741 to af62161dbe

2024-03-24 10:19:30 +01:00

Compare

Campbell Barton commented

2024-03-27 06:35:51 +01:00

@blender-bot build

Campbell Barton referenced this issue from a commit

2024-03-27 07:13:42 +01:00

Fix #86325: tilted viewport orientation in default startup

Campbell Barton changed title from ~~WIP: Fixed startup.blend default Viewport view tilt~~ to Fixed startup.blend default Viewport view tilt

2024-03-27 07:13:50 +01:00

Campbell Barton commented

2024-03-27 07:14:40 +01:00

Thanks, committed 913acaf395, closing.

Thanks, committed 913acaf395df1f38e47520027b2b3433dfaa77e1, closing.

Campbell Barton closed this pull request

2024-03-27 07:14:45 +01:00

buildbot/vexp-code-patch-lint Build done.

Details

buildbot/vexp-code-patch-linux-x86_64 Build done.

Details

buildbot/vexp-code-patch-darwin-x86_64 Build done.

Details

buildbot/vexp-code-patch-darwin-arm64 Build done.

Details

buildbot/vexp-code-patch-windows-amd64 Build done.

Details

buildbot/vexp-code-patch-coordinator Build done.

Details

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Fixed startup.blend default Viewport view tilt #113751

Problem Description

Fix / Solution

Before/After gif

Possible shortcomings of this solution

Pull request closed