Resonite-Issues
Resonite-Issues copied to clipboard
Yellow-Dog-Man
Low Motion Mode
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)
- Low Motion Slot
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.
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
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.
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.
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.
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.
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).
@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.
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
@gentlecolts
- This setting is fully client side. The only thing transmitted between users is the component described.
- This feature must be manually enabled on all User Generated Content
- This feature will be fully supported by anything Team created.
- a disclaimer will state that while we can encourage the use of this on User Generated Content we cannot ensure it is used on all user generated content.
There's also some additional details about how this might affect other settings here: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2163
Thank you for all the questions, and apologies that this one is taking a long time. I keep having to move my focus off of it.
This is a really cool idea that I really like. Having a simple component that people I hang out with regularly could drop onto their flashy avatar stuff would make a world of difference in accessibility.
Another "motion" issue I commonly face is shifting or audio-reactive emissive textures. Is there an avenue where this setting could be used to control or limit those?
This particular proposal / implementation primarily focuses on and is scoped to user-authored content, as well as official experiences (the tutorial, etc.) @Ryn-Fox - it would primarily be up to the user how they interpret / accommodate for this setting in their creations.
In future, there could potentially be some mechanism for heuristically detecting and toning down flashy / emissive materials, etc. - but that would be a much larger / more involved engineering effort with a lot more complexity than offering a system that users can build their experiences around.
I see I wasn't clear there. I understand that this is implemented by the content author.
The original comment mentioned that it would disable mesh renderers and particles.
I'm curious if there would be a convenient way for a creator to use that toggle to also control other relevant systems, such as ones that drive emission colors, so they could either disable the driver or limit the maximum value for users with the Low Motion setting enabled.
I'm curious if there would be a convenient way for a creator to use that toggle to also control other relevant systems, such as ones that drive emission colors, so they could either disable the driver or limit the maximum value for users with the Low Motion setting enabled.
I would guess a cloud or dynamic variable could be used for that.
Like either:
- Remember X user has this setting enabled globally which disables everything
- Reads the avatar to find a variable that will set a maximum/disable everything
But it's still up to people making those systems to implement that (and I know they don't).
To make my use case more clear, I regularly hang out with a few users who have particle systems and/or emissive textures that "move" and change in a way that causes me pain. They're always very accommodating and happy to turn them off while I'm nearby, but I often have to remind them and I feel a little bad because they're not getting to enjoy their cool systems that are fine for most other users and themselves.
Now obviously, since this is a regular occurrence, I could work with them to add in a simple persistent ValueUserOverride or Cloud Variable driver to their systems, and I will most likely do that in the meantime, but it would be pretty great from an accessibility standpoint if there were an official standard setting or "signal "for that sort of thing that creators could be encouraged to accommodate in their designs. Especially with official worlds showcasing demonstrations.