I was inspired by the Oculus Connect presentation by Nick Donaldson and Nick Whiting on how they achieved their targeted FPS for the UE4 demo. There were some clever work-arounds in there and if you haven’t sighted the presentation I’d recommend it.
While testing recommendations on how to find that sweet place of visual clarity and smooth head tracking, I had an idea… perhaps somebody has already tried it? Or it won’t work?
I am testing arch viz projects and I am realizing that when your head is still, or almost still with slow movement, you can have a high screen percentage and you don’t notice any performance problem. As soon as you swing your neck around quickly, the performance problems are a dead giveaway and you consequently drop the sp to a lower value to increase fps. That said, I can’t see why blueprints could not adjust the sp dynamically based on velocity of head movement to achieve the best of both worlds.
It seems natural that people stop moving their heads when they are looking at an object or scene, at which point they begin to let their eyes do the work. We seem to be trading visual quality all around to cater for low persistence, however, perhaps a lower FPS is acceptable when we prefer clarity over low persistence at a given point in time?
I’d be interested to hear of your thoughts on this…
there are a frame ¿gap? (don’t known if its the word in english), when you change the SP
My demo run smooth/LP at SP 120 if i change to 130 vsync lock my FPS at 37,5 (since Oculus add the “0 present time” modification), and i notice ghost/tearing althought i move the head slowly
then that only factible increase the SP if the head its completely motionless (But we have the frame gap problem)
Yes, I would love to see something like that (AFAIK Wipeout HD on PS3 did something similar, Halo 5 will do the same for XBox One). If you just change the SP/PD-setting, then you get a hickup of about 200-300 ms which is very noticeable. Maybe that’s because it just takes some time to allocate a new buffer with a different size from the driver.
If we had some of that buffers already prepared (say 0.9, 0.85, 0.8 and 0.7) then maybe the engine could just switch the target without having to allocate new memory etc.
@zahir3d: Isn’t that just how V-Sync works? To avoid tearing, the frame rate is cut to half if the engine can’t hold the native frame rate (75 fps).
