Floater that shows a compass, adds ability to face towards nearest avatar or given cardinal point

[chanayane]

… as well as some context menu items in minimap, nearby avatars and avatars to face towards a given avatar.

What for?

• Aligning two avatars perfectly for dancing, hugging... I think just for this it will be appreciated.
• Role playing as an adventurer with the compass
• Fine tuning your avatar rotation to your liking, for adjusting rotation in an animation for example.

The compass floater has a full and mini mode. Mini is tiny and won't take too much screen space. Full has more rotation buttons and a larger more detailed compass.

Clicking on the compass will rotate you on the clicked bearing to the nearest 45° slice.
Clicking on the center of the compass will have you facing towards the nearest avatar.

Context menu entries have been added to face towards any avatar.

For convenience two commands buttons have been added: toggling the compass floater on and off, and facing towards the nearest avatar.

Here are a few pictures of what it looks like:

Note about the feature to face towards the nearest avatar or a given avatar:
For two avatars to be facing perfectly, it will require both avatars to face towards each other.

What it does when you face towards another avatar:

1. It rotates your avatar directly towards the other avatar, locally, and sends that new rotation to the server.
2. It rotates the other avatar to its server rotation, locally in your viewer

For best results and due to how local avatar rotation can be different from the server avatar rotation on both viewers, it's best to do the following:

1. You click align
2. Other person clicks align
3. You click align again.

Here's why:

1. First avatar clicks align. The avatar is aligned locally in your viewer to the other avatar. Other avatar is rotated to its server-rotation value in your viewer. But on the other avatar's viewer, you might not be rotated correctly yet. At this point, only yourself is aligned towards the other avatar in your viewer.
2. Second avatar clicks align. It aligns the second avatar to yourself on the second avatar's viewer, and it now shows your avatar correctly aligned on the second avatar's viewer. But at this point, the other avatar's rotation can still look wrong on your viewer, because updating server rotation does not necessarily update the local rotation on other people's viewers! But at this point, for the server, both avatars are correctly rotated.
3. So you click a second time on that button, now, on both viewers, the two avatars are perfectly aligned! :-)

Firestorm Pull Request Checklist

Thank you for contributing to the Phoenix Firestorm Project.
We will endeavour to review you changes and accept/reject/request changes as soon as possible.
Please read and follow the Firestorm Pull Request Guidelines to reduce the likelihood that we need to ask for "Bureaucratic" changes to make the code comply with our workflows.

[beqjanus]

Hi @chanayane
Please amend the copyright and the comment tags to Firestorm rather than AyaneStorm. I don't want to set precedents for randomly tagging with personal viewer names.

Biggest concern: If I read this correctly, the snapRemoteAvatarBody() locally rotates the remote avatar to face you. While I totally understand the intention here, as there is no permission request (as would be the case with a HUD-based solution) this is not a feature we can allow, as it opens the door to potential abuse and AR-griefing (where a local scene is manipulated to submit a report that is not visually representative of the shared view). This is basically the same limitation we faced with the poser functionality; we're looking into solutions for that, so it may be that both services can share it later. For the time being, the remote avatar manipulation needs to be removed.)

Removing the remote avatar manipulation also removes the remote avatar isFlying check, which seems extremely inefficient (given the loop over all running animations and the fact it is called inside a loop over all nearby avatars). I think it also means that mTargetAvatar is no longer used.

Apart from that I wonder whether the drawCompass would be better refactored to take isMiniMode checks out of it , allowing you to pass the magic numbers for sizes in separately and potentially having it more data driven and less hard-coded. I'm not insisting on that change. It is just a thought with a view to future maintenance and whether embedding sizes into the code like that is unnecessarily fragile

[chanayane]

Nevermind, closing it then. Thank you for taking the time to review it Beq.

[chanayane]

Reopening after explaining that this does not change the other avatar's server rotation, only syncing other avatar's local rotation to its server rotation.

[chanayane]

I reworked this a little:

• fixed copyright
• added comments
• removed isAvatarFlying check completely
• making sure we sync other avatar local rotation to exactly the server one, not applying any correction
• building a CompassLayout outside of drawCompass for easier maintenance

[chanayane]

• Fixed tags