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 Aug 28, 2021. It is now read-only.
Because the agent's position and the camera location and orientation are coupled, move_forward has unexpected behavior. If the camera's pitch is non-zero, then the agent will move less than the expected amount in the "forward" direction. It will instead move the amount projected onto the [x, 0, z] vector, which is not unit length if the y is nonzero.
To fix this, there are two options: One, you zero out the y-value and renormalize the vectors, giving the expected magnitude of motion. I have a version that does this, but I haven't set up a clean commit for a pull request. I can do this later if you would like.
Two: you put a comment in the code explaining this behavior as I would argue it is not expected. I would also argue it is not desired, and this solution, while easier, is less useful.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
https://github.com/facebookresearch/House3D/blob/master/House3D/core.py#L196
Because the agent's position and the camera location and orientation are coupled, move_forward has unexpected behavior. If the camera's pitch is non-zero, then the agent will move less than the expected amount in the "forward" direction. It will instead move the amount projected onto the [x, 0, z] vector, which is not unit length if the y is nonzero.
To fix this, there are two options: One, you zero out the y-value and renormalize the vectors, giving the expected magnitude of motion. I have a version that does this, but I haven't set up a clean commit for a pull request. I can do this later if you would like.
Two: you put a comment in the code explaining this behavior as I would argue it is not expected. I would also argue it is not desired, and this solution, while easier, is less useful.
The text was updated successfully, but these errors were encountered: