[Flightgear-devel] Replay system

[Robert]

Hi everyone,

I'd like to share some thoughts with you on how we can improve the replay
system.
Right now only the last minute is recorded at full precision. After that
minute we get a precision of 1 fps. And after 10 minutes we get a precision
of 1 frame per 10 seconds (please correct me. this number may be wrong).
Due to linear interpolation the motion of the plane become jagged (hope you
understand what I mean here).
Also due to the loss of precision fast rotations of the plane look just
incorrect in the replays (reversed direction of the rotation).

FIRST SOLUTION:
Streaming the replay data to the hard disc drive always at full precision.
This is probably the best solution as:
We don't need much RAM to save a whole flight (we just need a stream
buffer).
We get full precision.
We solve the reversed rotaton problem.
We still should use linear interpolation here as it is faster than monotone
hermite spline:

SECOND SOLUTION:
To solve the jagged motion problem I thought of implementing another
interpolator.
The monotone Hermite spline interpolator. It has the benefits that it does
not oscillate in comparison to the Catmull Rom interpolator.
The downside to this solution is that the problem of incorrect (reversed)
rotation cannot be solved.
Also we will need to feed the hermite spline interpolator with 4 replay
frames instead of 2 used in the linear interpolator.


p.s. I also thought that it woud be nice if the nearest tower would be
automatically computed in replays (as it is done in x-plane), so you don't
have to enter the airport code every time.

What do you think?
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Replay system

[Peter Brown]

On Mar 31, 2011, at 11:01 AM, Robert wrote:

> Hi everyone,
> 
> I'd like to share some thoughts with you on how we can improve the replay 
> system.
> Right now only the last minute is recorded at full precision. After that 
> minute we get a precision of 1 fps. And after 10 minutes we get a precision 
> of 1 frame per 10 seconds (please correct me. this number may be wrong).
> Due to linear interpolation the motion of the plane become jagged (hope you 
> understand what I mean here).
> Also due to the loss of precision fast rotations of the plane look just 
> incorrect in the replays (reversed direction of the rotation).
> 
> FIRST SOLUTION:
> Streaming the replay data to the hard disc drive always at full precision.
> This is probably the best solution as:
> We don't need much RAM to save a whole flight (we just need a stream buffer).
> We get full precision.
> We solve the reversed rotaton problem.
> We still should use linear interpolation here as it is faster than monotone 
> hermite spline:
> 
> SECOND SOLUTION:
> To solve the jagged motion problem I thought of implementing another 
> interpolator.
> The monotone Hermite spline interpolator. It has the benefits that it does 
> not oscillate in comparison to the Catmull Rom interpolator.
> The downside to this solution is that the problem of incorrect (reversed) 
> rotation cannot be solved.
> Also we will need to feed the hermite spline interpolator with 4 replay 
> frames instead of 2 used in the linear interpolator.
> 
> 
> p.s. I also thought that it woud be nice if the nearest tower would be 
> automatically computed in replays (as it is done in x-plane), so you don't 
> have to enter the airport code every time.
> 
> What do you think?
> 

Just as additional info, this was how the precision was explained to me last 
year :

http://sourceforge.net/mailarchive/message.php?msg_id=24790011


--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Replay system

[ThorstenB]

On 31.03.2011 17:01, Robert wrote:
> Hi everyone,
>
> I'd like to share some thoughts with you on how we can improve the 
> replay system.
> Right now only the last minute is recorded at full precision. After 
> that minute we get a precision of 1 fps. And after 10 minutes we get a 
> precision of 1 frame per 10 seconds (please correct me. this number 
> may be wrong).
>
> FIRST SOLUTION:
> Streaming the replay data to the hard disc drive always at full precision.
Streaming data to disc would be nice - but should be optional and not be 
enabled by default. It would also be nice to have an option to save a 
recorded instant replay buffer (when you haven't enabled the 
stream-to-disc feature earlier).

I can't comment on the different interpolation methods. But what would 
also help is to change the recording scheme:
Currently the valuesof a fixed set of properties is recorded at each 
frame. However, most properties rarely change. Only the a/c position and 
speed properties tend to change in every frame. Properties like gear 
position and control surfaces are almost constant (from frame to frame). 
So, it might be a good idea to record all properties in an interval of a 
few seconds only, while only recording properties that have actually 
changed with every frame. That should allow to drastically reduce the 
amount of recorded data - and allow much longer high resolution memory 
recordings. And you could still fast-forward within the buffer, since 
you'll have a complete set of properties every now and then. It's a 
simple but effective compression method which is used in many areas.

It would also be nice to support recording of custom properties. We 
already have a similar solution for multiplayer mode. If the replay 
system recorded the same properties configured in the "aircraft-set.xml" 
(the "generic" int/float/string properties), it would mean a nice 
improvement. It would also have other advantages, such as allowing 
simple tests of an aircraft's multiplayer configuration.

> p.s. I also thought that it woud be nice if the nearest tower would be 
> automatically computed in replays (as it is done in x-plane), so you 
> don't have to enter the airport code every time.
Indeed. That feature would also be nice for "normal flight". I never 
understood why the tower view sticks to the initial airport. Switching 
to the "departure airport's tower view" doesn't make much sense after a 
long distance flight. A general "use nearest tower" option would be nice.

I don't think anyone is working in these areas right now. So if you are 
(or anyone else is) interested on working on these, let us know.

cheers,
Thorsten


--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Replay system

[Curtis Olson]

On Thu, Mar 31, 2011 at 5:08 PM, ThorstenB wrote:

> Streaming data to disc would be nice - but should be optional and not be
> enabled by default. It would also be nice to have an option to save a
> recorded instant replay buffer (when you haven't enabled the
> stream-to-disc feature earlier).
>

Yeah, streaming to the hard drive could fill up our user's drives really
quickly, and on many systems this could be a performance bottleneck and
impact frame rates (or consistency of frame rates.)  On the other hand it
would be a nice option to be able to turn on once in a while.

I can't comment on the different interpolation methods. But what would
> also help is to change the recording scheme:
> Currently the valuesof a fixed set of properties is recorded at each
> frame. However, most properties rarely change. Only the a/c position and
> speed properties tend to change in every frame. Properties like gear
> position and control surfaces are almost constant (from frame to frame).
> So, it might be a good idea to record all properties in an interval of a
> few seconds only, while only recording properties that have actually
> changed with every frame. That should allow to drastically reduce the
> amount of recorded data - and allow much longer high resolution memory
> recordings. And you could still fast-forward within the buffer, since
> you'll have a complete set of properties every now and then. It's a
> simple but effective compression method which is used in many areas.
>

Pluses and minus to every approach ... determining if a property has changed
by enough of a threshold amount to log the change would be extra work and
could also complicate the playback, so that would have to be balanced
against the potential pay off.  When you get away from a fixed record
format, then you need a way to identify/tag each data value along with a
corresponding time stamp, so you have to give some of the space savings back
... and I would imagine to do this efficiently (space and time) could lead
to some pretty complicated errr sophisticated logging code.  I'm not saying
that's bad, but this is a pretty complicated proposal I think when you start
digging into the details.


> It would also be nice to support recording of custom properties. We
> already have a similar solution for multiplayer mode. If the replay
> system recorded the same properties configured in the "aircraft-set.xml"
> (the "generic" int/float/string properties), it would mean a nice
> improvement. It would also have other advantages, such as allowing
> simple tests of an aircraft's multiplayer configuration.
>

This would be nice ... even if it was just a set of extra generic fields
that are logged and the aircraft-set.xml file would have some way to specify
a set of additional properties that would be logged an played back in
addition to the default ones.  It's annoying to replay helicopter flights
when the rotor doesn't spin, or when only one gear leg is deployed, or the
false shadow is stuck to the bottom of the aircraft while flying the replay


Indeed. That feature would also be nice for "normal flight". I never
> understood why the tower view sticks to the initial airport. Switching
> to the "departure airport's tower view" doesn't make much sense after a
> long distance flight. A general "use nearest tower" option would be nice.
>

No one has written the code to auto-switch the tower -- I think it's as
simple as that.


> I don't think anyone is working in these areas right now. So if you are
> (or anyone else is) interested on working on these, let us know.
>

There's plenty of room for improvement ... even tuning data rates or how
many seconds of what resolution data could lead to some improvements.  The
initial implementation was an attempt to balance many factors ...
simplicity, functionality, memory footprint, speed.

Regards,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://gallinazo.flightgear.org
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Replay system

[ThorstenB]

On Fri, Apr 1, 2011 at 12:34 AM, Curtis Olson  wrote:

>> So, it might be a good idea to record all properties in an interval of a
>> few seconds only, while only recording properties that have actually
>> changed with every frame. That should allow to drastically reduce the
>> amount of recorded data - and allow much longer high resolution memory
>> recordings. And you could still fast-forward within the buffer, since
>> you'll have a complete set of properties every now and then. It's a
>> simple but effective compression method which is used in many areas.
>
> Pluses and minus to every approach ... determining if a property has changed
> by enough of a threshold amount to log the change would be extra work and
> could also complicate the playback, so that would have to be balanced
> against the potential pay off.  When you get away from a fixed record
> format, then you need a way to identify/tag each data value along with a
> corresponding time stamp, so you have to give some of the space savings back
> ... and I would imagine to do this efficiently (space and time) could lead
> to some pretty complicated errr sophisticated logging code.  I'm not saying
> that's bad, but this is a pretty complicated proposal I think when you start
> digging into the details.

In fact, frames of tagged values is the same method we're already
using in encoding data for multiplayer transmission. Though that
module could also do with some improvements (*yikes* it's currently
packing each 8bit string character into a 32bit value for
transmission). Also, it doesn't reduce traffic by detecting unchanged
values yet (UDP transmissions loose some data, so that's more tricky
here, though also not impossible).

Yes, the tags are additional overhead. But I'm quite convinced that
this schemes outweighs the disadvantage - if we used this to encode
changing values only. I checked our current recording data structure:
it has a huge size of 1160 bytes for every frame. Also, the fixed
structure needs to reserve space for the maximum number of
wheels/engines/tanks etc - so even if an a/c has fewer tanks/.., it
still uses up the space. And it doesn't work for aircraft which
somehow exceed the default (btw, I saw a maximum of 4 tanks and 3
wheels is configured, so that is why there are gear replay issues with
4 or 5-gear aircraft, like the Concorde...). And looking at many of
the recorded properties, I think many of them indeed will hardly ever
change from frame to frame, so this 1K structure could probably be
reduced significantly - despite extra tagging bytes.

Thinking about it, it should also be possible to join some of the
multiplayer and replay code. The replay system could use the existing
encoder of the multiplay manager to generate the data packets - but
then record them locally instead of transmitting them via UDP. During
replay, these packets could then also be decoded by existing
multiplayer code. Might be worth a thought, if someone wanted to dig
in this area.

cheers,
Thorsten

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel