Re: [Flightgear-devel] jitters testing
Jim Wilson writes: Maybe anti-aliasing would fix the problem, but it seems that the only reasonable way to get rid of this is to make the cockpit a special case model and overlay it after all the scenery, etc. is rendered (without the position/orientation transformations). On the other hand I'm not sure that this is a good idea as a perfectly stable cockpit that does not jitter at all wouldn't be realistic either. This is a problem that will diminish in the future with higher-resolution displays. One pixel in current resolutions is still too big a minimum step, so jittering is noticeable. 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] jitters testing
Curtis L. Olson writes: It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. On the contrary, the instrument and the 3D cockpit jitter. It's the 2D panel overlaid that appears to be stable. 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] jitters testing
Andy Ross writes: The panel doesn't (er, didn't) jitter because it's drawn via an entirely different code path that doesn't look at aircraft orientation at all -- only viewing offsets. If you apply my current 3D panel code, you'll see the whole cockpit assembly wiggle in exactly the same way. On that point, I've tried your patch and it works, but the YASim FDM is then (inexplicably) frozen. Is it working for anyone else? 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] jitters testing
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. This theory doesn't work though. Think about it: in cockpit mode, the orientation of the aircraft is bolted to the FDM orientation. If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. No it would not. The scenery is too far away. Further pixels require bigger values to shift. Distance makes a huge difference. The c172 cockpit doesn't appear to jitter much until you turn to the right and look at the headrest on the co-pilot's seat. The A-4 cockpit is much tighter and the panel is that much closer to the camera. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
David Megginson [EMAIL PROTECTED] said:
On that point, I've tried your patch and it works, but the YASim FDM
is then (inexplicably) frozen. Is it working for anyone else?
This is a bug that seems to be related to some sort of memory corruption.
I've seen it off and on over the last couple of weeks when applying various
updates.
Try clamping the delta time in the FGInterface::_calc_multiloop() as follows:
if (dt 10 || dt 0) {
dt = 1;
}
Of course this doesn't correct the underlying problem, but it probably isn't
a bad thing to have in there anyway. What I do know about the problem is
that the delta time appears correct until we get inside this function. Why it
changes, I don't know.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
This can be caused by the value of remaining in FG interface not initialized as I wrote earlier. It makes _calc_multiloop return 0 and freeze FDM and animations Cheers, -Fred Messsage du 27/06/2002 13:30 De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copie à : Objet : Re: [Flightgear-devel] jitters testing Andy Ross writes: The panel doesn't (er, didn't) jitter because it's drawn via an entirely different code path that doesn't look at aircraft orientation at all -- only viewing offsets. If you apply my current 3D panel code, you'll see the whole cockpit assembly wiggle in exactly the same way. On that point, I've tried your patch and it works, but the YASim FDM is then (inexplicably) frozen. Is it working for anyone else? 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson wrote: Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. This theory doesn't work though. Think about it: in cockpit mode, the orientation of the aircraft is bolted to the FDM orientation. If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. No it would not. The scenery is too far away. Further pixels require bigger values to shift. Distance makes a huge difference. The c172 cockpit doesn't appear to jitter much until you turn to the right and look at the headrest on the co-pilot's seat. The A-4 cockpit is much tighter and the panel is that much closer to the camera. Well, _position_ jitter would hardly affect the scenery, but orientation jitter (if it is orientation about the eye-point) would show up in equal amounts on everything that is affected by it. It's not something silly like the /sim/panel/jitter property being non-zero, is it? Nah... that would be too silly. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] jitters testing
Jim Wilson writes: Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. This theory doesn't work though. Think about it: in cockpit mode, the orientation of the aircraft is bolted to the FDM orientation. If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. No it would not. The scenery is too far away. Further pixels require bigger values to shift. Distance makes a huge difference. The c172 cockpit doesn't appear to jitter much until you turn to the right and look at the headrest on the co-pilot's seat. The A-4 cockpit is much tighter and the panel is that much closer to the camera. I have to admit that I DON'T know how FGFS draws things anymore but Is this due to the calling of global_tile_mgr.update() twice in the Main Loop and causing 'confusion' as to what is the 'current' and the 'next' scenery center ?? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
[EMAIL PROTECTED] writes: It's not something silly like the /sim/panel/jitter property being non-zero, is it? Nah... that would be too silly. That would have no effect on the aircraft model. 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] jitters testing
Norman Vine [EMAIL PROTECTED] said: I have to admit that I DON'T know how FGFS draws things anymore but Is this due to the calling of global_tile_mgr.update() twice in the Main Loop and causing 'confusion' as to what is the 'current' and the 'next' scenery center No and IIRC that call is not duplicated when you are in the cockpit. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
[EMAIL PROTECTED] said: Well, _position_ jitter would hardly affect the scenery, but orientation jitter (if it is orientation about the eye-point) would show up in equal amounts on everything that is affected by it. That is correct, if your screen resolution was extremely high or the image anti-aliased. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson wrote: Andy Ross said: If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. No it would not. The scenery is too far away. Further pixels require bigger values to shift. Distance makes a huge difference. That's true for position jitter, but not for orientation. But even if it's position, the jitter should still cause a change in position of the scenery, not the cockpit. Remember that the cockpit *is* the aircraft -- no matter what the position is, it is always nailed down to the pilot's viewpoint position by definition. But the scenery is always perfectly fine, even the runway right next to the aircraft (not much farther than the cockpit) is rock solid. Really, I don't see any other options -- whatever is causing the jitter is inside the model's scene graph, and not under the scenery. Since the FDM output goes into both, you have to rule it out (or you can put printf's in the update routines and verify that inter-frame distances are never more than 0.1mm or so). Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: On that point, I've tried your patch and it works, but the YASim FDM is then (inexplicably) frozen. Is it working for anyone else? This is a bug that seems to be related to some sort of memory corruption. I've seen it off and on over the last couple of weeks when applying various updates. I saw it once, but unfortunately didn't track it far enough. It's since stopped happening to me. David, if you're getting this repeatably, would you mind tracing the bad values in gdb with a watchpoint? That is, figure out where the bad value comes from, set a watch point at its address* (e.g. watch *((int*)variable)) and re-run the program? If it turns out to be set via another garbage value, then set a watch point there, etc... Ultimately you should get to obviously incorrect code, like a variable that never gets set at all. This is tedious, but reasonably algorithmic. I wish I'd looked harder when it hit me last week; I saw the buffer overflow and just assumed that the garbage was normal behavior. Andy * Not the variable itself -- the address only. I've seen gdb get confused and miss watchpoint changes when watching variable names; maybe it's misoptimizing something? This doesn't help if the address changes across reruns, but in my experience that's actually pretty rare. The bad values are usually already bad during initialization, and initialization is a deterministric process. -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Andy Ross writes: Really, I don't see any other options -- whatever is causing the jitter is inside the model's scene graph, and not under the scenery. Since the FDM output goes into both, you have to rule it out (or you can put printf's in the update routines and verify that inter-frame distances are never more than 0.1mm or so). For what it's worth, I believe I can see the model jittering by a small amount from the chase view (zoomed way in.) Regards, Curt. -- 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] jitters testing
Andy Ross writes: I saw it once, but unfortunately didn't track it far enough. It's since stopped happening to me. David, if you're getting this repeatably, would you mind tracing the bad values in gdb with a watchpoint? I can no longer repeat it. 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] jitters testing
Curtis L. Olson writes: For what it's worth, I believe I can see the model jittering by a small amount from the chase view (zoomed way in.) That surprises me more. In interior view, the model is in a separate scene graph with a different clip plane, but in exterior view, it's just another node in the scenery tree. 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] jitters testing
David Megginson wrote: Speaking of taunting, do you have any ideas about the problem I mentioned earlier -- that no text shows up on the radios in your new 3D panel patch? It's the only thing stopping me from committing it. None yet, I need to get home and try it. Nothing looks suspicious; I thought perhaps plib was overriding the glPolygonOffset that I'm using, but it doesn't seem to be. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Andy Ross [EMAIL PROTECTED] said: That's true for position jitter, but not for orientation. But even if it's position, the jitter should still cause a change in position of the scenery, not the cockpit. Remember that the cockpit *is* the aircraft -- no matter what the position is, it is always nailed down to the pilot's viewpoint position by definition. Well that's sort of what I suggested in an earlier message could be done (basically just overlay the scenery with a cockpit and camera set to 0,0,0). What you say may be true by definition, but not in flightgear. In flight gear the aircraft is positioned in the world and the pilot's eye is positioned in the world. The eye just happens to be in the cockpit when in the pilot view. Since the FDM output goes into both, you have to rule it out (or you can put printf's in the update routines and verify that inter-frame distances are never more than 0.1mm or so). Except when flying at 400knots :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Andy Ross writes: David Megginson wrote: Speaking of taunting, do you have any ideas about the problem I mentioned earlier -- that no text shows up on the radios in your new 3D panel patch? It's the only thing stopping me from committing it. None yet, I need to get home and try it. Nothing looks suspicious; I thought perhaps plib was overriding the glPolygonOffset that I'm using, but it doesn't seem to be. I should mention before we get too far that glPolygonOffset is not always consistantly implimented across cards/drivers. It might not be as big a problem for us if we are viewing the panel mostly perpendicularly, but for objects that could be viewed from just about any angle, you will wind up needing different parameters to make things work for different cards. I believe some earlier voodoo cards/drivers didn't even impliment glPolygonOffset (I could be wrong on that.) It's at least something that we should proceed with carefully and test on a couple different cards (voodoo3/geforce/ati at least) before we really become dependent on using this opengl feature. Regards, Curt. -- 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] jitters testing
David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: For what it's worth, I believe I can see the model jittering by a small amount from the chase view (zoomed way in.) That surprises me more. In interior view, the model is in a separate scene graph with a different clip plane, but in exterior view, it's just another node in the scenery tree. It does. I checked last night. Being in seperate ssg roots makes no difference. The whole scene jitters all the time. You just can't see it because the scaled movement is less than a pixel once you get more than a couple feet away. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Curtis L. Olson wrote: I should mention before we get too far that glPolygonOffset is not always consistantly implimented across cards/drivers. Is that really true anymore? I know it used to be true ~5 years ago in the era of QuakeGL, but today things are really quite stable. The glPolygonOffset mechanism is the basis for doing multipass rendering, and multipass is pervasive. Are there really any platforms today (that can run FlightGear acceptably) that don't have a solid PolygonOffset implementation? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Andy Ross writes: Curtis L. Olson wrote: I should mention before we get too far that glPolygonOffset is not always consistantly implimented across cards/drivers. Is that really true anymore? I know it used to be true ~5 years ago in the era of QuakeGL, but today things are really quite stable. The glPolygonOffset mechanism is the basis for doing multipass rendering, and multipass is pervasive. Are there really any platforms today (that can run FlightGear acceptably) that don't have a solid PolygonOffset implementation? I've never used this function myself but I'm pretty sure it works on GeForce cards. I would assume that it worked on ATI cards (although they might require different parameter tweaking to achieve the same results.) The issue is that the parameters you pass to glPolygonOffset tie into the internal implimentation of the card which is obviously different from vendor to vendor and thus you will likely see at least some rendering differences with the same parameter set if you use a different card. The one I'd be most concerned about is the Voodoo/3dfx line of cards. I think if it works ok there we should be good because it should also work on all other modern cards. But we may need to tweak the actual parameters for each card (maybe/maybe not) but if so that could get a little cumbersome. Regards, Curt. -- 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] jitters testing
Jim Wilson writes: Setting all the view offsets to 0 I was able to prove that the position/rotation matrices generated on the model and the camera are numerically identical. Here's a sample from the dump: POS Aircraft 0.823776 -0.150286 -0.546632 0.00 0.468893 0.722572 0.507965 0.00 0.318641 -0.674762 0.665706 0.00 5064.624023 590.030945 -1211.297729 1.00 VIEW From 0.468893 0.722572 0.507965 0.00 -0.823776 0.150286 0.546632 0.00 0.318641 -0.674762 0.665706 0.00 5064.624023 590.030945 -1211.297729 1.00 POS Aircraft 0.823778 -0.150284 -0.546631 0.00 0.468911 0.722528 0.508011 0.00 0.318610 -0.674809 0.665673 0.00 5064.621582 590.031433 -1211.296509 1.00 VIEW From 0.468911 0.722528 0.508011 0.00 -0.823778 0.150284 0.546631 0.00 0.318610 -0.674809 0.665673 0.00 5064.621582 590.031433 -1211.296509 1.00 Note that one is applied to the object and the other the camera. If you look closely you'll see that the numbers in sync. This is only a couple of iterations, but the values don't diverge over time either. With no offsets what so ever to either the model or the camera the jitters are still there (I modified a model in order to observe the jitters at 0,0,0 offset). The jitters are also there in Chase View so it has nothing to do with rendering the cockpit in a seperate ssg root. This tells me the problem is most likely in plib, or at least plib is where we send these numbers. Plib for the most part is a very thin layer on top of opengl so these matricies are probably getting sent directly to opengl so most likely we are achieving some sort of numerical precision problem that is affecting opengl. This sort of thing probably isn't a bug with plib. Regards, Curt. -- 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] jitters testing
Jim Wilson [EMAIL PROTECTED] said: This tells me the problem is most likely in plib, or at least plib is where we send these numbers. On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. The variations are probably correct, but the way 3D rendering works you get what appears to be a jump when a pixel boundry is crossed. This is clearest when testing with the magic carpet fdm. Maybe anti-aliasing would fix the problem, but it seems that the only reasonable way to get rid of this is to make the cockpit a special case model and overlay it after all the scenery, etc. is rendered (without the position/orientation transformations). On the other hand I'm not sure that this is a good idea as a perfectly stable cockpit that does not jitter at all wouldn't be realistic either. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson writes: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. The variations are probably correct, but the way 3D rendering works you get what appears to be a jump when a pixel boundry is crossed. This is clearest when testing with the magic carpet fdm. Maybe anti-aliasing would fix the problem, but it seems that the only reasonable way to get rid of this is to make the cockpit a special case model and overlay it after all the scenery, etc. is rendered (without the position/orientation transformations). On the other hand I'm not sure that this is a good idea as a perfectly stable cockpit that does not jitter at all wouldn't be realistic either. It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. Curt. -- 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] jitters testing
Jim Wilson wrote: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. This theory doesn't work though. Think about it: in cockpit mode, the orientation of the aircraft is bolted to the FDM orientation. If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. Conversely, in tower view, the scenery should stay put while the aircraft jitters. But it doesn't, the aircraft geometry jitters here too. So the problem somewhere in the model's scene graph; there really aren't any other places it could hide that I can think of. Could you give us a quick rundown of exactly which matrices or ssgTransforms get added to the scene graph and where they come from? I started tracing this out but got distracted by the glut font stuff (different discussion entirely). :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Curtis L. Olson wrote: It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. Actually, the whole cockpit is jittering. The ball just has more high-frequency information to catch your eye. The panel doesn't (er, didn't) jitter because it's drawn via an entirely different code path that doesn't look at aircraft orientation at all -- only viewing offsets. If you apply my current 3D panel code, you'll see the whole cockpit assembly wiggle in exactly the same way. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson writes: Curtis L. Olson [EMAIL PROTECTED] said: It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. That's an optical illusion. Turn off the panel and you'll see that the whole cockpit jitters in unison. I actually think it'll be ok once we remove the 2D panel all together. Ok, you are right, the entire 3d aircraft model is jittering. That points to a discrepancy between the model position and the view position (or some rounding or numerical precision issue.) If the view position and model position matched exactly, there shouldn't be any jitter. Curt. -- 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
