View matrix and Inverse View matrix mixed up.

[cshenton]

Bevy version

12.0

Problem

The naming of the view and inverse_view matrices in the View struct are the opposite of what those names mean everywhere else.

A view matrix transforms from world to view space. The "view matrix" in the View struct transforms from view to world space.

bevy/crates/bevy_render/src/view/mod.rs

Line 381 in a4c2728

let view = camera.transform.compute_matrix();

[JMS55]

Duplicate of #8492

[cshenton]

That is an issue discussing alternative naming conventions. It does not cover the fact that there is an error in the existing names. view and inverse_view mean the opposite thing in Bevy than they do in every other renderer.

[JMS55]

@superdump wrote it like this for some reason, I don't know the rationale. I'll leave it up to him to determine if this is a duplicate or not.

[cshenton]

Quick summary of places with the widely accepted convention that view == world_to_camera (i.e. not Bevy's convention)

Engines

• Unity: https://docs.unity3d.com/ScriptReference/Camera-worldToCameraMatrix.html
• Unreal: https://docs.unrealengine.com/4.27/en-US/API/Runtime/Core/Math/FLookFromMatrix/__ctor/
• Godot: https://github.com/godotengine/godot/blob/a311a4b162364d032b03ddf2a0e603ba40615ad7/drivers/gles3/shaders/scene.glsl#L412
• Stride: https://github.com/stride3d/stride/blob/35bb959b83ea37518abe003c440f184e2e55ef40/sources/engine/Stride.Engine/Engine/CameraComponent.cs#L253
• Flax: https://github.com/FlaxEngine/FlaxEngine/blob/526edb83de5a427daf787025e5334dead5ecd2cf/Source/Engine/Core/Math/Viewport.cs#L263

Libraries

• GLM: https://github.com/g-truc/glm/blob/586a402397dd35d66d7a079049856d1e2cbab300/glm/ext/matrix_transform.hpp#L125
• DirectXMath: https://github.com/microsoft/DirectXMath/blob/a4f6d7bd7897858e1bcedbd7d2127cc151b257b2/Inc/DirectXMathMatrix.inl#L2178
• Apple ARKIt: https://developer.apple.com/documentation/arkit/arcamera/2921672-viewmatrix

Gfx tutorials/docs

• LearnOpenGL: https://learnopengl.com/Getting-started/Camera
• Vulkan Tutorial: https://vulkan-tutorial.com/Uniform_buffers/Descriptor_layout_and_buffer
• DX9 Docs: https://learn.microsoft.com/en-us/windows/win32/direct3d9/view-transform
• 3DGEP: https://www.3dgep.com/understanding-the-view-matrix/

I could go on...

tl;dr: the convention in Bevy runs counter to the overwhelming majority of existing gfx tutorials, libraries, and engines. I can't find a single example that agrees with Bevy's convention.

IMO this is a major bug

[DGriffin91]

I've also always found this odd. We should try to match the industry conventions soon than later. This is not a duplicate of #8492 And this issue should not be closed.

[superdump]

This has been discussed elsewhere. It isn't a duplicate of #8492, and I think we should resolve it by implementing #8492. I had done this, but I didn't want to disrupt @DGriffin91 's helper implementations.

[superdump]

I haven't thoroughly checked all of the links. Foundations of Game Engine Development 2, Rendering by Eric Lengyel uses the inverse camera matrix to transform from 'world' to 'camera' space. That uses a right-side multiplication of matrices convention. I don't remember where I originally saw the argument about "if you have a camera in space, looking into a scene, and you rotate the camera to anti-clockwise about its up axis, what happens visually to the objects the camera sees? They rotate about the camera position along the camera's up axis, but clockwise".

Not that it matters other than for trying to understand where it came from in Bevy, but I'm not certain I was the one who originally wrote this, but I feel I have understood it since, and there were definitely references.

I think to take the project forward without wasting people's time discussing whether view or inverse view is necessarily correct, we were anyway intending to do #8492 and this issue mostly suggests to me that we should either avoid referring to the 'view' matrix at all in documentation or anywhere. If we have to, we can discuss it, but maybe we could try this approach first?