Cubic Extrapolation
Who ever first called interpolation needs a good smack.
Ok, I got my time sync, I got my packet streamer, I got my position information, I got a position packet that packs the coefficents for 3 parametric cubic equations & the time is was true for (each client will calc its own coef''s and send them out).
My first thought was to use the last 4 position points and make a perfect fit cubic. I''m concerned that this will suck because perfect fit poly''s suck at extrapolation. It''s just a bad idea to base the next 300-1000ms of motion off of the first 120ms of motion.
I was curious if anyone has used perfect fits and how bad (or good) they were. I was thinking that a best fit poly would be a better (but more expensive) method, maybe over the last seconds worth of movement.
You might consider using damped cubic extrapolation instead of exact fit. That given the four previous points, you can calculate position, and approximations to the first derivative, second derivative and third derivitive at the end point with exact cubic interpolation. Then reconstruct an extrapolant for the movement by taking as starting conditions the position and first derivative and a fraction of the second and third derivative, or even a multiple. Whether you damp or overshoot depends on how regular you expect movement to be in your application.
I'm new at this multiplayer stuff, but shouldn't the interpolation be calculated off of the last three LOCAL states?
If the remote system is doing the interpolation calculation, and the local system loses a packet p21, packet p22 is going to have some weird interpolation that is not going to jive with the final position information. for example, if an object is supposed to start at 5,5,5 but your local machine thinks it is at 1,1,1, applying a precalculated interpolation (using only first derivatives, or velocity) of (0,0,1) is going to make you end up at 1,1,2 not 5,5,6. Assuming you are sending absolute coordinates as well, you could apply the interpolation, end up at 1,1,2, then have to warp to 5,5,6. Or you could just warp to 5,5,6. Either way, the interpolation information from the remote system has not helped to smooth warping. (Of course you could interpolate between 1,1,2 and 5,5,6 on the local machine in order to smooth the warping. . .)
Also, by sending interpolation information, you are making your packets larger. I thought one of the main functions of interpolation is so that all you have to send is absolute positions thus reducing packet sizes. The local machines will then guess the rest through interpolation of the last few LOCAL states.
Sorry if i misunderstood what you are doing.
DmGoober
Edited by - DmGoober on December 1, 2000 3:35:02 PM
If the remote system is doing the interpolation calculation, and the local system loses a packet p21, packet p22 is going to have some weird interpolation that is not going to jive with the final position information. for example, if an object is supposed to start at 5,5,5 but your local machine thinks it is at 1,1,1, applying a precalculated interpolation (using only first derivatives, or velocity) of (0,0,1) is going to make you end up at 1,1,2 not 5,5,6. Assuming you are sending absolute coordinates as well, you could apply the interpolation, end up at 1,1,2, then have to warp to 5,5,6. Or you could just warp to 5,5,6. Either way, the interpolation information from the remote system has not helped to smooth warping. (Of course you could interpolate between 1,1,2 and 5,5,6 on the local machine in order to smooth the warping. . .)
Also, by sending interpolation information, you are making your packets larger. I thought one of the main functions of interpolation is so that all you have to send is absolute positions thus reducing packet sizes. The local machines will then guess the rest through interpolation of the last few LOCAL states.
Sorry if i misunderstood what you are doing.
DmGoober
Edited by - DmGoober on December 1, 2000 3:35:02 PM
oh man, I wrote a decent reply but wapped esc on accident...
But thanks, I didn''t even think to do it that way...(using local received points)
I see two problems with that though:
1) Sporadic time-base
2) Few points to extrapolate from
So you more or less can never extrapolation, you always have to interpolate (hence the common name eh? <smacks self in head>), so the other player''s position is never accurate.
Calculating the extrapolation coef. remotely lets you use many more points, yeilding a better fit curve - or rather a fitting curve.
As I see it, it''d just be a waste of cpu time to calculate 3rd order coef''s based off of local points... a straight line may be more accurate!
Maybe some combination of both?
Magmai Kai Holmlor
- The disgruntled & disillusioned
But thanks, I didn''t even think to do it that way...(using local received points)
I see two problems with that though:
1) Sporadic time-base
2) Few points to extrapolate from
So you more or less can never extrapolation, you always have to interpolate (hence the common name eh? <smacks self in head>), so the other player''s position is never accurate.
Calculating the extrapolation coef. remotely lets you use many more points, yeilding a better fit curve - or rather a fitting curve.
As I see it, it''d just be a waste of cpu time to calculate 3rd order coef''s based off of local points... a straight line may be more accurate!
Maybe some combination of both?
Magmai Kai Holmlor
- The disgruntled & disillusioned
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
