RE: [Flightgear-devel] Propeller animation speed fix
Jon Berndt writes: I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Currently, we have FGSubsystem::update (int dt) where dt represents the elapsed time in ms since the last update. That puts a limit of 2^31 ms, or just under 600 hours, between updates. It has the advantage of keeping us in integer math, and the disadvantage of not being able to represent a granularity of under 1ms. That's OK for a simulator involving human interaction, since we cannot notice such a small difference, but it would obviously be a problem for other kinds of simulations such as rapid chemical reactions. So, what do we do? John mentioned that reporting in sec rather than ms is standard, so do we switch to FGSubsystem::update (double dt_sec) or do we simply rename dt to elapsed_ms FGSubsystem::update (int elapsed_ms) or do stick with ms but allow finer granularity FGSubsystem::update (double elapsed_ms) ? I don't see any harm in sticking with the integer value, but I agree that a better name, proper documentation, and some debugging is essential. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Propeller animation speed fix
? I don't see any harm in sticking with the integer value, but I agree that a better name, proper documentation, and some debugging is essential. This is true - particularly about documentation. Inline comments would help, too. I prefer (and we will continue to do this for JSBSim) that dt stands for delta T in seconds. It can be used directly that way, as it is in a prime unit. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Propeller animation speed fix
On Fri, 2002-05-03 at 04:20, Jon Berndt wrote: ? I don't see any harm in sticking with the integer value, but I agree that a better name, proper documentation, and some debugging is essential. This is true - particularly about documentation. Inline comments would help, too. I prefer (and we will continue to do this for JSBSim) that dt stands for delta T in seconds. It can be used directly that way, as it is in a prime unit. That's delta seconds per frame, not total elapsed. Jon -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
David Megginson wrote: Jon Berndt writes: I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Currently, we have FGSubsystem::update (int dt) where dt represents the elapsed time in ms since the last update. That puts a limit of 2^31 ms, or just under 600 hours, between updates. It has the advantage of keeping us in integer math, and the disadvantage of not being able to represent a granularity of under 1ms. That's OK for a simulator involving human interaction, since we cannot notice such a small difference, but it would obviously be a problem for other kinds of simulations such as rapid chemical reactions. As soon as something depends on the dt it's quite likely that it involves floats. And one of the most common uses of dt is for integration. As integration summs the values up one wrong value is enough to make all following results wrong, too (*). So I want (as I wrote some time ago, too), that a float or double dt in the unit second gets passed to the update functions/methods. So, what do we do? John mentioned that reporting in sec rather than ms is standard, so do we switch to FGSubsystem::update (double dt_sec) Yes or do we simply rename dt to elapsed_ms FGSubsystem::update (int elapsed_ms) No, there we'll get problems when we need a accurate dt. And offering a int elapsed_ms as well as a double dt doesn't make much sense IMHO. or do stick with ms but allow finer granularity FGSubsystem::update (double elapsed_ms) No. Stick to the standard. And when I get ms I probably still want sec (or hour or µs or whatever). So let the modules do the work to get the correctly shaped value, we can only guess (and guess it wrong) ? I don't see any harm in sticking with the integer value, I do. but I agree that a better name, proper documentation, and some debugging is essential. That's definitely a requirement. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
I think I agree. When we go about fixing this up, I think we should pass a dt to the modules which would be in units = seconds and of type double. Regards, Curt. Christian Mayer writes: David Megginson wrote: Jon Berndt writes: I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Currently, we have FGSubsystem::update (int dt) where dt represents the elapsed time in ms since the last update. That puts a limit of 2^31 ms, or just under 600 hours, between updates. It has the advantage of keeping us in integer math, and the disadvantage of not being able to represent a granularity of under 1ms. That's OK for a simulator involving human interaction, since we cannot notice such a small difference, but it would obviously be a problem for other kinds of simulations such as rapid chemical reactions. As soon as something depends on the dt it's quite likely that it involves floats. And one of the most common uses of dt is for integration. As integration summs the values up one wrong value is enough to make all following results wrong, too (*). So I want (as I wrote some time ago, too), that a float or double dt in the unit second gets passed to the update functions/methods. So, what do we do? John mentioned that reporting in sec rather than ms is standard, so do we switch to FGSubsystem::update (double dt_sec) Yes or do we simply rename dt to elapsed_ms FGSubsystem::update (int elapsed_ms) No, there we'll get problems when we need a accurate dt. And offering a int elapsed_ms as well as a double dt doesn't make much sense IMHO. or do stick with ms but allow finer granularity FGSubsystem::update (double elapsed_ms) No. Stick to the standard. And when I get ms I probably still want sec (or hour or µs or whatever). So let the modules do the work to get the correctly shaped value, we can only guess (and guess it wrong) ? I don't see any harm in sticking with the integer value, I do. but I agree that a better name, proper documentation, and some debugging is essential. That's definitely a requirement. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
On Thu, 2 May 2002 23:23:53 -0500, Jon Berndt [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: This is ridiculous. dt is short for delta T. In a 100 Hz simulation, the corresponding dt is 0.04. For 120 Hz it's 0.00833. For people that do simulation for a living this is one of the *most* recognized parameters around. ..I the blacklisted aero engineer who turned gas guru... http://www.crest.org/discussion/gasification/199903/msg00055.html ...and newbie coder wanna-be, would have _guessed_ so. Or _assumed_ so. Etc. Which _is_ wrong. ..Andy, who coded Yasim here, figured something else he found (_too_) reasonable, so he used that. And yasim _works_. ..we come from _all_ walks of life. So we need to _know_. Not guess, believe, have faith in, assume etc. ..best way is to put it in the docs, along with all the other dumb questions. And ask everyone to read it, and holler if something is missing, or write then if we do know the missing answers. ;-) Jon almost assuredly meant dt = .01 for 100 Hz or dt = .04 for 25 Hz or he was testing us. :) I haven't been getting much sleep lately. ..famous last words. ;-) I was remembering first how the F-16 sim at Link was run at 25 Hz, which is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's right ;-) Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. Thanks. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Billboard animation
I've just checked in changes to add a billboard animation to FlightGear 3D models. The billboard animation causes an object (or entire model) to rotate towards the camera about its z-axis and, optionally, its x-axis as well. Here's the XML wrapper for a sample billboarded tree (only 4 vertices) in $FG_ROOT/Models/Trees/billboard-tree.xml: PropertyList pathbillboard-tree.ac/path animation typebillboard/type sphericalfalse/spherical /animation /PropertyList The 'spherical' property is false (the default) for objects with only cylindrical symmetry, like trees, and true for objects with spherical symmetry, like simplistic clouds. Feel free to play with the sample tree and to compare it to the non-billboarded tree. I don't know which approach would be better for an entire forest: 1. The non-billboarded tree has 18 vertices (or so), but doesn't require any special dynamic transformation. 2. The billboarded tree has only 4 vertices, but requires a transformation based on the view matrix. Norm: which do you think would be more efficient for a forest of, say, 500 trees? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Billboard animation
David Megginson writes: Feel free to play with the sample tree and to compare it to the non-billboarded tree. I don't know which approach would be better for an entire forest: 1. The non-billboarded tree has 18 vertices (or so), but doesn't require any special dynamic transformation. 2. The billboarded tree has only 4 vertices, but requires a transformation based on the view matrix. Norm: which do you think would be more efficient for a forest of, say, 500 trees? It probably depends . Hardware assisted OpenGL can be hard to predict But I am guessing you already know the answer, on your machine at least :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
