60 FPS soon-to-be standard on a console?
<div class="IPBDescription">30 FPS sampling + interpolation = 60 FPS gameplay</div>One for the tech-heads, from SIGGRAPH:
<a href="http://and.intercon.ru/rtfrucvg_html_slides/" target="_blank">http://and.intercon.ru/rtfrucvg_html_slides/</a>
The videos are particularly wow-factor if you cba to download them.
Basically it's a way of feeding in rendering at 30 FPS and having it output at 60 FPS with barely any noticeable difference.
<a href="http://and.intercon.ru/rtfrucvg_html_slides/" target="_blank">http://and.intercon.ru/rtfrucvg_html_slides/</a>
The videos are particularly wow-factor if you cba to download them.
Basically it's a way of feeding in rendering at 30 FPS and having it output at 60 FPS with barely any noticeable difference.
Comments
Neato. My graphics pipeline cries a little less now, once we throw in more interpolation hardware.
'Cause really we should solve everything in hardware. This won't end poorly. At all.
(This debate again. This'll probably last forever.)
I don't think you can actually see much higher than that.
I'm skeptical about this, because if it was as simple as rendering 30fps and then blurring between them, surely someone would have done it already.
Also I kinda think it would introduce a slight lag because the frames will have to be rendered, then the next one rendered, then the interpolated frame calculated, then displayed.
So you're going to be 1-2fps behind what is actually happening in game, or maybe 2-3 because it's actually running at half that FPS, not sure. Might not be a problem but could result in a slightly laggy feel.
No, it's like saying you can count to 120 in a minute by counting twice a second instead of just once a second. Of course, it only matters if you want to count faster, just like this tech is only better if higher frame rate is better ( it is, but with diminishing returns).
Kouji_San explains it perfectly.
They can't render an interpolated frame without the two frames to interpolate between, interpolation works by taking two frames and blending between them. In animation for example you set two key frames, and the the computer interpolates the movement of the character between them, but you need to have TWO key frames to interpolate between, otherwise the computer has to predict the future and figure out where you want the character to move to before you tell it.
So they have to render frame 1, then frame 2, then compare the two and render frame 1.5.
Or in reality, they have to render frame 1, then frame 3, then compare them to get frame 2.
So they can't start rendering frame 2 until frame 3 is fully rendered, which means they're going to be probably between 1 and 3 frames behind, because the game has completed the stuff shown in frame 3 and is simulating for frame 4 while frame 2 is starting rendering.
Like I said I don't know how much of a problem this will be in reality, but I think you will notice a 1 or 2 frame delay between you pressing fire and the gun shooting, for example.
Page 9 doesn't actually explain anything, interpolation is blending between two frames, otherwise it's just rendering things as normal. It's not interpolating if they just look at where it is on frame 2 and render it, that's just rendering.
The way you expand 30 fps to 60 fps is to take the 30fps frames, play them at half speed, and blur between them.
That's what interpolation is.
puzl you ninja poster! <img src="http://members.home.nl/m.borgman/ns-forum/smileys/tongue.gif" border="0" class="linked-image" />
Yes but my point is that if you do that, you get discrepancy between game and display.
If they know what frame 3 is going to look like then the game has to have simulated it, which means the game is at frame 3 and calculating frame 4. The display however is currently calculating frame 2 from frames 1 and 3 and then displaying it, making the display lag behind by two frames more than normal, which is what I've been saying all the time.
Normally, you would just display frame 3 as soon as it's calculate and rendered, more or less, but with interpolation you have to hold it back until frame 2 is calculated and rendered, adding one or two frames to your response delay.
So, as I keep saying, you trade response time for framerate. You can probably interpolate between two images or sets of data more easily than you can render everything from scratch, I don't dispute that, but if you're doing that you're going to be lagging behind the simulation, and thus you're going to have bad responsiveness ingame.
If they know what frame 3 is going to look like then the game has to have simulated it, which means the game is at frame 3 and calculating frame 4. The display however is currently calculating frame 2 from frames 1 and 3 and then displaying it, making the display lag behind by two frames more than normal, which is what I've been saying all the time.
Normally, you would just display frame 3 as soon as it's calculate and rendered, more or less, but with interpolation you have to hold it back until frame 2 is calculated and rendered, adding one or two frames to your response delay.
So, as I keep saying, you trade response time for framerate. You can probably interpolate between two images or sets of data more easily than you can render everything from scratch, I don't dispute that, but if you're doing that you're going to be lagging behind the simulation, and thus you're going to have bad responsiveness ingame.<!--QuoteEnd--></div><!--QuoteEEnd-->
They won't be delaying any frames, the current frames 30FPS will probably just stay where they are. On their 33,3ms interval, they will just be interpolating the extra frame in between on the 16.7ms interval (in between the normal frames). They claim they have gpu/cpu time to finish the interpolating process well within the 16.7ms. They probably wont be touching the other "real" frames, all they want to do is interpolate the extra 60fps frames.
Their claim:
0ms frame 1
0ms to 16.7 (timewindow to interpolate the "1.5" frame, which they could do in 1.5ms 720p on Xbox)
16.7 display interpolated frame "1.5"
33.3 frame 2
@ marketing, hell it's AMD "+" and Intel "MHz" all over again
You need frame 2 to be able to interpolate frame 1.5, you NEED that information because otherwise you can't do any interpolation.
Therefore, instead of simply displaying frame2 as soon as it's calculated, they have to hold the frame back until frame 1.5 is rendered and displayed.
You simply can't interpolate a frame before the frames before AND AFTER it have been calculated. And that means that you have to hold the frame after it back slightly instead of displaying it as soon as you are able.
The whole thing is running with a delay so that they have time to figure out the interpolated frame.
Well they apparently don't, because they say they already know what happens in between those frames by using information from the buffer. Rendering that extra frame is a lot more expensive and simply not possible (hence the 30FPS lock), while the interpolation process they want to use is a heck of a lot cheaper on gpu/cpu time (possible within 1.5ms as they claim on the Xbox @ 720p, 1.2ms on the PS3/5cpu)
Again, this is not like video rendering where they have to predict motion with the use of frame 1 and 2 (respectively) and then "up-fps" it into a new file to display after the whole thing is finished <img src="http://members.home.nl/m.borgman/ns-forum/smileys/tongue.gif" border="0" class="linked-image" />
Again, this is not like video rendering where they have to predict motion with the use of frame 1 and 2 (respectively) and then "up-fps" it into a new file to display after the whole thing is finished <img src="http://members.home.nl/m.borgman/ns-forum/smileys/tongue.gif" border="0" class="linked-image" /><!--QuoteEnd--></div><!--QuoteEEnd-->
'In the buffer' means 'could be going straight to rendering but isn't because we need to interpolate frame 1.5 first'.
Without interpolation it goes like this:
Calculate frame 1 > display frame 1 > calculate frame 2 > display frame 2 > calculate frame 3 > display frame 3 > calculate frame 4 > display frame 4 > calculate frame 5.
With interpolation it goes like this.
Calculate frame 1 > display frame 1 > calculate frame 3 > interpolate frame 2> display frame 2 > Calculate frame 5 > display frame 3> interpolate frame 4 > display frame 4.
You're getting a bigger discrepancy between simulating it and displaying it, because you have to run the display about one frame behind in order to do the interpolation. This means when you press fire and the game simulates it, you are going to have a greater delay between you pressing it and the game simulating it, and it actually appearing on screen.
Hehe quoting myself <img src="http://members.home.nl/m.borgman/ns-forum/smileys/biggrin.gif" border="0" class="linked-image" />
<!--quoteo(post=1796561:date=Aug 27 2010, 08:02 PM:name=Kouji_San)--><div class='quotetop'>QUOTE (Kouji_San @ Aug 27 2010, 08:02 PM) <a href="index.php?act=findpost&pid=1796561"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Their claim:
0ms frame 1
0ms to 16.7 (timewindow to interpolate the "1.5" frame, which they could do in 1.5ms 720p on Xbox)
16.7 display interpolated frame "1.5"
33.3 frame 2<!--QuoteEnd--></div><!--QuoteEEnd-->
Which shows you, they do not need more time or shift frames in their time index. So there is no delay, it just ups the FPS by starting these newly interpolated frames on 16.7ms and using a 33.3 interval from there, in between the original 30fps frames running at 33.3ms.
It is basically using two times 30FPS, the original starting at 0ms and the newly interpolated starting at 16.7. Collectively giving you 60FPS (a frame each 16.7ms)
Your example does the interpolation before calculating the frames needed to perform the interpolation, that's the problem.
It has nothing to do with how long it takes to do the interpolation, it's because you have to do it AFTER calculating the next frame, thus giving you the response time problem.
You may be able to do the interpolation calculation in 1.5 m/s, but you can't do it before 33.3 m/s has gone by and frame2 has been calculated, which means you have to actually display frame 1.5 at the next window of opportunity which is somewhere around 50m/s.
The time discrepancy ignores existing delay of frame rendering to game state. Already frame 1 is delayed from game state. Due to frame buffering it is held in the buffer for a period of time, giving more delay from the game state. Frames are not instantly rendered real-time onto your screen.
They are interpolating the frames while frame 1 is displayed and frame 2 is in the frame buffer, so both exist already, meaning no new delay is produced (or at least marginal addition). They simply interpolate and insert frame 1,5 before frame 2.
Slide 23 explains this.
This
Essentially they are using image manipulation on the rendered frames (makes me think of photoshop) to produce new frames, then inserting these in the time gap between rendered frames.
Infact, why just stop at every other frame? A well designed game could take advantage of situations where certain visual aspects can be rendered at slower frame rates and interpolated to give the illusion of much higher quality graphics on lesser hardware.
Like a hybrid between pre-rendered/sprite animation graphics 3d generated graphics.