feat: disable facial features based on distance to player

[AjimenezDCL]

Fixes #826

How to test

It's easier to test this in Unity. Just lock the editor window to an avatar and either move the avatar away or move yourself away to see how the mouth, eyes and eyebros dissapear.

Test coverage

All of our AvatarShape tests are disabled (it takes too long to load an Avatar) and there's an ongoing effort to first refactor AvatarShape/AvatarRenderer and then implement a proper test suite. Therefore I decided to not waste time on making a test that is going to be disabled.

Implementation details

Instead of checking each time the player or the other avatars change position, I decided to have a routine running and performing the distance calculation.
I was worried of triggering a Distance calculation (expensive) each time (possibly multiple times).

[github-actions]

After the CI passes:

• This branch can be previewed at https://play.decentraland.zone/index.html?renderer=urn:decentraland:off-chain:renderer-artifacts:feat/disable-facial-features-distance
• Code coverage report: https://renderer-artifacts.decentraland.org/branch-coverage/feat/disable-facial-features-distance

[D4rWiNSS]

LGTM with a small request! Not sure if each component should check to show the facial here or have a global controller. Anyway, this looks good!

[D4rWiNSS]

Should we use the CourutineStarter here? Also, we should track the coroutine and clean it in the Cleanup method

[AjimenezDCL]

CoroutineStarter is a "hack" to have coroutines when you dont have Monobehaviours, which is not the case.

Tracking the coroutine is not really needed because they are aborted when the monobehaviour gets disabled (in this case when going back to the pool), but it doesn't hurt to make it explicit. Gonna do it!

[D4rWiNSS]

Cool! As far as I know, we were using CoroutineStarter (Besides de hack of course) because in some situations the coroutines will stay in memory even if the monobehaviour is destroyed. @BrianAmadori can you confirm on this?

[AjimenezDCL]

I created the CoroutineStarter and that was the purpose, to have coroutines non dependant of monobehaviours haha.

Coroutines are parts of the monobehaviours (that's the reason if you have a disabled one you cannot start a coroutine, because the update is never called) and I haven't been able to find anything related to leaks in coroutines.
In fact using the CoroutineStarter can actually lead to some leaks if the coroutine it's never released and the handler gets destroyed.

[AjimenezDCL]

Benchmark

Moving

Zone:
PerformanceMeter - Data report step 2 - Processed values:
 * PERFORMANCE SCORE (0-100) -> 37.63
 * average FPS -> 19.11664
 * highest FPS -> 24
 * lowest FPS -> 12
 * 50 percentile (median) FPS -> 19
 * 95 percentile FPS -> 23
 * total hiccups (>0.05ms frames) -> 330 (56.6% of frames were hiccups)
 * total hiccups time (seconds) -> 18.75877
 * total frames -> 583
 * total frames time (seconds) -> 30.04703

Facial features optimization:
PerformanceMeter - Data report step 2 - Processed values:
 * PERFORMANCE SCORE (0-100) -> 45.95
 * average FPS -> 19.74794
 * highest FPS -> 24
 * lowest FPS -> 11
 * 50 percentile (median) FPS -> 20
 * 95 percentile FPS -> 23
 * total hiccups (>0.05ms frames) -> 249 (41.02% of frames were hiccups)
 * total hiccups time (seconds) -> 13.81271
 * total frames -> 607
 * total frames time (seconds) -> 30.03112

Still

Zone:
PerformanceMeter - Data report step 2 - Processed values:
 * PERFORMANCE SCORE (0-100) -> 30.3
 * average FPS -> 18.63636
 * highest FPS -> 19
 * lowest FPS -> 11
 * 50 percentile (median) FPS -> 19
 * 95 percentile FPS -> 19
 * total hiccups (>0.05ms frames) -> 403 (70.45% of frames were hiccups)
 * total hiccups time (seconds) -> 21.6909
 * total frames -> 572
 * total frames time (seconds) -> 30.04011

Facial features optimization:
PerformanceMeter - Data report step 2 - Processed values:
 * PERFORMANCE SCORE (0-100) -> 58.25
 * average FPS -> 20.21027
 * highest FPS -> 21
 * lowest FPS -> 12
 * 50 percentile (median) FPS -> 20
 * 95 percentile FPS -> 21
 * total hiccups (>0.05ms frames) -> 107 (17.17% of frames were hiccups)
 * total hiccups time (seconds) -> 5.710587
 * total frames -> 623
 * total frames time (seconds) -> 30.03861