Norman Vine wrote:
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
Maybe you could convince every one by supplying some patches ...
:-)
Erik
___
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]
http:/
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 samp
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 yo
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
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
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
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
> > inst
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
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 th
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 Megginso
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 a
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 pressur
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 o
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 upd
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
> > u
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
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
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,
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
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
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 app
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 text
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 reconstru
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
___
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 ca
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 underlyi
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 underlyi
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
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
_
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
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 h
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
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
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.
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 yo
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 pan
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/
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" ) ;
ssg
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
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
fri
41 matches
Mail list logo
