You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 29, 2022. It is now read-only.
The screenshot above was taken by using CodeLLDB and stepping through the execution of Rust code.
As you can see, pre-normalization the ray vector is about (12, 15, -98) which is actually a unit vector with its magnitude x100. That means we'd expect the normalized vector to be around (0.12, 0.15, -0.98)
After normalization (assigned to direction) the vector is (-0.98, 0, 0).
The -0.98 value placed in the x scalar slot should be placed in the z scalar slot, and the x and y scalars are not present at all.
Now, CodeLLDB isn't perfect, it may not be mapping the memory values correctly, so this may essentially be a visual bug with the debugger.
However, I am experiencing a bug where I'm casting a ray through some collider shapes, and the ray cast always returns None, even when I confirm the start and ray vectors would correctly cause the ray to pass through the location of the collider shapes.
The vector normalization misalignment is the best lead I have so far.
For the sake of completeness,, I've attached below a copy a post I made asking for help in the Bevy Discord server. If there's an obvious bug there that would cause the raycast to not detect the collision shapes, then I think it's reasonable to chalk up the erroneous vector normalization to a debugger memory layout bug.
However, if the attached code looks correct, then as above, this vector normalization bug is the best lead I have for a root cause.
The normalization code looks generated, possibly based on system architecture, so I'll mention I'm on Windows 10 with an intel i7-6700K CPU and an NVidia GTX 1080 GPU. More information available upon request if it seems relevant.
Popping in to say upon further investigation, it looks like the vector alignment issue is actually a debugger display issue. Logging the value (by forking Heron) provides correct values.
I'm still unable to get my rays to collide with collision shapes, and I'm not confident that the bug lies in heron, but I'll leave this issue open in case someone gets the chance to double-check my help code.
I'll update the issue accordingly.
Riizade
changed the title
Possible Issue with Raycasting due to Vector Normalization Bug
Possible Issue with Raycasting
Jul 20, 2022
The screenshot above was taken by using CodeLLDB and stepping through the execution of Rust code.As you can see, pre-normalization theray
vector is about(12, 15, -98)
which is actually a unit vector with its magnitude x100.That means we'd expect the normalized vector to be around(0.12, 0.15, -0.98)
After normalization (assigned todirection
) the vector is(-0.98, 0, 0)
.The-0.98
value placed in the x scalar slot should be placed in the z scalar slot, and the x and y scalars are not present at all.Now, CodeLLDB isn't perfect, it may not be mapping the memory values correctly, so this may essentially be a visual bug with the debugger.However, I am experiencing a bug where I'm casting a ray through some collider shapes, and the ray cast always returnsNone
, even when I confirm thestart
andray
vectors would correctly cause the ray to pass through the location of the collider shapes.The vector normalization misalignment is the best lead I have so far.For the sake of completeness,, I've attached below a copy a post I made asking for help in the Bevy Discord server. If there's an obvious bug there that would cause the raycast to not detect the collision shapes, then I think it's reasonable to chalk up the erroneous vector normalization to a debugger memory layout bug.
However, if the attached code looks correct, then as above, this vector normalization bug is the best lead I have for a root cause.
help.md
The text was updated successfully, but these errors were encountered: