Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
David Megginson writes:
He means texture animations (moving the UV coordinates around).
Probably easier to use pbuffers or the equivalent on those platforms
that don't support pbuffers
ie reconstruct the texture each
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
Then what does ssgTexTrans:: support?
It controls the texture transform
google( glMatrixMode GL_TEXTURE )
That's correct, but I haven't used that. My reading is you can apply matrices
to rotate and translate the texture mapping
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
Then what does ssgTexTrans:: support?
It controls the texture transform
google( glMatrixMode GL_TEXTURE )
That's correct, but I haven't used that. My reading is you can apply matrices
to rotate
Norman Vine wrote:
In the case of a 3D cockpit there may be a good use for this
in building the texture up but the main problem I see is still
going to be polygon offset related, so I am suggesting that
a better approach might be to bind to textureObjects rather
then an actual texture and
Norman Vine writes:
Norman Vine wrote:
In the case of a 3D cockpit there may be a good use for this
in building the texture up but the main problem I see is still
going to be polygon offset related, so I am suggesting that
a better approach might be to bind to textureObjects rather
Curtis L. Olson writes:
One of the knocks against programs like Fly and MSFS is their horribly
slow instrument update rate.
I will confirm that comment on FLY. The panel operation is great for
startup, etc., but it's basically unusable for IFR because of the slow
update.
All the best,
Curtis L. Olson writes:
Norman Vine writes:
This method should also be *considerably* faster then the current
Panel code in that the actual updating of the instruments can be
done on a round robin basis reducing the work done per pass as
all but the instrument texture being
Norman Vine writes:
If we can half the frame rate hit of the Panel using this kind of scheme,
and I expect even a better boost, then we could render half the instruments
one frame and the other half the next and still have the ~same instrument
update rate as we currently have and an
David Megginson writes:
Norman Vine writes:
If we can half the frame rate hit of the Panel using this kind of scheme,
and I expect even a better boost, then we could render half the instruments
one frame and the other half the next and still have the ~same instrument
update rate
Norman Vine writes:
also note I think we would all be happy with a 15hz instrument update
if it meant we went from a 30hz to a 60hz screen refresh rate :-)
For VFR, usually; for IFR, never. Even in VFR, we have to watch the
instruments closely sometimes -- on final approach, I want the
On Fri, 2002-12-20 at 09:58, Norman Vine wrote:
David Megginson writes:
Norman Vine writes:
If we can half the frame rate hit of the Panel using this kind of scheme,
and I expect even a better boost, then we could render half the instruments
one frame and the other half the
Tony Peden writes:
I think you'll find that once turbulence is introduced, this won't be
true at all. Maintaining straight and level flight in even light
turbulence requires the pilot (or autopilot) to constantly scan the
instruments and make adjustments.
That won't affect oil pressure
Tony Peden writes:
ie in quasi steady flight conditions most instruments would probably go
minutes before needing a refresh esp. if we were smart about the delta
value that required an update.
I think you'll find that once turbulence is introduced, this won't
be true at all.
Norman Vine writes:
That won't affect oil pressure temp gas gauges ect :-)
If I ever find a plane without a wobbly gas gauge, I'll let you know.
The point is well taken, though. The question is whether there's
enough potential saving left to bother.
All the best,
David
--
David
David Megginson
It's hard to picture any
situation (other than parked with the engine off) where the main six
and the mag compass won't need updating every frame.
I respectfully disagree
I think you would be surprised at how steady some gauges
are when sampled at 30 hz and displayed at the
Norman Vine writes:
Anything that has built in damping, air pressure controlled devices ect,
probably have no need to be sampled at anything greater then 5 hz
unless you are flying thru a tornado :-)
Needles start to look very awkward below 20 fps -- that's one reason I
like FlightGear so
On Fri, 2002-12-20 at 15:18, Norman Vine wrote:
Tony Peden writes:
I think you'll find that once turbulence is introduced, this won't be
true at all. Maintaining straight and level flight in even light
turbulence requires the pilot (or autopilot) to constantly scan the
instruments
On Fri, 2002-12-20 at 16:08, Norman Vine wrote:
David Megginson
It's hard to picture any
situation (other than parked with the engine off) where the main six
and the mag compass won't need updating every frame.
I respectfully disagree
I think you would be surprised at how steady
David Megginson
You can spot a
trend with a needle much faster than you can read an absolute value,
and to fly steady, you really have to work hard to damp out the
movement.
I agree and with my proposal you would see a deflection once
the required 'delta' was reached. I am assuming that
Tony Peden writes:
On Fri, 2002-12-20 at 16:08, Norman Vine wrote:
Anything that has built in damping, air pressure controlled devices ect,
probably have no need to be sampled at anything greater then 5 hz
unless you are flying thru a tornado :-)
This won't be as true for aircraft
On Fri, 2002-12-20 at 19:22, Norman Vine wrote:
Tony Peden writes:
On Fri, 2002-12-20 at 16:08, Norman Vine wrote:
Anything that has built in damping, air pressure controlled devices ect,
probably have no need to be sampled at anything greater then 5 hz
unless you are flying
Tony Peden
No matter how sophisticated the ECS may be, it can only react to changes
in the aircraft state ...
or sensor state :-)
Aside from all that whatever lags or damping may exist should be modeled
by the code for the individual instrument. It shouldn't arise from lack
of sample
Norman Vine wrote:
sample rate will remain exactly the same with my proposed scheme
Actually if the proposed scheme has a higher fps the sample rate will
increase accordingly also
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Norman Vine writes:
PPE just uses the conversion code from PLIB it does no additional massaging
ie it is the same as
ssgModelPath ( data ) ;
ssgTexturePath ( data ) ;
ssgEntity *my_obj = ssgLoad( my_obj.mdl ) ;
ssgSaveAC(my_obj.ac,my_obj);
Right, with a little extra
Michael Selig writes:
Panels -- From what I can gather, Chuck Dome is a real pro at making MSFS
panels. If those can be converted to FGFS, then we would have a slew of
panels to pick from because if asked I am pretty sure he would GPL them
like he has w/ the models.
Many of his
David Megginson writes:
Michael Selig writes:
Panels -- From what I can gather, Chuck Dome is a real pro at making MSFS
panels. If those can be converted to FGFS, then we would have a slew of
panels to pick from because if asked I am pretty sure he would GPL them
like he has w/
David Megginson [EMAIL PROTECTED] said:
We could make use of the instrument textures for certain. We're
tending to move away from 2D panels in FlightGear and towards 3D
panels in the aircraft itself, but there's still room for both.
Can't imagine using anything more than the textures
Jim Wilson writes
Two things we really need for doing real 3D instrument work is texture
transforms and text for things like radio, gps and atari ferrari displays.
not sure I follow you here
texture will just transform with the underlying geometry
and text is just another texture
norman
Norman Vine writes:
Two things we really need for doing real 3D instrument work is texture
transforms and text for things like radio, gps and atari ferrari displays.
not sure I follow you here
texture will just transform with the underlying geometry
and text is just another texture
Norman Vine [EMAIL PROTECTED] writes :
Jim Wilson writes
Two things we really need for doing real 3D instrument work is texture
transforms and text for things like radio, gps and atari ferrari displays.
not sure I follow you here
texture will just transform with the underlying geometry
David Megginson writes:
Norman Vine writes:
Two things we really need for doing real 3D instrument work is texture
transforms and text for things like radio, gps and atari ferrari displays.
not sure I follow you here
texture will just transform with the underlying geometry
Norman Vine [EMAIL PROTECTED] said:
David Megginson writes:
He means texture animations (moving the UV coordinates around).
Probably easier to use pbuffers or the equivalent on those platforms
that don't support pbuffers
ie reconstruct the texture each frame with OpenGL calls
and
Norman Vine [EMAIL PROTECTED] said:
and text is just another texture
Right, I'm just thinking about something like the text layer in the 2D panel,
except that it is applied a poly that is part of a 3D model. The texture gets
regenerated each frame.
Best,
Jim
Michael Selig [EMAIL PROTECTED] said:
Chuck Dome has OK'ed our use of his models w/ FlightGear. Here's a list of
his ~70+ aircraft that he has GPL'd:
http://www.fs2000.org/dome/index.htm
This list grows w/ updates coming from:
http://home.cfl.rr.com/cdfss/
This is great! But we need
Jim Wilson writes:
Now when converting from mdl to ac3d using ppe (which _maybe_ isn't the same
thing as just loading the mdl)
PPE just uses the conversion code from PLIB it does no additional massaging
ie it is the same as
ssgModelPath ( data ) ;
ssgTexturePath ( data ) ;
ssgEntity
At 12/18/02, Jim Wilson wrote:
Michael Selig [EMAIL PROTECTED] said:
Chuck Dome has OK'ed our use of his models w/ FlightGear. Here's a
list of
his ~70+ aircraft that he has GPL'd:
http://www.fs2000.org/dome/index.htm
This list grows w/ updates coming from:
http://home.cfl.rr.com/cdfss/
Michael Selig writes:
Panels -- From what I can gather, Chuck Dome is a real pro at making MSFS
panels. If those can be converted to FGFS, then we would have a slew of
panels to pick from because if asked I am pretty sure he would GPL them
like he has w/ the models.
Many of his panels
Michael Selig [EMAIL PROTECTED] said:
Thank you for this explanation. It reminds me now of some past comments
from you along these lines.
I was hoping for the answer use this code to convert the files, but
things are not so simple unfortunately.
If you are handy at scripting you might
Jim Wilson writes:
Michael Selig [EMAIL PROTECTED] said:
Thank you for this explanation. It reminds me now of some past comments
from you along these lines.
I was hoping for the answer use this code to convert the files, but
things are not so simple unfortunately.
If you are
Chuck Dome has OK'ed our use of his models w/ FlightGear. Here's a list of
his ~70+ aircraft that he has GPL'd:
http://www.fs2000.org/dome/index.htm
This list grows w/ updates coming from:
http://home.cfl.rr.com/cdfss/
Unfortunately, these newer MSFS models (FS2000/2002) are not FlightGear
40 matches
Mail list logo
