Tool for detecting potential triggers for photosensitive epilepsy during dev/playtest

[Selene-Amanita]

What problem does this solve or what need does it fill?

One in 4,000 people have a form of photosensitive epilepsy (PSE).
This can trigger various forms of seizure, which can in turn be a risk for the life of some of those people in some circumstances.
Video game, as other video medias, can trigger those seizures in some situations (mainly, but not only, high luminance contrast).
It can be hard for a person without PSE to know what qualifies as, or even notice, a trigger stimuli.

What solution would you like?

A dev tool integrated with bevy to be able to analyze what is rendered during a gameplay session.
This tool could be on during the whole development process, and during playtest, and display a warning everytime a potentially triggering stimuli is detected.

What alternative(s) have you considered?

Recording a gameplay session and analyze the video with another available tool (https://trace.umd.edu/peat/ / https://video.stackexchange.com/questions/22858/software-for-detecting-photosensitive-epilepsy-content/29576#29576 ).

Additional context

Conversations for a similar tool for colorblindness can be found here: #2724 / #5606

[bushrat011899]

I think a post-processing shader would be the best way to tackle something like this. I personally don't have PSE, so I'm not qualified or experienced with it or its mitigations, but I would imagine something that works on the final rendered image would be the most sensible way to assess PSE risk. Based on the W3C Seizure Guidelines, the general recommendation is to "just" avoid flashing, where flashing is defined here.

I'm not familiar enough with shader development to make something myself, but I imagine what you would need to do is:

• Store at least 1 second worth of frames in a buffer. Strictly speaking, we only care about the red channel, and the luminosity, so this could be 2 buffers of single-channel images, but that's an optimisation and not a requirement.
• Over the entire buffer, if adding the current proposed frame passes any of the below criteria, it is "safe" as-is:
  1. There are no more than three flashes.
  2. The combined area of flashes occurring concurrently occupies no more than 25% of any 10 degree visual field on the screen at typical viewing distance.
• If the proposed frame would violate the safety conditions, then the shader could either:
  1. Modify the image to ensure it passes (blend proposed frame with previous luminosity/red, etc.)
  2. Report that failure to the engine for a post-render system to react to (panic, log the occurrence, etc.)

Since this would require some pretty memory intensive frame analysis, I imagine this would be best suited for an optional plugin. Since the guidelines involve FOV information, the shader would need runtime information regarding an estimate of the DPI (pixels to physical length), and the viewing distance (physical length to angular length).

Since the whole test revolves around counting flashes over a 1 second interval, the hardest part of this issue is creating a shader which could classify pixels as having flashed. If that can be done, then measuring the size and frequency of flashes is a relatively simple task.