Details
-
Bug
-
Resolution: Cannot Reproduce
-
Not Evaluated
-
None
-
6.9.0
-
None
-
Qt Version:
You've specified: 6.9.0
Operating System (OS) and Version:
You need to specify this. Examples:
Windows 10 (Version 22H2, OS Build 19045.xxxx)
Windows 11 (Version 23H2)
macOS Sonoma 14.x
Ubuntu 22.04 LTS
Other Linux distribution (e.g., Fedora 38, Arch Linux)
Development Environment/IDE (if applicable):
You might want to specify this. Examples:
Qt Creator (e.g., Qt Creator 12.0.1)
Visual Studio Code with Qt extensions
Other text editor + command line qmake/cmake
Compiler (if building C++ components or if relevant):
You need to specify this if it's relevant to how you build/run your Qt application. Examples:
MSVC 2019 / 2022 (for Windows)
MinGW (e.g., MinGW 11.2.0 64-bit - for Windows)
GCC (e.g., GCC 11.4.0 - for Linux)
Clang (e.g., Apple Clang version 15.0.0 - for macOS)
If you are purely running QML files with the qml tool or a pre-built Qt, this might be less critical, but the Qt installation itself was built with a specific compiler.
Graphics Hardware and Driver Version (Potentially useful for 3D issues):
This can be helpful but might not be strictly necessary if the bug seems purely logical. Examples:
NVIDIA GeForce RTX 3070 (Driver Version: 535.xx)
AMD Radeon RX 6800 XT (Driver Version: Adrenalin 23.x.x)
Intel Iris Xe Graphics (Driver Version: xx.xx.xxx.xxxx)Qt Version: You've specified: 6.9.0 Operating System (OS) and Version: You need to specify this. Examples: Windows 10 (Version 22H2, OS Build 19045.xxxx) Windows 11 (Version 23H2) macOS Sonoma 14.x Ubuntu 22.04 LTS Other Linux distribution (e.g., Fedora 38, Arch Linux) Development Environment/IDE (if applicable): You might want to specify this. Examples: Qt Creator (e.g., Qt Creator 12.0.1) Visual Studio Code with Qt extensions Other text editor + command line qmake/cmake Compiler (if building C++ components or if relevant): You need to specify this if it's relevant to how you build/run your Qt application. Examples: MSVC 2019 / 2022 (for Windows) MinGW (e.g., MinGW 11.2.0 64-bit - for Windows) GCC (e.g., GCC 11.4.0 - for Linux) Clang (e.g., Apple Clang version 15.0.0 - for macOS) If you are purely running QML files with the qml tool or a pre-built Qt, this might be less critical, but the Qt installation itself was built with a specific compiler. Graphics Hardware and Driver Version (Potentially useful for 3D issues): This can be helpful but might not be strictly necessary if the bug seems purely logical. Examples: NVIDIA GeForce RTX 3070 (Driver Version: 535.xx) AMD Radeon RX 6800 XT (Driver Version: Adrenalin 23.x.x) Intel Iris Xe Graphics (Driver Version: xx.xx.xxx.xxxx)
-
Windows
Description
Qt Version: 6.9.0
Module: Qt Quick 3D
Component: QtQuick3D.Node (specifically its right direction vector property)
Observed Behavior:
The Node.right vector property can exhibit inconsistent behavior by flipping its direction (e.g., its components change sign, like (x, y, z) becoming (-x, -y, -z)) between consecutive reads. This occurs even when the Node's eulerRotation property (and thus its conceptual forward direction) has remained unchanged between these reads.
This issue was identified in a QML context where a Node (representing a camera) had its orientation controlled by eulerRotation. The Node.right vector was used to calculate character strafing movement. When processing distinct input events for "strafe left" and "strafe right" in quick succession (without any change to the camera's eulerRotation between these events), the Node.right vector would sometimes provide a flipped value for the second input. This resulted in both "strafe left" and "strafe right" inputs causing character movement in the same world-space direction, instead of opposite directions.
Expected Behavior:
If a Node's eulerRotation remains constant between two reads of its direction vector properties, the Node.right (as well as Node.forward and Node.up) vectors should also remain consistent and not spontaneously flip their direction.
Steps to Reproduce (Conceptual):
* Create a Node in a Qt Quick 3D scene.
* Set its eulerRotation (e.g., node.eulerRotation = Qt.vector3d(pitch, yaw, 0)).
* In QML JavaScript, read and store node.right (let's call this right_T1).
* Trigger a subsequent event or a very short timer. Ensure node.eulerRotation has not been modified.
* In the handler for this second event/timer, read node.right again (let's call this right_T2).
* Compare right_T1 and right_T2. In problematic cases, right_T2 will be approximately equal to -right_T1.
Impact:
This inconsistency makes the Node.right property unreliable for calculations that depend on stable and predictable direction vectors, such as character movement or aiming logic, especially when the Node's orientation is managed via eulerRotation.
Workaround:
The issue was successfully worked around by manually calculating the camera's forward and right vectors directly from its currentPitchDegrees and currentYawDegrees properties (which were used to set the eulerRotation) using standard trigonometric functions within QML JavaScript. This custom calculation provided stable and consistent direction vectors, bypassing the problematic Node.right property.