Another software strobing implementation on a 3D engine

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!
fuzun
Posts: 17
Joined: 20 Jan 2018, 21:18

Another software strobing implementation on a 3D engine

Post by fuzun » 20 Jan 2018, 21:55

Hello,

If you do not know, there is a game engine called Xash3d and it is compatible with GoldSource. This means it can load the legacy Half-Life from 1998!

I have always been bothered with motion blur in fast paced games like Half-Life.

Since Gold Source is closed source and there is no way to implement software strobing into it without hacking driver or hooking, this will be an alternative to it.

What I want from you is checking if this is done right or not. I assume that you have Half-Life files in your computer so you can test this out.

Here is Xash3d engine: https://github.com/FWGS/xash3d
Here is the implementation: https://github.com/FWGS/xash3d/pull/343
  • Just download the latest release from here: https://github.com/FWGS/xash3d/releases
  • Extract the archive of this test build on top of that: https://transfer.sh/pDvAM/1025-01-27-xa ... d58ba72.7z
  • Grab "valve" game folder from Half-Life folder in Steamapps/common (if you use steam) and copy or sym-link it to the folder that you have done the extractions.
  • Start xash_sdl.exe with "-dev 5 log -console" parameters.
  • Now, open console with ~ key and type "map c2a5a" or "map c1a0" (whatever map you want. C1A0 is good for testing text readability as it contains texts and c2a5a is good for testing brightness reduction and flickering).
  • Make sure that vsync is enabled by typing gl_swapinterval 1. And turn off fps capping by typing fps_max 0.
  • Turn on fps counter by typing cl_showfps 1.
  • Finally turn on strobing with command "r_strobe <int>".
Details from the implementation:
Purpose
Provides motion clarity by eliminating motion blur on high frequency monitors.

How
Replaces certain amount of consequent frames with black frames. This makes a scanning effect like CRT monitors.

Usage
Set r_strobe cvar to the black frame insertion interval (black frame count) you want (ideal values for 144hz monitors are probably -2, -1 = 1, 2, 3) . Frame display interval can be changed with gl_swapInterval cvar. Use cl_showfps 1 to see the actual / effective fps (displayed non-black frame count in 1 second).

Note that V-Sync must be active to enable this! (gl_swapInterval != 0)
  • If r_strobe is positive, some rendered frames will be replaced with black frame
    For example result of r_strobe = 3 will be: black-black-black-normal-black-black-black-normal-black-black-black-normal
  • If r_strobe is negative, the procedure will be the opposite.
    For example result of r_strobe = -4 will be: normal-normal-normal-normal-black-normal-normal-normal-normal-black
Issues
  • Actual brightness gets reduced to half (and perceived brightness will be lowered but not as much as actual brightness) if r_strobe is set to 1 more if >1 less if <-1. This can be corrected somehow by altering gamma and brightness I believe. Because this is just like pulse width modulation synchronized to v-sync frames. And there are several methods to overcome PWM brightness issue. Implementing adaptive version of this is on todo list.
  • FPS will always be lowered. Actual or effective FPS (frames that are not black) gets reduced to half if r_strobe is set to 1 or -1 more if >1 less if <-1 .
  • This will trigger epileptic attacks on epileptic patients.
  • Even on 144hz monitors, flickering may happen.
  • Perceived picture quality will be worse. Much worse on IPS, VA or slow TN panels.
  • Frames that will be black are rendered for no rational reason. TODO: Consider vsync timings and do not render the supposed black frame at all.
  • Ghosting effect may increase.
Any feedback will be appreciated!

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Another software strobing implementation on a 3D engine

Post by Chief Blur Buster » 20 Jan 2018, 22:32

Fantastic stuff!
You created this? Your username on git is the same!

This is the stuff that BlurBusters loves to read about! I'll likely blog about this very soon.

This is similar to the software based blackframe insertion I already have at http://www.testufo.com/blackframes

I have always known that this was possible if you built it into a game engine. This is creative and works very well on 240Hz non-ULMB monitors that can reduce 60Hz persistence by 75 percent (if doing a VISIBLE-BLACK-BLACK-BLACK cycle) -- good for emulators for 240Hz monitors that have no strobed mode -- reducing 75% of motion blur via software based black frame insertion.

For software-based black frame insertion, you definitely need lots of refresh rate headroom to pull this off very well because you can only do persistence in refresh-rate-granularity increments.

For 120Hz, you can only do persistence in 1/120sec increments (e.g. 8.3ms persistence for any frame rate, e.g. 30Hz strobed, 40Hz strobed, 60Hz strobed -- even divisors of 120Hz) -- this is demonstrated via the 2-UFO, 3-UFO and 4-UFO blackframe demo.

You need hardware (backlight controlled strobing) to get sub-refresh-cycle persistence, but software-based blackframe insertion is one good way to get 60Hz strobing on monitors that do not support low-frequency strobe modes.

If you have a strobed monitor, BFI can also be a method of supporting strobed "refresh rates" below the minimum strobed rate of your monitor. For example, 120Hz ULMB or LightBoost can be forced to do 60Hz strobing simply by blacking out every other refresh cycles, making this useful for emulators, 60fps videos, or other forced-60Hz content.

I will install this software within the near future and give this a spin. And when I do -- if you don't mind -- I'd love to blog about it on the main blurbusters.com page crediting you!

P.S. I sent you a PM and email.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

fuzun
Posts: 17
Joined: 20 Jan 2018, 21:18

Re: Another software strobing implementation on a 3D engine

Post by fuzun » 20 Jan 2018, 23:03

Chief Blur Buster wrote:Fantastic stuff!
You created this? Your username on git is the same!

This is the stuff that BlurBusters loves to read about! I'll likely blog about this very soon.

This is similar to the software based blackframe insertion I already have at http://www.testufo.com/blackframes

I have always known that this was possible if you built it into a game engine. This is creative and works very well on 240Hz non-ULMB monitors that can reduce 60Hz persistence by 75 percent (if doing a VISIBLE-BLACK-BLACK-BLACK cycle) -- good for emulators for 240Hz monitors that have no strobed mode -- reducing 75% of motion blur via software based black frame insertion.

For software-based black frame insertion, you definitely need lots of refresh rate headroom to pull this off very well because you can only do persistence in refresh-rate-granularity increments.

For 120Hz, you can only do persistence in 1/120sec increments (e.g. 8.3ms persistence for any frame rate, e.g. 30Hz strobed, 40Hz strobed, 60Hz strobed -- even divisors of 120Hz) -- this is demonstrated via the 4-UFO blackframe demo at http://www.testufo.com/blackframes#count=4

You need hardware (backlight controlled strobing) to get sub-refresh-cycle persistence, but software-based blackframe insertion is one good way to get 60Hz strobing on monitors that do not support low-frequency strobe modes.

I will install this software within the near future and give this a spin. And when I do -- if you don't mind -- I'd love to blog about it on the main blurbusters.com page crediting you!
Thank you so much! I wanted an opinion from you because I have got inspired of "http://www.testufo.com/blackframes" before doing this. I love your website and hope that it will gain attention from developers because almost no one cares about motion blur and realize how bad it really is!

Yeah it is me in the github and a blog post may be done after the pull request (if) gets accepted and integrated. Before that I want to make sure that nothing is wrong on code level. Inspect the code as well if you can since it is pretty basic.

I do not know much about the scientific backend of this but I have done some tests.

On Samsung C24FG70 VA panel @ 144hz without built-in monitor strobing, r_strobe 1 or -1 results low motion blur (not as low as r_strobe 2 or 3) but very bad image quality (like it makes the frame drawn with 8 bit color palette but zero flickering!). I suppose that this is because it is a VA panel. I think with c24fg70@144hz and r_strobe 1 it is not worth to trade picture quality and motion blur. But r_strobe -2, 2 and 3 (or 1 with increased frame latency with gl_swapinterval cvar) works pretty well because it somehow does not degrade picture quality as much as r_strobe 1 (only lowers brightness. Does not make it like 8 bit). I want to make this implementation adaptive and change gamma and brightness settings according to the current frame for example if the current frame gets darker, gamma can get boosted. This will however make flickering more apparent but who cares if motion blur gets eliminated this much!

On Samsung S22B350H TN Panel overclocked to 76hz, r_strobe 1 or -1 and 2 results low motion blur and not bad image quality compared to C24FG70. Ideal setting would be 1 for this monitor I think because it is not high refresh rate and making r_strobe more than 2 makes the flickering almost unbearable.

On B156HAN06.2 AHVA laptop panel overclocked 104hz (from 60hz), r_strobe 1 or -1 gives the best result (Motion blur gets eliminated very much. I can read texts while moving :) ). Not very much noticeable flickering or picture quality. Increasing it will make flickering apparent. However the panel gets darker over time and image retention/burning happens!. Even after closing the game the screen continues to flicker for some time :) . Therefore r_strobe 2 or -2 may be used for this panel or gl_swapinterval 2 may be used.

This may break the game engine but I want to know if this method (black frame replacement) better or for example r_strobe 1 + capping the fps to half and inserting black frames. The latter is used on emulators but I do not know how it would work on this. Probably worse I think.

And there is gl_swapinterval thing which basically sets the duration of a frame. I do not have any testing equipment to see if r_strobe 2 + gl_swapinterval 1 is better or if r_strobe 1 + gl_swapinterval 2. The second set fixes the bad picture quality that C24fg70 produces but also increases flickering.

Lastly, one good thing about this engine is that even with GTX 670 I can get more than 300 fps. This makes testing these kind of things pretty easy. So I recommend for you guys to use this engine for testing things.
---
I can not read the PM btw it says "You are not authorised to read private messages.". I need to have more posts probably.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Another software strobing implementation on a 3D engine

Post by Chief Blur Buster » 21 Jan 2018, 00:01

fuzun wrote:Thank you so much! I wanted an opinion from you because I have got inspired of "http://www.testufo.com/blackframes" before doing this. I love your website and hope that it will gain attention from developers because almost no one cares about motion blur and realize how bad it really is!
While it is only a small bit -- this is slowly changing thanks to virtual reality -- at least among VR developers.

Strobing is used on Oculus and HTC Vive (as well as Samsung GearVR which forces Android phones into a 60Hz flickermode) since motion blur creates lots of headaches in virtual reality!
fuzun wrote:On Samsung C24FG70 VA panel @ 144hz without built-in monitor strobing, r_strobe 1 or -1 results low motion blur (not as low as r_strobe 2 or 3) but very bad image quality (like it makes the frame drawn with 8 bit color palette but zero flickering!). I suppose that this is because it is a VA panel. I think with c24fg70@144hz and r_strobe 1 it is not worth to trade picture quality and motion blur. But r_strobe -2, 2 and 3 (or 1 with increased frame latency with gl_swapinterval cvar) works pretty well because it somehow does not degrade picture quality as much as r_strobe 1 (only lowers brightness. Does not make it like 8 bit).
That is because of something called LCD inversion. See www.testufo.com/inversion or run odd-pixel-steps at www.testufo.com/ghosting (use motionspeeds that uses odd numbers for "Pixels Per Frame". LCD inversion occurs every other refresh cycles to prevent burn-in.

Glossary
LCD inversion -- every LCD does this to prevent burn-in. Rapidly alternate positive/negative voltages to keep things balanced
LCD inversion artifacts -- Normally LCD inversion logic is invisible but sometimes there are artifacts.

More Information about normal LCD inversion operation
- Lagom Inversion Article
- TechMind Inversion Article
- TestUFO inversion patter ntest (pattern optimized for common TN, not VA)

Software-BFI sometimes defeats this burn-in-prevention logic (on certain displays, not all of them). So that's why I programmed www.testufo.com/flicker to alternate by adding one frame once every few seconds to allow it to flicker in the opposite order (to undo the burnin). So basically it's ON-OFF-ON-OFF-ON-OFF for a few seconds, then suddenly it does an ON-OFF-ON-OFF-OFF-ON-OFF to re-balance the voltage inversion.

Burn In Prevention in software-based BFI
This will reduce or fix flicker problems after exiting game
You should swap phases once every few seconds. Basically you need to make sure (over the period of one minute) that all even-numbered refresh cycles and odd-numbered refresh cycles have the same number of black frames. That means even-numbered blackframe insertion needs compensation to rebalance things. Also, frameskips will make it hard to resync, but you could monitor the timing of pageflips and try to detect dropped frames. So that you can correctly guess how many black frames occured during odd refresh cycles, and how many black frames occured during even refresh cycles. That will prevent burn-in. You could keep a counter of black frames for even refresh cycles and a counter of black frames for odd refresh cycles. When one counter becomes massively too big compared to other, automatically adding 1 extra black frame to force the rebalancing. I'd suggest swapping phases once every few seconds. Some monitors don't mind a phase-swap every 60 seconds, but some monitors will do better with a phase-wap every 5 or 10 seconds. Make this configurable.

The separate phases (positive, negative -- even/odd numbered refresh cycles) of inversion essentially have independent image retention, so that's why you see flickering after you exit the game -- one inversion phase is burnt-in with bright images and the other inversion phase is burnt-in with dark images. Fixing this flicker (caused by inversion-logic-defeating software-based BFI) upon game exit can also be done by playing a very high-action full-screen YouTube (no letterbox bars). That resets all the pixels. But if you add an occasional phase-swap (extraneous black frame) you'll reduce or eliminate the flicker that you get upon game exit!

Not all monitors look very bad at even-numbered BFI ratios (e.g. 60fps at 120Hz). For 240Hz monitors (that can do custom refresh rates), you can do 60fps at 180Hz, for a burnin-free black frame insertion of 60fps content (e.g. emulators). And for 144Hz, you can do 48fps at 144Hz just like you're already doing.
fuzun wrote:I want to make this implementation adaptive and change gamma and brightness settings according to the current frame for example if the current frame gets darker, gamma can get boosted. This will however make flickering more apparent but who cares if motion blur gets eliminated this much!
Yes!

As long as the person is motion-blur-sensitive. Not everyone is motion-blur-sensitive -- everybody's vision is different -- some sees colors more, others see blur more, yet others see stutters/tearing more. People are super picky about vastly different things. So make sure this is optional. Let people play with settings. Some people will never like flicker, but that's OK -- that doesn't mean it's a problem for a different person (like you or me).
fuzun wrote:On Samsung S22B350H TN Panel overclocked to 76hz, r_strobe 1 or -1 and 2 results low motion blur and not bad image quality compared to C24FG70. Ideal setting would be 1 for this monitor I think because it is not high refresh rate and making r_strobe more than 2 makes the flickering almost unbearable.
Very good! That's very flickery, but at least LCD GtG kind of soften the flickers by fading it out (sorta like a phosphor fade).
fuzun wrote:On B156HAN06.2 AHVA laptop panel overclocked 104hz (from 60hz), r_strobe 1 or -1 gives the best result (Motion blur gets eliminated very much. I can read texts while moving :) ). Not very much noticeable flickering or picture quality. Increasing it will make flickering apparent. However the panel gets darker over time and image retention/burning happens!. Even after closing the game the screen continues to flicker for some time :) . Therefore r_strobe 2 or -2 may be used for this panel or gl_swapinterval 2 may be used.
For flicker fixing, see above algorithm

This may break the game engine but I want to know if this method (black frame replacement) better or for example r_strobe 1 + capping the fps to half and inserting black frames. The latter is used on emulators but I do not know how it would work on this. Probably worse I think.
fuzun wrote:And there is gl_swapinterval thing which basically sets the duration of a frame. I do not have any testing equipment to see if r_strobe 2 + gl_swapinterval 1 is better or if r_strobe 1 + gl_swapinterval 2. The second set fixes the bad picture quality that C24fg70 produces but also increases flickering.
Shorter flashes are darker but has lower persistence. I think what you're doing is trading "ON-OFF-OFF" versus "ON-ON-OFF" I suspect. The "ON-ON-OFF" BFI cycle probably looks brighter and have less inversion artifacts, but have more motion blur than the BFI cycle.
fuzun wrote:Lastly, one good thing about this engine is that even with GTX 670 I can get more than 300 fps. This makes testing these kind of things pretty easy. So I recommend for you guys to use this engine for testing things.
Yes, that means you can do super-reliable BFI. You pretty much need pretty much perfect frame rate (and VSYNC ON) for comfortable BFI.
fuzun wrote:I can not read the PM btw it says "You are not authorised to read private messages.".
Oops! I sometimes keep forgetting forum members need 5 posts before they can read/send PMs.

This is because we keep having spammers sign up and try to send PM. By forcing them to post publicly first, we can catch them before they begin sending mass-PM's to everybody on Blur Busters. Apologies about this -- eventually we'll have a better system to filter spammers, so that newbies can send PMs more to heart content. But for now, just email me at mark[at]blurbusters.com

Cheers,
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: Another software strobing implementation on a 3D engine

Post by lexlazootin » 21 Jan 2018, 02:28

As a HL speedrunner it does work very well! We can't use Xash for runs but it's still a very neat experience. It's a shame that the FPS cap in Xash is rubbish (can't hold a steady fps) because with this and G-Sync you could set it to any value and get a strobed experience.

I found it also neat that you can adjust the OD setting on your monitor to get a brighter image ;) and it will quickly show you how some colours get over shot or under.

I wish someday soon Valve will open source GoldSrc to add features like this directly. :(

BattleAxeVR
Posts: 44
Joined: 14 Dec 2017, 11:38

Re: Another software strobing implementation on a 3D engine

Post by BattleAxeVR » 21 Jan 2018, 15:18

What I'm curious about, in order to make motion look as realistic as possible, and given ultra high native framerates from older games with simpler engines / graphics, would be to do accumulation-type motion blur (blending 300 fps into 60 or 120 fps), then BFI those frames.

So you present a framerate-appropriate blurred image then using low persistence get the exact right amount of blur, no more, and no less.

There is definitely IMO such a thing as not enough blur, i.e. when you see objects skipping instead of smoothly smeared across the image sensor or out the display finally. Really, the enemy of clarity is low framerate, no matter how much you reduce persistence further you're just exposing a lack of motion blur and things start to look jumpy. Two different types of temporal aliasing, basically. So pick your poison: studdering or over-blurring. There's a crossover point where you don't get extra persistence based blur from the display added on top of the image being presented, but that image is captured or rendered at a certain framerate and objects should *not* teleport from one position to another, that's physically impossible / inappropriate.

So really, what I'm saying is, motion blur isn't the enemy per se, it's excessive motion blur that's the problem. To my mind, a framerate appropriate amount of blur, without anything extra added by the display, but also without missing anything by naively rendering a delta function snapshot in time, is the best.

Critiques / thoughts? I could be totally wrong about this. I've seen jerky motion even at 90 fps in VR experiences, when there isn't any synthetic motion blur added and objects cross your field of vision closely (say a projectile or person travelling close to you such that the number of pixels / frame the objects traverse is much higher than the framerate so that it looks like they teleport from one static moment in time to another, discretely. This doesn't look right to me and takes me out of the moment. IRL objects smear in your perception when they cross your head quickly, in terms of high degrees / second movement).

User avatar
RealNC
Site Admin
Posts: 3740
Joined: 24 Dec 2013, 18:32
Contact:

Re: Another software strobing implementation on a 3D engine

Post by RealNC » 21 Jan 2018, 23:32

Adding motion blur of any type helps with non-tracked motion, but hurts tracked motion, especially with BFI/strobing/crt.

Overall, I dislike it heavily. I mostly care about motion I track with my eyes. The stroboscopic effect does not bother me enough to make me accept motion blur and thus sacrifice tracking clarity, even if it's high quality motion blur based on actual, real frames.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Another software strobing implementation on a 3D engine

Post by Chief Blur Buster » 22 Jan 2018, 13:01

BattleAxeVR wrote:There is definitely IMO such a thing as not enough blur, i.e. when you see objects skipping instead of smoothly smeared across the image sensor or out the display finally. Really, the enemy of clarity is low framerate, no matter how much you reduce persistence further you're just exposing a lack of motion blur and things start to look jumpy.
Yes, this is the stroboscopic effect, aka Phantom Array effect, found at http://www.testufo.com/mousearrow



And unfortunately, Phantom Array still exists at 240Hz and 480Hz. Here's an actual, real photograph from our 480Hz test:

Image

For people who absolutely despise the stroboscopic effect (more than motion blur), the fix is GPU motion blur effect.

You simply add 1 frametime worth of GPU motion blur fixes this.

Low-persistence has no effect on this math. You always need exactly one frametime. If framerate is matching refresh rate, that's one refresh cycle worth of motion blur. Basically if you're doing 90 frames per second, you add 1/90sec worth of GPU motion blur to fix the stroboscopic effect.

The side effect is, obviously, motion blur. Many of us here dislike motion blur.

So how do you fix strobosopic effect AND motion blur simultaneously? Easy. >1000fps at 1000Hz. Okay, yes that's hard.

The higher the frame rate, the less GPU motion blur effect you need to fix any remaining stroboscopic effects. So a higher Hz display at a higher framerate. Now you're figuring it out :)

That way, you only need to add 1ms worth of GPU motion blur effect to fix any remaining minor phantom array effect. That's extremely minor (to most people) -- even LightBoost is 2ms persistence, more motion blur than doing the 1000fps@1000Hz + 1ms GPU motion blur effect for 100% Phantom Array Free with less motion blur than LightBoost/ULMB at default pulse width settings!!!

That's why blurless sample-and-hold is so superior to strobing -- no phantom array effect AND no motion blur. For more information please read Blur Busters Law: The Amazing Journey To Future 1000Hz Displays. Strobefree ULMB will arrive during the 2020-2030s decade, I have seen prototypes (including tantalizing glimpses via our [url=http://www.blurbusters.com/480hz[/url].

NVIDIA also tested a 1700Hz zero-latency display. ViewPixx also now sells a 1440Hz experimental DLP projector for vision scientists. 1000Hz is already in the lab today and I have seen similar true-1000Hz technology privately too! For the first time, I now realistically expect refresh rates will be commercially available by roughly mid-2020s in top-end gaming monitors.

It's strobeless ULMB bliss. And without strobing, there's no lag. Blur reduction without strobing. And you can fix the Phantom Array, easy peasy at these stratospheric refresh rates.

Some people:
- Hate motion blur
- Or hate phantom array
- Or hate stutters
- Or hate stroboscopic effects
- Or hate strobing lag
- Or hate strobing color degradation
- Or hate brightness loss of strobing
- Or hate VSYNC OFF tearing
- Or hate VSYNC ON lag
- Or hate flicker
- Or multiple of the above
- Or all the above
Etc.

The only way to solve ALL above hates simultaneously is blur-free sample-and-hold (aka 1000fps at 1000Hz). That's why it's such a Great Thing that a form of strobeless/lagless ULMB will finally come within our lifetimes. It may take ten years but it's coming.

Resolutions have gone retina, but refresh rates have not yet. The Hz race will keep going for a long time.
Once upon a time, HDTV costs 5 figures. Now it costs only $100 for a cheap 1080p60.
Yes, 1000Hz may be expensive at first.
But by year 2050, it's possible 1000Hz will be cheap, too.

1000Hz: It's not an "if" anymore, but "when".
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

fuzun
Posts: 17
Joined: 20 Jan 2018, 21:18

Re: Another software strobing implementation on a 3D engine

Post by fuzun » 22 Jan 2018, 22:44

Hello again,

I have been working on this and now it works ordered to fix burn in problem. (thanks for the advice Chief !)

It is now running on 4 different situations:

Positive Normal
Positive Black
Negative Normal
Negative Black

Virtual frame sequence will always start (+) and continues like this: + - + - + - + - ...

If r_strobe_swapinterval <x> is set, a swap will happen at certain time (each x sec).

Some examples:

r_strobe 1 / r_strobe_swapinterval 0 :

+ - + - + - + - + - ...
n b n b n b n b n b ...

r_strobe 1 / r_strobe_swapinterval 1 :

+ - + - + - + - + - . (pass of 1 second) . + - + - + - + -
n b n b n b n b n b . (pass of 1 second) . b n b n b n b n

r_strobe 2 / r_strobe_swapinterval 1 : (Swap will be disabled because it is not needed and makes it like r_strobe -2 )

+ - + - + - + - + -
n b b n b b n b b n

r_strobe 3 / r_strobe_swapinterval 2 : Notice that (-) frames will always be black. So swapping/shifting will happen.

+ - + - + - + - + - . (pass of 2 second) . + - + - + - + - . (pass of 2 second) . + - + - + - + - + - ...
n b b b n b b b n b . (pass of 2 second) . b b b n b b b n . (pass of 2 second) . n b b b n b b b n b ...

The difference between positive normal / black and negative normal / black will also be tracked so that if difference gets bigger over time because of some interception or another thing, the player will be informed.

Here is prototype of the new function:

Code: Select all

void R_Strobe(void)
{
	...

	if ((SwapPhaseInfo.fCounter % 2) == 0) //Starts with +
	{
		++SwapPhaseInfo.pCounter;
		SwapPhaseInfo.isPositive = true;
	}
	else
	{
		++SwapPhaseInfo.nCounter;
		SwapPhaseInfo.isPositive = false;
	}

	if (swapInterval < 0)
		swapInterval = abs(swapInterval);

	if ((swapInterval != 0) && (getInterval % 2 != 0)) //Swapping is not enabled for even intervals. Because it makes it like r_strobe -interval . It is not needed anyway since even intervals do not cause burn in problem.
	{
		currentTime = Sys_DoubleTime();
		delta = currentTime - recentTime;
		if ((delta >= (double)(swapInterval)) && (delta < (double)(2 * swapInterval)))
		{
			SwapPhaseInfo.isInverted = true;
		}
		else if (delta < (double)(swapInterval))
		{
			SwapPhaseInfo.isInverted = false;
		}
		else
		{
			recentTime = currentTime;
		}
	}

	if (SwapPhaseInfo.isPositive == true && SwapPhaseInfo.isInverted == false)
	{
		if (abs(getInterval) % 2 == 0)
			SwapPhaseInfo.isNormal = (((SwapPhaseInfo.pCounter - 1) % (abs(getInterval) + 1)) == 0) ? true : false; //even
		else
			SwapPhaseInfo.isNormal = ((SwapPhaseInfo.pCounter % ((abs(getInterval) + 1) / 2)) == 0) ? true : false; //odd

		if (abs(getInterval) == 1)
			SwapPhaseInfo.isNormal = true;
	}
	else if (SwapPhaseInfo.isPositive == true && SwapPhaseInfo.isInverted == true)
	{
		if ((abs(getInterval) % 2) == 0)
			SwapPhaseInfo.isNormal = (((SwapPhaseInfo.pCounter - 1) % (abs(getInterval) + 1)) == (abs(getInterval) / 2)) ? true : false; //even
		else
			SwapPhaseInfo.isNormal = false;
		if (abs(getInterval) == 1)
			SwapPhaseInfo.isNormal = false;
	}
	else if (SwapPhaseInfo.isPositive == false && SwapPhaseInfo.isInverted == false)
	{
		if ((abs(getInterval) % 2) == 0)
			SwapPhaseInfo.isNormal = (((SwapPhaseInfo.nCounter - 1) % (abs(getInterval) + 1)) == (abs(getInterval) / 2)) ? true : false; //even
		else
			SwapPhaseInfo.isNormal = false;
		if (abs(getInterval) == 1)
			SwapPhaseInfo.isNormal = false;
	}
	else if (SwapPhaseInfo.isPositive == false && SwapPhaseInfo.isInverted == true)
	{
		if (abs(getInterval) % 2 == 0)
			SwapPhaseInfo.isNormal = (((SwapPhaseInfo.nCounter - 1) % (abs(getInterval) + 1)) == 0) ? true : false; //even
		else
			SwapPhaseInfo.isNormal = (((SwapPhaseInfo.nCounter - 1) % ((abs(getInterval) + 1) / 2)) == 0) ? true : false; //odd

		if (abs(getInterval) == 1)
			SwapPhaseInfo.isNormal = true;
	}

	if (getInterval < 0)
		SwapPhaseInfo.isNormal = !SwapPhaseInfo.isNormal;

	if (SwapPhaseInfo.isNormal) //Show normal
	{
		R_Set2DMode(false);
		if (SwapPhaseInfo.isPositive)
			++SwapPhaseInfo.pNCounter;
		else
			++SwapPhaseInfo.nNCounter;
	}
	else //Show black frame
	{
		gl_GenerateBlackFrame();
		if (SwapPhaseInfo.isPositive)
			++SwapPhaseInfo.pBCounter;
		else
			++SwapPhaseInfo.nBCounter;
	}
	++SwapPhaseInfo.fCounter;
}
Is there anything else that can be theoretically implemented?
Last edited by fuzun on 23 Jan 2018, 00:28, edited 1 time in total.

fuzun
Posts: 17
Joined: 20 Jan 2018, 21:18

Re: Another software strobing implementation on a 3D engine

Post by fuzun » 22 Jan 2018, 23:31

Chief Blur Buster wrote:Strobing is used on Oculus and HTC Vive (as well as Samsung GearVR which forces Android phones into a 60Hz flickermode) since motion blur creates lots of headaches in virtual reality!
Can software based strobing be used on PWM monitors?
Samsung OLED panels for phones are pulse width modulated. And best laptop panels are pulse modulated. The best 1080p panel I have found for laptops is modulated at 202 Hz (refresh rate is 60 Hz) which causes headache.
Chief Blur Buster wrote:That is because of something called LCD inversion. See http://www.testufo.com/inversion or run odd-pixel-steps at http://www.testufo.com/ghosting (use motionspeeds that uses odd numbers for "Pixels Per Frame". LCD inversion occurs every other refresh cycles to prevent burn-in.
Glossary
LCD inversion -- every LCD does this to prevent burn-in. Rapidly alternate positive/negative voltages to keep things balanced
LCD inversion artifacts -- Normally LCD inversion logic is invisible but sometimes there are artifacts.
Software-BFI sometimes defeats this burn-in-prevention logic (on certain displays, not all of them). So that's why I programmed http://www.testufo.com/flicker to alternate by adding one frame once every few seconds to allow it to flicker in the opposite order (to undo the burnin). So basically it's ON-OFF-ON-OFF-ON-OFF for a few seconds, then suddenly it does an ON-OFF-ON-OFF-OFF-ON-OFF to re-balance the voltage inversion.
Burn In Prevention in software-based BFI
This will reduce or fix flicker problems after exiting game
You should swap phases once every few seconds. Basically you need to make sure (over the period of one minute) that all even-numbered refresh cycles and odd-numbered refresh cycles have the same number of black frames. That means even-numbered blackframe insertion needs compensation to rebalance things. Also, frameskips will make it hard to resync, but you could monitor the timing of pageflips and try to detect dropped frames. So that you can correctly guess how many black frames occured during odd refresh cycles, and how many black frames occured during even refresh cycles. That will prevent burn-in. You could keep a counter of black frames for even refresh cycles and a counter of black frames for odd refresh cycles. When one counter becomes massively too big compared to other, automatically adding 1 extra black frame to force the rebalancing. I'd suggest swapping phases once every few seconds. Some monitors don't mind a phase-swap every 60 seconds, but some monitors will do better with a phase-wap every 5 or 10 seconds. Make this configurable.
So there is only two phases : (+) and (-) because of physics. But there may be different patterns based on + and - phases for LCD inversion. We can't probably be sure that simply swapping prevents the burn in or related problems? I think instead of a simple swap, something like contra-pattern must be implemented. I know there are thousands of different monitors so there must be a lot of inversion patterns but a public database can be made. If software based strobing technique becomes wide-spread this will need to happen.

Frameskipping is a problem yes and I will look into it probably. There are counters now but they only count frames as swapped buffers right now.

Skipping frames -as a feature- instead of black replacement will also need modification on the engine (will break the physics engine probably) and on the custom renderer and that means a lot of work which I do not have right now. Given that there are already no performance issues in Xash3d even with dedicated graphic cards, it should not be a priority.
Chief Blur Buster wrote:As long as the person is motion-blur-sensitive. Not everyone is motion-blur-sensitive -- everybody's vision is different -- some sees colors more, others see blur more, yet others see stutters/tearing more. People are super picky about vastly different things. So make sure this is optional. Let people play with settings. Some people will never like flicker, but that's OK -- that doesn't mean it's a problem for a different person (like you or me).
Yeah but as an initial progress, I think that there should be a perfect balance. The problem is finding it.

Image

This is graph of light perception of humans.

I assume that actual brightness lowers to 50% if strobe happens like this: N B N B N B ...

So if the monitors brightness was 400 lumens (for example), the perceived light will not be like 200 lumens.
In Budgetlightforums, people discuss the relation of light perception and physical values. The most agreed thing is that it is related to some n. root of lumens. (mostly 2, 3 and 4 are used on flashlight firmwares for dimming)
If we think it as square root, it will be 20 - 14.1421 = 5.85, which means 29.25% loss of light, not 50%.

To compensate this, gamma can be changed. But I need to find a good mathematical relevance between gamma and percepted brightness.

Chief Blur Buster wrote: This is because we keep having spammers sign up and try to send PM. By forcing them to post publicly first, we can catch them before they begin sending mass-PM's to everybody on Blur Busters. Apologies about this -- eventually we'll have a better system to filter spammers, so that newbies can send PMs more to heart content. But for now, just email me at mark[at]blurbusters.com
Yeah I understand, I wrote it because I thought there was a bug. After that I realized that it is made by design.
I have sent you response mail. Was the mail and PM the same? If you did not get the mail I can send you PM.
Last edited by fuzun on 23 Jan 2018, 00:27, edited 1 time in total.

Post Reply