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
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
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
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
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
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
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
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
[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/
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
[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
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
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
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
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
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
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;
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
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.
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
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
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
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
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
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
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
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
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
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
29 matches
Mail list logo
