[prev in list] [next in list] [prev in thread] [next in thread]
List: flightgear-devel
Subject: Re: [Flightgear-devel] Replay system
From: Curtis Olson <curtolson () gmail ! com>
Date: 2011-03-31 22:34:43
Message-ID: BANLkTimCM2H7gWM2xXifVsYAq0LxS8oEdg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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<http://www.flightgear.org/blogs/category/personal/curt/>
[Attachment #5 (text/html)]
On Thu, Mar 31, 2011 at 5:08 PM, ThorstenB wrote:<br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Streaming data to \
disc would be nice - but should be optional and not be</div>
enabled by default. It would also be nice to have an option to save a<br>
recorded instant replay buffer (when you haven't enabled the<br>
stream-to-disc feature earlier).<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;">I can't comment on the \
different interpolation methods. But what would<br> also help is to change the \
recording scheme:<br> Currently the valuesof a fixed set of properties is recorded at \
each<br> frame. However, most properties rarely change. Only the a/c position and<br>
speed properties tend to change in every frame. Properties like gear<br>
position and control surfaces are almost constant (from frame to frame).<br>
So, it might be a good idea to record all properties in an interval of a<br>
few seconds only, while only recording properties that have actually<br>
changed with every frame. That should allow to drastically reduce the<br>
amount of recorded data - and allow much longer high resolution memory<br>
recordings. And you could still fast-forward within the buffer, since<br>
you'll have a complete set of properties every now and then. It's a<br>
simple but effective compression method which is used in many \
areas.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">It would also be nice to support recording of custom \
properties. We<br> already have a similar solution for multiplayer mode. If the \
replay<br> system recorded the same properties configured in the \
"aircraft-set.xml"<br> (the "generic" int/float/string \
properties), it would mean a nice<br> improvement. It would also have other \
advantages, such as allowing<br> simple tests of an aircraft's multiplayer \
configuration.<br></blockquote><div><br></div><div>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 \
....</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">Indeed. That \
feature would also be nice for "normal flight". I never</div> understood \
why the tower view sticks to the initial airport. Switching<br> to the \
"departure airport's tower view" doesn't make much sense after \
a<br> long distance flight. A general "use nearest tower" option would be \
nice.<br></blockquote><div><br></div><div>No one has written the code to auto-switch \
the tower -- I think it's as simple as that.</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">I don't think anyone is working in these areas right \
now. So if you are<br> (or anyone else is) interested on working on these, let us \
know.<br></blockquote><div><br></div><div>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.</div>
<div><br>Regards,</div><div><br>Curt.</div></div>-- <br>Curtis Olson:<div><a \
href="http://www.atiak.com" target="_blank">http://www.atiak.com</a> - <a \
href="http://aem.umn.edu/~uav/" target="_blank">http://aem.umn.edu/~uav/</a><div>
<a href="http://www.flightgear.org" target="_blank">http://www.flightgear.org</a> - \
<a href="http://www.flightgear.org/blogs/category/personal/curt/" \
target="_blank">http://gallinazo.flightgear.org</a></div></div><br>
------------------------------------------------------------------------------
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic