Low Motion Mode

[ProbablePrime]

Is your feature request related to a problem? Please describe.

We've had some reports that certain parts of our official experiences can cause issues for users with vertigo or epilepsy. Of particular note is the teleporter effect at the end of the tutorial and the "bubble" effect that occurs when loading into the cloud home.

It is difficult to figure out how to turn these off and to make this system expansive for future content.

Describe the solution you'd like

I'll be adding a setting within the initial user experience called "Low Motion Mode"(this term is borrowed from the Web world).

Low Motion Mode when enabled, will signal to a new component that a user has requested low motion mode. This component will then disabled mesh renderers and particles underneath its hierarchy.

Example Hierarchy

• Super Animated Hyper Space JUMP SCARE
  • Low Motion Slot
    • Intense spacey animation (disabled in low motion mode)

The methodology here may seem silly, but it is designed to allow for the following items:

• Opaqueness for other users - it is important that other users cannot see that this mode is enabled or it could become a target for harassment.
• Expandability, while we've only had complaints about our official experience, there are more official experience in our idea bucket. This will also allow people to use it in their own creations.

Describe alternatives you've considered

We did initially consider making this just a general "boolean" setting but this exposes it in a way that could allow it to be targeted for harassment etc. We want to avoid this.

We also considered cloud variables etc.

Additional Context

• This is not a motion blur toggle - You want this issue: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/178. I understand the frustration here, but motion blur issues or comments will be hidden from this thread.
• Yes this is another setting, I have explicit permission from the team to add this setting.

Why now & Why Me?

For those who don't know, I suffer from Epilepsy. I'm lucky that my seizures are not photosensitive but this doesn't mean they aren't seizures. For anyone that has experienced them, they are the single scariest thing I have experienced. Your entire body is suddenly out of your control. I'm also color blind.

So I'm doing this out of personal reasons. I also have a personal passion for accessibility.

Why not other stuff?

I AM WORKING ON OTHER STUFF, this is just one item I'm working on. Imagine a stack of plates that are different shapes, sizes, colors etc. making the best stack of plates can sometimes mean that certain plates "fit" and certain ones do not. This plate fits my stack.

[kulzae]

Is this intended to be a visual stimulus reduction function or ONLY apply to motion. would using this for things like flashing lights be appropriate

[Banane9]

I'm not sure if "obfuscating" the way it works like this necessarily prevents using it to target people. One could built a simple contraption with a camera or color picker node to check whether something under a Low Motion Slot rendered and presto, you know if a user has it enabled or not.

[Frooxius]

It would work if the cameras would not ever respect this setting - it would only affect the primary user view, which you won't be able to sample.

[Banane9]

It would work if the cameras would not ever respect this setting - it would only affect the primary user view, which you won't be able to sample.

While true, I could see this posing issues as well, for example when a camera is used to show a 3rd person view of the scene on a screen, such as in some party worlds like the Rave Cave from HardLight. If the camera view doesn't respect the Low Motion setting, the screen could still show the flashing lights that are supposed to be off.

Alternatively, such a camera system would have to be disabled entirely, which could significantly affect the user experience in some worlds. In particular, I'm thinking of another MMC world, which featured an arcade shooter game (i.e. explosions and flashes) on a large screen, which was created using a camera flying through a scene offset from the player area.

[Frooxius]

The camera that you use for that doesn't let you sample the color though. This would only apply to things where you can actually read-out the result.

E.g. if you have real-time camera in the world that can show flashing lights, you flag it as such. This would do two things:

• Make it respect that setting, so its view does not render flashing lights either
• Either not render in any contexts that can sample the colors - it would become static image and/or black, regardless of the setting

Essentially the way to think about is that the "censoring" happens as close to anything you can use to sample the color/data as possible. That way the user can still see the value in any views that cannot be sampled. If views show something that would leak information, those views cannot be sampled either.

There are limitations, but if preserving the privacy on this setting is important to the user, I don't believe there's a way to do it without the limitations.

[Banane9]

Essentially the way to think about is that the "censoring" happens as close to anything you can use to sample the color/data as possible. That way the user can still see the value in any views that cannot be sampled. If views show something that would leak information, those views cannot be sampled either.

How would you handle taking camera pictures? You could trigger taking a photo with protoflux and then sample the resulting image.

I could also see the renderer-disabling feature being possible to abuse by making use of stencils, so that a material with a stencil that would hide a flashing effect is disabled, making it specifically show for users who enable Low Motion.

Also, to be clear, I'm not vehemently opposed to having it hidden, I'm just trying bring up potential issues so they can be handled from the start. It just seems like something relying on not being abused in either way (though making abuse more complicated may be worthwhile in itself too).

[Frooxius]

@Banane9 Like I mentioned in my post above - stuff that shows the information that can be leaked will not show in the renders that can sample it.

[gentlecolts]

if you have real-time camera in the world that can show flashing lights, you flag it as such

From what I've been reading, this would be a feature a creator would have to explicitly tag on their own creations? If that's correct, I don't know that I like that as a setting. Features like this should be fully client-side and should not rely on trusting the creator to be responsible for (or even aware of) components like this. Imo it would be more preferable to consider features like this for the settings rework, and implement these kinds of safety settings in ways where they cannot be influenced by other users, ex client side limits on particle count/speed/fps, color/texture update rate, capping own-user velocity, etc.

Otherwise, apologies if I'm misunderstanding