Page 5 of 6

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 01 Mar 2014, 20:08
by valfranx
is there any video card that can support PROPixx 500hz?
http://www.vpixx.com/products/visual-st ... opixx.html

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 02 Mar 2014, 07:07
by hashtonkutcher
i can attest to this, its purely muscle memory. for example the drag from a dirty or sweaty mousepad will trow my aim off, if its 100% smooth i can easly snap without even thinking about it. atm im using a teflon based mousepad and added a custom ptfe skate to the mouse. i find the default mini skates mouses come with gather sticky dirt which trows me of by a lot

this looks rather getho, but i be damned if the drag is smooth and even all across the mousepad

Damn I thought I was picky about my mousing surface. I have friends that I play games with that use cloth mouse pads or...shudder...no mouse pad at all and it doesn't even bother them. I always use a hard plastic mouse pad and I even swap the stock mouse feet for teflon versions from corepad, but you my friend, are on some next level shit. Where did you get your teflon if you don't mind me asking?


On a side note, anyone with a high refresh rate display should absolutely invest in a high performance mouse, if you haven't seen blurbusters guide on mice I suggest you check it out.
http://www.blurbusters.com/faq/mouse-guide/

One thing I wanna add is that if you go over to /r/mousereview on reddit they get really deep into the specifics of which mice are the best and why. The long and short of it is that optical mice are superior to laser mice because they offer the rawest input(least acceleration).

http://www.reddit.com/r/MouseReview

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 04 Mar 2014, 03:58
by Chief Blur Buster
Experiments on Adjustable Persistence Displays

LightBoost has long been known to be adjustable in persistence, but only by a factor of about 2x (LightBoost 10% versus 100%). However, I have, here, sitting a BENQ XL2720Z monitor with updated firmware, that is has highly adjustable persistence over nearly a whole order of magnitude, with the new Blur Busters Strobe Utility:

Image

Known: Persistence is equal to strobe length. (measured by photodiode oscilloscope)
Known: Persistence is equal to sample and hold duration. (measured by photodiode oscilloscope)
Confirmed: 4ms persistence has twice the motion blur of 2ms persistence
Confirmed: 2ms persistence has twice the motion blur of 1ms persistence
Confirmed: 1ms persistence has twice the motion blur of 0.5ms persistence

When I view http://www.testufo.com/photo at 960pixels/sec (very close to 1000 pixels/second, but still divisible by the 120Hz refresh rate), I am witnessing an easy adjustable-persistence-monitor that helps tests the persistence law of "1ms equalling 1 pixel of motion blur during 1000 pixels/second".

Make sure you're using a stutter free web browser ( http://www.testufo.com/browser.html ) and you are not using Classic mode in Windows (which can interfere with TestUFO). Make sure TestUFO is the only webpage running, and no background applications. Enable BENQ Blur Reduction. Disable all 60Hz monitors (if you're using multimonitor). Now, verifiy TestUFO is running stutter-free at 120 frames per second. At http://www.testufo.com/photo choose a photo (Quebec, Toronto Map or Alien Invasion). Look at the thin window frames in the "Quebec" animation, look at the street name labels in the "Toronto Map" animation, or look at the eyes/pixel details in the "Alien Invasion" animation. While looking at these fine details, adjust.

At 960 pixels/second, I visually observe:
4ms persistence = ~4 pixels of motion blur during 960 pixels/second
2ms persistence = ~2 pixels of motion blur during 960 pixels/second
1ms persistence = ~1 pixels of motion blur during 960 pixels/second
0.5ms persistence = I have some difficulty telling the difference to 1ms

At 1920 pixels/second, I start to notice benefits of 0.5ms persistence:
4ms persistence = ~8 pixels of motion blur during 1920 pixels/second
2ms persistence = ~4 pixels of motion blur during 1920 pixels/second
1ms persistence = ~2 pixels of motion blur during 1920 pixels/second
0.5ms persistence = ~1 pixels of motion blur during 1920 pixels/second

The motionspeeds of 1920 pixels/second (one screenwidth panning per second) is very common in FPS gaming, during mouse turning/strafing/panning. So, the benefits of 0.5ms persistence is just about visible to my eyes during situations where I'm running at 120fps @ 120Hz, especially when combined with an ultra-smooth 1000Hz mouse (500Hz and less is too microstuttery; see next post below).

The benefits of 1ms persistence and 0.5ms persistence was not noticeable to my eyes at 960 pixels/second or less. I did, however, notice a rather interesting phenomenon: the scrolling screendoor effect (where the LCD pixel grid appear to "scroll" along with the motion) only showed up during 0.5ms strobe flash length, not during 1ms strobe flash length. This makes sense, since the shorter 0.5ms strobes is now sufficiently short to eliminate most of eye-tracking-based blurring of the LCD subpixels during 960 pixels/second - so the screendoor effect now stroboscopically 'scrolls along'.

Eye tracking 1920 pixels/second can still be prone to inaccuracies from saccade effects, but I am definitely seeing human visible differences, with my eyes, between 1ms persistence and 0.5ms persistence (not placebo). It's pretty neat to see further visual confirmation of the formula (which I now call "Blur Busters Law of Persistence").

Conclusion: 1ms of persistence (strobe flash length) is equal to 1ms of tracking-based motion blur during 1000pixels/second framerate-refreshrate synchronized motion.

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 04 Mar 2014, 04:14
by Chief Blur Buster
The Topic of Microstutter Mathematics

On another subject -- another area of study is stutter/judder creating motion blur.
Judder/stutter often creates a flickering-edge effect.

High-frequency stutter at, say e.g. 113fps@144Hz (and will even still happen at higher refresh rates, even 1279fps@1000Hz) if it was 8 pixel amplitude stutter, would blend into an 8 pixel motion blur. If the stutter is 5 pixel amplitude, it's a 5 pixel-wide motion blur if the stuttering is occuring at high frequencies beyond flicker fusion threshold. Given sufficiently fast motion on sufficiently sharp displays (e.g. 8000 pixels/second panning speed on a theoretical 1000fps@1000Hz 4K VR goggles), this is actually a human-visible factor and must be considered, since I can see individual single pixels during two-screenwidths-per-second panning speeds (3840 pixels/second) in certain TestUFO tests on ultralow persistence monitors. This is another big reason why I can visually see microstutter differences of a 500Hz mouse versus a 1000Hz mouse, when dragging a window on a strobe-backlight monitor. There's no motion blur to obscure the microstutters, and tiny text in a web browser window is more visibly blurred during 500Hz mouse operation than during 1000Hz mouse operation due to less aliasing effects between mouse pollrate versus display refresh rate. During 4000 pixels/second window dragging, a 1/1000th rounding error is 4 pixels, and a 1/500th rounding error is 8 pixels. The rounding errors occurs because sometimes mouse position updates happen right before a refresh versus right after a refresh; This aliasing effect between poll rate versus refresh rate defines the microstutter amplitude (the amount of deviation relative to eye tracking).

Unlike most people, I find microstutter mathematics is very easy to visualize in my head, calculate and very easy to predict, so I'm probably going to design a Blur Busters Microstutter Calculator sometime this year during 2014, where you enter a frame rate (or poll rate) & enter a refresh rate, and I output how much microstutter you will see, at what beat-frequency (for low frequency microstutter harmonics), and at what blurring effect (for high frequency microstutter harmonics). This is useful to those people who still see microstutters during VSYNC OFF 300fps@144Hz, and it is easy to calculate what the stutter amplitude is, relative to ideal tracking trajector -- formula is simply (1/fps)th of motionspeed. For example, VSYNC OFF 4000 pixels/second during 300fps@144Hz, creates a microstutter amplitude of 13.3 pixels. (excluding any additional microstutters contributed by computer mice). The frequency of the microstutter during 300fps@144Hz is 12 stutters per second (edge vibration cycles per second), calculated as simply the beat frequency between fps versus Hz. You can see 2 stutter per second at 142fps@144Hz, and you can see 1 stutter per second at 143fps@144Hz.

Technically, one can eliminate microstutters via using VSYNC ON. This improves motion clarity greatly during strobe operation, and can be good for solo gameplay where input lag isn't critical (e.g. sliding on rails in Bioshock Infinite benefits from VSYNC ON 120fps@120Hz, where stutter-free motion clarity really stands out)

In addition, I also mathematically/scientifically understand why NVIDIA strongly recommends a 1000Hz mouse during GSYNC on. It reduces microstutter harmonics. Mouse operation during 1000Hz has half the microstutter amplitude of mouse operation at 500Hz, and in addition, 1000Hz operation also has less aliasing effects with refresh rates -- a very important consideration when the said refresh rate itself is continually varying.

Microstutter math is simpler than most people think. This, of course, assumes the graphics card isn't the weak link (e.g. older source engine game on new graphics cards) and the game engine is pretty stutterfree (e.g. older source engine on new graphics cards) and other devices aren't injecting extra stutter (e.g. microstutters caused by computer mice, caused by poll rate interacting with refresh rate), so the microstutter math is easily "seen-for-yourself" testable via keyboard strafe left-right (no mouse microstutters) when playing with fps_max values of a Source Engine game (e.g. Half Life 2) on a recent graphics card. Note that actual fps output often deviates 1fps from fps_max values, so make sure to read actual fps counters for verification. (Note that fps_max 143 often generated framerates of 142fps). In this situation, predicted microstutter math accurately followed human observations. (Geforce GTX Titan, capable of >400fps in older source engine games, VSYNC OFF).
Observations
-- 141fps at 144Hz creates 3 microstutters per second (plus downwards rolling tearline at 3 cycle per second)
-- 142fps at 144Hz creates 2 microstutters per second (plus downwards rolling tearline at 2 cycle per second)
-- 143fps at 144Hz creates 1 microstutters per second (plus downwards rolling tearline at 1 cycle per second)
-- 144fps at 144Hz creates 0 microstutters per second (plus nearly stationary/slow/vibrating tearline artifact)
-- 145fps at 144Hz creates 1 microstutters per second (plus upwards rolling tearline at 1 cycle per second)
-- 146fps at 144Hz creates 2 microstutters per second (plus upwards rolling tearline at 2 cycle per second)
-- 147fps at 144Hz creates 3 microstutters per second (plus upwards rolling tearline at 3 cycle per second)
-- Keyboard strafing left/right shows a microstutter vibration amplitude equal to (1/fps)th of motionspeed in situations whenever framerate is not synchronized to refreshrate.
-- 400fps@144Hz looks noticeably smoother than 200fps@144Hz, the microstutter amplitude is only half as much (ignoring microstutter frequency, but focussing on microstutter amplitude relative to ideal tracking vector)

Conclusion #1: Higher mouse poll rates reduces microstutters, due to less aliasing effects between poll rate and refresh rate / frame rate. Unfiltered 1000Hz versus unfiltered 500Hz is more visible when the improved motion clarity of a display no longer masks microstutters (e.g. 120Hz, 144Hz, LightBoost, etc). Visual observations are consistent with with mathematical microstutter predictions.
Conclusion #2: Raising framerates even further, far above refresh rate, has actual, tangible, scientifically provable & calculable visual benefit, during motion that is not synchronized to refresh rate (e.g. VSYNC OFF). 400fps@144Hz is noticeably smoother than 200fps@144Hz. Visual observations are consistent with the microstutter math indicating there would be half-amplitude microstutters at 400fps than at 200fps.

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 04 Mar 2014, 23:35
by Chief Blur Buster
P.S. This is quite a lot of science here, and I'd most be happy to partner up with any scientist/researcher readers for actual science papers that eventually get peer reviewed. There is a lot of new knowledge in the last few years alone, that weren't easily testable pre-2011 -- cheap adjustable-persistence monitors did not arrive until recently.

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 05 Mar 2014, 02:49
by ScepticMatt
To look closer at strobing vs tracking vs blur, I created a little openGL glut motion blur test app.
Not sure if this is a good idea on blurbusters but I find it interesting non the less.
It's a white triangle bouncing and rotating, with
a) no motion blur, lot's of strobing
b) eye tracking simulation, little strobing as long as eye-tracking is good, blur from rotation
c) classic motion blur, no strobing but extra blur.
Using the classic A-buffer algorithm.
ImageImageImage
I've uploaded Linux binary and source code at:
https://github.com/ScepticMatt/Blurdemo

(It's my first openGL program, so please don't be too strict with my code :)

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 05 Mar 2014, 09:57
by Chief Blur Buster
Very interesting demo!
ScepticMatt wrote:To look closer at strobing vs tracking vs blur, I created a little openGL glut motion blur test app.
Not sure if this is a good idea on blurbusters but I find it interesting non the less.
Motion blur isn't verboten around here -- we just fight against mandatory display-enforced motion blur (that can't be adjusted down) forced upon our eyes above-and-beyond natural motion blur within human brain/vision. Software motion blur can be fully adjustable and can be disabled via a configuration setting, this is not something we're against as long as the user has the choice. We've got a philosophy:
The Blur Busters Philosophy: Although we strive to eliminate motion blur, we do not necessarily hate motion blur in general. However, we believe displays should never create unavoidable extra motion blur upon human eyes. Motion blur should be 100% natural, as it is a natural behavior of the human brain. Thus, motion blur should be created naturally (or by artistic intent or user adjustment) without the display adding unwanted motion blur.

Re: So what refresh rate do I need? [Analysis] [very good on

Posted: 22 Aug 2017, 14:33
by Chief Blur Buster
New demos relevant to this thread.

We have tested a 480Hz monitor, which still keeps improving in phantom array effects at higher Hz, in the new Mouse Arrow test http://www.testufo.com/mousearrow

Image

And here's a TestUFO Persistence Of Vision Demo.
Look at the stationary UFO, then look at the moving UFO. On a non-strobed LCD, the vertical lines disappear (into motion blur instead) for the moving UFO:



Test this at 60Hz, 120Hz and 240Hz (and I've even now tested at 480 Hz)
- Doubling the Hz will double the horizontal resolution of this
- Resolution of scrolling image is independent of the separation between veritcal lines. (Click the test and change "Separation" setting)
- Vertical boundaries between pixel are much sharper than default LCD motion blur
- Thanks to the BFI effect of eye-tracking across black gaps; this test filters persistence from LCD GtG, so vertical boundary clarity is now more LCD GtG instead of persistence. On TN LCDs instead of VA/IPS LCDs, the vertical boundaries between pixels become quite noticeably sharper, now that sub-refresh-cycle LCD GtG is no longer obscured by full-refresh-cycle persistence.

Re: So what refresh rate do I need? [Analysis] [very good one!]

Posted: 24 Aug 2020, 22:37
by Kertwaii
Speaking about adaptive sync technologies...
Does it mean that at very high monitor refresh rates low frame rates will look almost like adaptive synced because the refresh cycle is very fast and getting a tear line is a rare occurence (and visible for a very short time)?
e.g. 110fps stutter@144hz vs 110fps stutter@1000hz

Re: So what refresh rate do I need? [Analysis] [very good one!]

Posted: 25 Aug 2020, 14:40
by Chief Blur Buster
Kertwaii wrote:
24 Aug 2020, 22:37
Speaking about adaptive sync technologies...
Does it mean that at very high monitor refresh rates low frame rates will look almost like adaptive synced because the refresh cycle is very fast and getting a tear line is a rare occurence (and visible for a very short time)?
e.g. 110fps stutter@144hz vs 110fps stutter@1000hz
First, terminologically, this needs to be clarified, because there is probably a confusion here.

If by "adaptive sync" you mean variable refresh rate technology, there's never tearlines during VRR for consistent framerates well below Hz. Not to be confused by fixed-Hz "adaptive vsync" driver settings (non-VRR), which is different from "VESA Adaptive Sync" (VRR tech)

Now if by "stutter", you mean fast regular stutter blending into motion blur (Explained at www.blurbusters.com/1000hz-journey ... 110fps being the 110 object-jumps per second) independently of the erratic stutter or judder (e.g. harmonics/beat frequencies between frame rate and refresh rate).

"VRR", here, represents Variable Refresh Rate, such as FreeSync or G-SYNC or VESA Adaptive-Sync.

110fps stutter would look identical for 110Hz VRR and 1000Hz VRR, since refresh interval would be 1/110sec.

Now if you mean 110fps non-VRR during 1000Hz, it would look like 100fps VRR because of the tiny stutter granularity. 1/1000sec stutter for 1000Hz, versus 1/144sec stutter for 144Hz -- the stutter jump amplitude would be about one-seventh at 1000Hz versus 144Hz (1000/144 = about 7x difference).

Thus, for a sample-and-hold display, these would look identical (1/144sec of motion blur)
110fps at 144Hz VRR
110fps at 1000Hz VRR
110fps at 1000Hz fixed-Hz (only 1/144sec = 1ms error margin)

While this would look visibly erratically-stuttery
110fps at 144Hz fixed-Hz (up to 1/144sec = 6.94ms error margin).

Does this answer your question adequately?