Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Viewpoint tracking not working #6620

Open
brettle opened this issue Aug 13, 2024 · 6 comments
Open

Viewpoint tracking not working #6620

brettle opened this issue Aug 13, 2024 · 6 comments

Comments

@brettle
Copy link
Contributor

brettle commented Aug 13, 2024

Describe the Bug
Viewpoint tracking does not appear to be working.

Steps to Reproduce

  1. Load viewpoint_test.zip which has Viewpoint.follow set to "robot:camera" and Viewpoint.followType set to "Mounted Shot".
  2. (Optional) Select View > Optional Rendering > Show Camera Frustrums

Expected behavior
The view in the 3d window should be from the perspective of the camera.

Screenshots
Instead, the view looks like this:
viewpoint_test

System

  • Operating System: Fedora Workstation 40
  • Graphics Card: Intel® UHD Graphics 630 (CFL GT2)

Additional context
Running the simulation doesn't seem to have any effect on the issue.

I'm seeing this in R2023b and the current R2024a master.

@brettle
Copy link
Contributor Author

brettle commented Aug 13, 2024

Further investigation reveals that the Viewpoint's perspective is updated after each step, but it is updated relative to the perspective that the Viewpoint had when tracking was initiated. As a result, to get the effect I expected (where the Viewpoint has the same position and rotation as the tracked solid), one needs to copy the translation and rotation fields of the tracked Solid into the position and orientation fields of the Viewpoint and then have the simulation running while you update the translation and rotation fields of the tracked Solid. Is that the way it is supposed to work?

@omichel
Copy link
Member

omichel commented Aug 13, 2024

Yes, that's the way it is supposed to work. It allows setting the viewpoint with some offset with respect to the position and orientation of the robot, which is often useful.

@brettle
Copy link
Contributor Author

brettle commented Aug 13, 2024

I can see how that would be useful, but I think that can be achieved while providing a user experience more inline with what I was expecting. Thoughts on the following possible changes?

  1. When the user initiates tracking, the Viewpoint should be set to the perspective of the tracked object. The user could still modify the viewpoint from there.
  2. Update the viewpoint whenever the tracked object's perspective changes, not just after each timestep. This would allow the user to, for example, manually aim a camera (while seeing what is within its fov) without needing to run the world.

If the current behavior is to be maintained, the associated documentation should probably be made clearer.

@omichel
Copy link
Member

omichel commented Aug 14, 2024

I believe there are use cases where the current behavior is useful. For example, if you watch a soccer game, you want to set the viewpoint to some position and orientation and instruct to follow the ball. You don't want to change the viewpoint that you just set. Generally, changing anything set by the user is usually considered as a bad UX. So, I would not apply your first suggestion. The second one probably makes more sense and could be implemented.

@brettle
Copy link
Contributor Author

brettle commented Aug 14, 2024

I should have been clearer in my description of my first proposal above. I'm proposing that when the user initiates tracking, the Viewpoint should be set as follows:

  1. For "Mounted Shot", the Viewpoint should be set to the perspective of the tracked object. This was the case I was focused on and is the behavior I expected to see.
  2. For "Pan and Tilt" or "Tracking Shot" (one of which is presumably what would be used in your soccer example), the Viewpoint translation should not be changed, but the orientation should change to center the tracked object in the view. (There is an extra "twist" DOF in what the orientation should be. Presumably it should correspond to the world's up axis being vertical in the view.)

To be clear, the above would only occur when the user initiates tracking. Since the user has requested the tracking, I don't see changing the Viewpoint in response as a bad UX. From a UX perspective, this behavior is the one that provides the "least surprise", imo.

To return to your soccer example, if you want to track the ball but not have it centered in the view, it seems easier to first track the ball and then adjust the Viewpoint than it would be to first set the Viewpoint and then track the ball.

@omichel
Copy link
Member

omichel commented Aug 19, 2024

This is difficult for me to evaluate this without being able to actually test it. Maybe you can go ahead with some implementation and we can test it to see if that seems better than the current system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants