[Flightgear-devel] FW: [gts-general] New Project Annoucement - TriAero

2005-12-08 Thread Norman Vine
FYI

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Sriram
 Rallabhandi
 Sent: Wednesday, December 07, 2005 5:53 PM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: [gts-general] New Project Annoucement - TriAero
 
 
 All,
 
 I am pleased to announce the unveiling and open-source release of the
 TriAero suite of simple aerodynamics analysis programs developed
 primarily with GTS (Thanks Stephane!) as the backbone. The TriAero
 programs are unstructured versions of the standard linearized
 aerodynamic codes used in conceptual/preliminary design. There are four
 modules bundled under TriAero - Trisurf, Triwave, Trifrict and Trishabp.
 
 TriSurf -- A program to create an unstructured wetted surface from a
 wire-frame (*.hrm) file. The Boolean operations aren't 100% robust, but
 it does pretty well.
 
 TriWave -- An unstructured Harris wave drag code. Unlike AWAVE (Harris
 Wave drag program), it properly and easily represents the shape  volume
 of an aircraft.
 
 TriFrict -- An unstructured skin friction drag code.  Local wetted-area
  Reynolds number for each major component are calculated  the skin
 friction drag is summed.  Very simple, but slightly more complex
 versions may be easily implemented.
 
 TriSHABP -- A clever unstructured input file preparer for S/HABP, the
 Gentry Hypersonic Impact program.  S/HABP is by nature structured, but
 it contains a redundant hierarchy in the input structure.  This
 redundancy is used to generate unstructured input files.  This program
 is very immature and may not deserve the 1.0 label, however it does
 serve as a proof of concept for unstructured S/HABP input file generation.
 
 Please refer to the webpage, http://triaero.sourceforge.net for further
 details.
 
 These modules have been written as a part of my thesis work, where I
 have created many geometries and tried to optimize their shape using
 genetic algorithms. I have many aircraft geometries which failed during
 the GTS Boolean operations :). As GTS improves, so will TriAero. If any
 of the GTS developers need some of these failed geometries for debugging
 purposes, I would be glad to share them with you.
 
 I welcome all of you to look at the TriAero project and use it according
 to your need. All suggestions for improvements are welcome.
 
 Once again welcome to the TriAero Project.
 
 Regards,
 Sriram
 begin:vcard
fn:Sriram Rallabhandi
n:Rallabhandi;Sriram
org:Georgia Institute of Technology;Aerospace Engineering
adr;dom:;;;Atlanta;GA
email;internet:[EMAIL PROTECTED]
title:Postdoctoral Fellow
tel;work:404 385 4252
version:2.1
end:vcard

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Possible new thinking for 2D/3D cockpitinstruments

2005-12-01 Thread Norman Vine
Steve Hosgood writes:

 Makes me wonder whether there's an excuse for some new thinking on the
 subject of UI design, regardless of whether a cockpit is 3D or 2D.
 Here's what I propose - please be kind with your comments, I'm not
 trying to dictate terms or tread on anyone's toes:

 Flightgear (and any other flight sim) is trying to reproduce the
 experience of flying, both in terms of the flight dynamics and (to a
 limited extent) the whole experience.

 As such, many of the instruments in the virtual cockpit can be
 configured with mouse-clicks on the instruments themselves. Some can
 also be configured through dialog boxes.

 If FG wants to try and model the flight experience, these alternative
 dialog-box UIs must go. There are no pull-down menus on a real plane,
 and no dialog-boxes. Providing them therefore breaks the flight
 experience.

Steve

I agree that it would be nice to have all instruments etc have interactive
interfaces ala a mouse click, if that is at all realistic, but this does not 
necessarily
mean that the dialog boxes should go.

Please note the following from  http://www.flightgear.org/introduction.html

The goal of the FlightGear project is to create a sophisticated flight 
simulator framework for use in research or academic
environments, for the development and pursuit of other interesting flight 
simulation ideas, and as an end-user application. We are
developing a sophisticated, open simulation framework that can be expanded and 
improved upon by anyone interested in contributing.

Is a much broader vision then a first person experience of flight !!

So if you don't want to use the menu or dialog box interface don't
and they won't spoil your experience  :-)

Cheers

Norman


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] OpenGL and new video card

2005-12-01 Thread Norman Vine
Jon Berndt writes:
 
 I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. 
 Unfortunately,
 now OpenGL apps give an application error - they don't even start up. I'm 
 trying to get
 some answers out of the card and driver manufacturer, but if anyone here has 
 any
 suggestions, I'd appreciate hearing them

Try installing the latest driver from NVIDIA
http://www.nvidia.com/object/winxp_2k_81.95.html

HTH

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Possible new thinking for 2D/3Dcockpitinstruments

2005-12-01 Thread Norman Vine
Steve  Hosgood writes:
 
 Agreed, but if we've got a better scheme, why keep the dialog boxes?
 Every disjoint aspect to the GUI is just another thing waiting to go
 wrong, as with the Cessna autopilot where the dialog box is invisibly
 disconnected from the real autopilot.

Steve 

Apparently I wasn't clear in my initital response

FlightGear is more then just a first person sim

These other uses may have reasons to want 

dialog box displays.

Again  if you don't ike the dialog boxes don't use them

but please do not advocate taking them away.

FWIW they are also the simplest interface to build and 

as such are useful in development and debugging

Cheers

Norman 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] [BUG] earth rotational axis poked a hole inthe planet?

2005-11-06 Thread Norman Vine
Mathias Fröhlich writes:

 On Samstag 05 November 2005 17:21, Vassilii Khachaturov wrote:
  With either jsbsim or yasim aircraft, when is in the vicinity of the
  (North) pole, the AGL (as seen in the HUD) goes into 2*10^7 ranges. You
  can either start up with --lat=90 (and any longtitude you please), or, if
  you dislike the singularity of --lat=90 at the startup, use --lat=88 and
  head north. Soon past 89 degrees you'll see it happening. (I initially
  discovered it by trying to start up with santa at the pole :) ).
 
  When this happens, one can fly below earth (altitude-wise, as indicated on
  the altimeter) down and down w/o a problem on an aircraft (like hunter)
  that doesn't allow it normally.
 
  I don't think this is a particuarly annoying aspect of the flightgear
  universe, but maybe somebody will get a hint to another bug from this
  report.
 It is just that there is no scenery for that area, I think.

 The poles have a singularity in the lat/lon/altitude coordinate system. That
 singularity might be the reason these places do not even have a water
 surface, at least I guess that reason ...

The code use to have this test which prevented you from getting *too* close
to the pole and seemed to work well enough

note: one second of latitude is approx 20 meters

void sgGeocToGeod( const double lat_geoc, const double radius,
   double *lat_geod, double *alt, double 
*sea_level_r )
{
 
if( ( (PI_OVER_2 - lat_geoc)  SG_ONE_SECOND )// near North pole
  || ( (PI_OVER_2 + lat_geoc)  SG_ONE_SECOND ) )   // near 
South pole
{
*lat_geod = lat_geoc;
*sea_level_r = Geocent_a*E;
*alt = radius - *sea_level_r;
} else {

Not sure if an equiv test is included in the current code

Of course all of this nonsense could be avoided if latitude and longitude were
not used for internal representaion.  eg  use Cartesian XYZ form instead

Norman


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: gui dialogs: selecting buttons via keyboard

2005-11-05 Thread Norman Vine
 Melchior FRANZ wrote:
 
  I thought it might be advisable to make Ctrl-q the key for exiting
  from fgfs (like it's standard in almost all GUI apps I know), and Esc
  the key for canceling/dismissing/closing dialogs.

Alt-F4  is the key used for the this on the *vast* majority of programs  :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] wish list for next release

2005-10-30 Thread Norman Vine


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Dave Culp
 Sent: Sunday, October 30, 2005 7:55 AM
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] wish list for next release
 
 
  Ow, that I'm not sure of.
  I guess it would be better to backport this code to support 2D panels
  also then.
 
 
 The only thing lacking in the 2D code now is the ability rotate, translate, 
 and *then* crop a texture.  Maybe it would be required that the texture be 
 drawn to a context in memory, rotated, translated, and then cropped and drawn 
 to the screen?
 
 It's unlikely that I'll be learning OpenGL in the next few years, so it would 
 be *really* great if someone could look into this issue.  This would finally 
 make the 2D panel code complete.

I am not really up to speed with the Panels but ...

FG_SRC / cockpit / panel.hxx

/**
 * A transformation for a layer.
 */
class FGPanelTransformation : public SGConditional
{
public:

  enum Type {
XSHIFT,
YSHIFT,
ROTATION
  };

  FGPanelTransformation ();
  virtual ~FGPanelTransformation ();

  Type type;
  const SGPropertyNode * node;
  float min;
  float max;
  bool has_mod;
  float mod;
  float factor;
  float offset;
  SGInterpTable * table;
};

seems to have what you need

Maybe it just needs to be exposed better

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] CVS compiling error

2005-10-20 Thread Norman Vine
Erik Hofman
 
 David Luff wrote:
 
  Fair point.  Do you know if HUGE is part of a standard anywhere that
  definately should be supplied by Cygwin, or is it simply available from
  everyone else by unwritten convention?
 
 According to the IRIX header file it would be an ANSI definition.

IRIX  that is almost as compliant as MSDOS derivitaives where HUGE 
is a reserved word  :-)

This is an anachronism from mixed memory model programing on Intel 

Norman



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: A question regarding accurate taxiways

2005-10-17 Thread Norman Vine
Erik Hofman writes:
 
 Martin Spott wrote:
 
  So: However somebody is going to design a new airports description
  format we always should have a method to merge Robin's updates.
  Additionally we need someone who tracks these updates on a regular
  basis because we don't want to loose a nifty feature that some X-Plane
  user adds to Robin's database.
 
 This can be done by requesting a new designator number as an alternative 
 taxiway entry. That way it would be possible to have both the old and 
 new format available in the file.

Doesn't that just create another problem ?

Now the tools will need to check for duplicates a notoriously
tricky thing todo with GeoSpatial data

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: A question regarding accurate taxiways

2005-10-17 Thread Norman Vine
Erik Hofman writes:
 
 Martin Spott wrote:
 
  Additionally we need junctions if the plan should make sense. Junctions
  like this one:
 
 When carefully designed this could be done with the quad approach 
 (although it would not be easy). So the data should be quad based.
 It is up to the taxidraw developers on how to make it easy for the user.

I vote for everything being triangle based like the underlying renderer

Note this implicitly includes quads and is much more versatile
 
Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] HUD fonts for Norman Vine

2005-10-11 Thread Norman Vine
 
 The problem is I need to change the font that is showing on my HUD
 to make it larger (and brighter).  I cannot figure out where this is done.
 It seems to refer back to properties in some way, but I can't find where
 the lever is.  If I change the sizes in the programs in Cockpit, nothing
 happens.  If the program is not using the GL fonts, what is it using and
 how does one change one or more instances in the HUD? 

The HUD uses PLIB Fonts these are *much* faster then the Glut Fonts

The code has been considerably reworked, albeit a  long time ago, 
since I implemented the PLIB Font mechanisms.

That said I believe you want to look at hud.hxx

class fgText {
  
void Draw(fntRenderer *fnt,int digits) {


HTH

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Rita

2005-09-21 Thread Norman Vine
Jon Berndt writes: 
 
 I'll likely be relatively sparse on the Internet for the next week or so - 
 perhaps much,
 much longer depending on how things go in League City, due to Rita. I'm about 
 14 feet
 above sea level, about a mile inland from Galveston Bay.
 
 Anyone else look like they're going to be affected by this?

Not directly but we will be continuing the effort desctibed here
http://www.onlamp.com/pub/wlg/7807

Best

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: Custom scenery integration

2005-08-13 Thread Norman Vine
 
 Martin Spott wrote:
 
  Does osgPlanet allow for contour lines for elevation data instead of
  DEM's ? 

No

FYI osgPlanet questions better asked on the OSSIM list.
http://mailman.remotesensing.org/mailman/listinfo/ossim

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]

2005-07-22 Thread Norman Vine
You should find everything you need to replace the objectional 
code here

http://www.stjarnhimlen.se/comp/sunriset.c

/* +++Date last modified: 05-Jul-1997 */

/*

SUNRISET.C - computes Sun rise/set times, start/end of twilight, and
 the length of the day at any date and latitude

Written as DAYLEN.C, 1989-08-16

Modified to SUNRISET.C, 1992-12-01

(c) Paul Schlyter, 1989, 1992

Released to the public domain by Paul Schlyter, December 1992

*/

Norman

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman
 Sent: Friday, July 22, 2005 12:09 PM
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
 
 
 Steve Hosgood wrote:
 
  Xearth also spawned my own hack xmars, but since Xplanet does
  everything in the solar system, I now consider xmars defunct.
 
 Since you are already familiar with this stuff, I need the function to 
 calculate the sun position (in degrees or radians) above the horizon at 
 a certain time/lat/lon. What is this normally called: RightAscension, 
 Declination, Magnitude or something else?
 
 Erik
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Cirrus SR20 Model?

2005-07-21 Thread Norman Vine
Curtis L. Olson writes:
 
 If it helps motivate someone, he might be able to come up with a small 
 amount of $$$ to do the job, but in this case, if he's spending his own 
 money, he wants to own the result.

soap box
I suggest mentioning the Free as in beer analogy might get
the itch solved more quickly

Or that someone interested in building this model might consider
a dual license for it 

eg  Free for Open Source programs but a Commercial license for
commercial programs
/soap box

Norman


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: Code Typo?

2005-07-07 Thread Norman Vine
Melchior FRANZ writes:
 
 * Patrick Quirk -- Wednesday 06 July 2005 21:50:
  In file Main/viewer.cxx, in function MakeVIEW_OFFSET(...), on line ~118 
  where the third matrix is being made, there is the following line:
 [...]
  Since this is making the third matrix from the third angle, shouldn't 
  this line be:
  
  tmp = t * axis3[1];
 
 Yes. According to Norman this is probably a bug. Fix committed. It looks,
 though, as it doesn't make much difference. A big relief at least for
 people like me, who are better at pattern recognition, than at vector
 stuff.  ;-)

But even though thecomment says this code is mine
this is in an additition to my original code
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/src/Main/viewer.cxx.diff?r1=1.14r2=1.15cvsroot=FlightGear-0.9

HTH

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: Custom scenery integration

2005-07-04 Thread Norman Vine
Martin Spott writes:
 
 Ralf Gerlich wrote:
 
  I don't see why we need to store elevation data for the whole world in 
  the database anyway. I wouldn't think elevation data would be a typical 
  subject for user-submitted modifications related to wide areas. If more 
  detailed structures are desired than provided by the DEM data, 
  corrective contour data for small areas could be stored in the database 
  and be combined with the official DEM data, which could be stored 
  outside the database.
 
 Great, this is almost exactly what Frederic and I discussed while
 talking about his intended reorganization of FGSD  :-)

The beauty of storing things in a DB is that you can easily have
a history of the changes, maintain metadata, and have an easier
way to serve the data thru OGC Standard Interfaces.

Also once you start making any changes you have to go thru the DB 
Interface anyway unless you just modify the originals.  

Then again since FGFS is just a g 'game' /g

Also who knows Native PostGIS support for Raster Data may not be all 
that far in the future :-)

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: Custom scenery integration

2005-07-04 Thread Norman Vine
Ralf Gerlich writes:
 
 My point was that we don't have to store the DEM data in raster format. 
 As long as there is no PostGIS support for raster data, we either need 
 to store the raster data outside of PostGIS or store it as vector data 
 such as contours.

I agree you don't have to but there are advantages to doing so,  the way you 
do this is to store the DEM as a BLOB whose polygon is a PostGIS object.

Note this allows you to use PostGIS spatial functions

Any way just a suggestion for a way to bring TerraGear into the world
of the main stream Open Source GIS standards

Norman



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: Custom scenery integration (was: Re: [Flightgear-devel] Re:[Terragear-devel])

2005-07-03 Thread Norman Vine
Ralf Gerlich writes:
 
 Hello,
 
 Martin Spott schrieb:
   [SNIP]
  Actually, I _do_ agree that having preprocessed scenery
  _is_ an advantage. But it does have disadvantages as well:
  1.) At the current state it appears (to me) nearly impossible to inject
  user-contributed additions into the scenery,
  2.) I don't manage to build the necessary tools on my server   ;-))
 
 Share your problems with us, perhaps we can help ;-)
 
  Maybe the way to go might be to make it easier for everyone to build
  the tools (and to simplify the process of scenery generation) and to
  add his personal scenery improvements using common open GIS file
  formats but keep the preprocessed scenery as we are already used to it.
 
 I'm currently working on some more detailed scenery data 
 
 I'm using GRASS (http://grass.itc.it) for digitising and the preliminary 
 results are quite interesting regarding better orientation - at least 
 for a local ;-)
 
 I had to write an additional tool to get linedata imported from GRASS to 
 TerraGear, but actually with all the support libraries available this is 
 far from complex :-)
 
 Most of the exporting and scenery generation tasks is automated using 
 scripts and a single configuration file.

This sounds great,  Grass is a powerful tool. 

IMO the most useful approach would be modifying TerraGear to use 
PostGIS instead of the File System.  Then one could use tools like
Grass and UDig directlly on the data stream.  For that matter it would
be interesting to investigate using PostGIS to store the FGFS Scenery
directly.  

Hmm this is starting to sound a lot like something that osgPlanet could
render too :-)

Cheers

Norman



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: Custom scenery integration

2005-07-03 Thread Norman Vine
Martin Spott writes:
 
 By definition you can transform the current VMAP0 data, which comes in
 the so called VPF format, into shapefiles. In order to achieve this you
 need OGR and the OGDI VPF driver (Norman, please correct me if I'm
 wrong). 

The same set of tool scan be used to go directly to PostGIS without
teh intermediary shapefile step.
 
 Once we have the landcover data in a PostGIS database we are enabled to
 manually adjust roads and rivers, add ponds like the one in front of
 the Oracle building and send everything to Curt for the scenery
 generation   if someone adds a Shapefile or PostGIS driver to
 TerraGear which replaces the current VMAP0 importer.
 
 I'm currently uncertain if we really can store the _whole_ scenery in
 PostGIS. Our elevation data currently comes as raster data but maybe
 it makes sense to convert that into contour lines - which we finally
 can store in such a database as well. Does this make sense, Norman, or
 will this eliminate our ability to alter the data with 'common' tools ?

Why not just store the Elevation data in a mixed record type of a
Polygon with a  BLOB field ?

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: [Terragear-devel]

2005-07-02 Thread Norman Vine
Martin Spott writes:
 
 Norman Vine wrote:
 
  Because it has only recently been released  see
  http://radar.oreilly.com/archives/2005/06/os_gis_conferen.html
 
 Yep, I talked to Jan-Oliver Wagner who attended your presentation and
 was deeply impressed  ;-)

It is a neat 'toy' (1) and should run on any system that can run FlightGear.

Cheers

Norman

 toy refers to the osgplanetviewer example application 
   the underlying library is a reasonably rigourous mapping 
   engine 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] About 3D Clouds

2005-07-01 Thread Norman Vine

Harald JOHNSEN writes:
 
 Apparently there is no stencil in 16 bpp mode.
 Can someone check if there is an alpha channel in 16bpp mode and how 
 many bits in it ?

There is a 5 5 5 1  where 5 bits per color and one bit alpha mode

GL_RGB5_A1

#define  GL_UNSIGNED_SHORT_5_5_5_1 0x8034

example usage
glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB5_A1, IMAGE_SIZE_X, IMAGE_SIZE_Y, 0, 
GL_RGBA, GL_UNSIGNED_SHORT_5_5_5_1, 0L );

HTH

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] readXML problems

2005-06-28 Thread Norman Vine
Erik Hofman writes:
 
 Are you calling readXML while another call to readXML is in progress? 

Can't be done unless this other call is in a different thread :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] OpenAL for CygWin

2005-06-14 Thread Norman Vine
I have placed a compiled tarball of yesterdays OpenAL CVS files @
http://www.vso.cape.com/~nhv/files/cygwin/cyg_openAL.tgz

you might want to test these against the current FGFS before
blindly overwriting your currrent installation

Norman
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] OpenAL for CygWin

2005-05-30 Thread Norman Vine
Vivian Meazza writes:
 
 Jon Berndt wrote:
 
  
  I'm finally getting around to reinstalling FlightGear after a hard drive
  crash a couple
  months ago. I have this as a place to get OpenAL for Cygwin:
  
  http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz
  
  Is this still the latest/best dist?
  

I no longer have that file on my site

Please delete any links to it 

and use this one instead 
 
 Try this version:
 
 ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz

Thanks

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Cygwin slowness

2005-05-28 Thread Norman Vine
Erik Hofman writes:
 
 bass pumped wrote:
 Well, I submitted it.  Alas, it didn't go well.  You can follow the
 flame war here:
 
  http://cygwin.com/ml/cygwin/2005-05/threads.html#01305
  
  I just read that...   that guy certainly has a problem!!!
 
 Tell me about it, I've worked with such an individual for more than five 
 years. If they don't think there's a problem then everybody else has.
 
 I can only say; don't use cygwin as long as this person is involved.

With due respect Cygwin is a *high* volume list with well documented 
protocols with prominent links on its home page  for submitting problems.
http://cygwin.com/problems.html 

FWIW I think these apply here
http://www.catb.org/~esr/faqs/smart-questions.html#id3001405
http://www.catb.org/~esr/faqs/smart-questions.html#keepcool

I suggest you see the follow ups to this
http://cygwin.com/ml/cygwin/2005-05/msg01317.html
rather then continue an uniformed off list flame

Then again we can have another GlutFest or Or PlibBash
which is bound to be productive :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Cygwin slowness

2005-05-28 Thread Norman Vine
Vivian Meazza writes:
 
 Andy Ross wrote:
 
  
  Erik Hofman wrote:
   Norman Vine wrote:
FWIW I think these apply here
http://www.catb.org/~esr/faqs/smart-questions.html#id3001405
http://www.catb.org/~esr/faqs/smart-questions.html#keepcool
  
   These two contradict (You can't offend them but they can offend you).
   It's a nice document on how to approach a three year old though.
  
  It's actually a pretty good guide.  The problem is I don't know how I
  could have followed it any better.  I mean, I *am* the hacker type ESR
  is talking about.
  
  The was, IMHO, a fantasy bug report:
  
  + A symptom so painfully obvious that no technical knowlege is
required to see it (1.6 seconds vs. 26 seconds run time)
  + Simple example code
  + Easily reproduced within a few commands
  + Requires no external dependencies (just gcc and the mingw libraries)
  + And a real world use case (us!) for why it's important that it be
fixed.
  
  To turn it around: could you imaging me responding to this bug report:
  
Here's a simple Nasal script that reduces my FPS to 2-3.
  
  with:
  
If it is really important to you, you should try to fix it rather
 than posting here and trying to get lucky. (pretty much exactly
 Chris's words).
  
  I mean, sometimes I'm lazy or forget stuff, but I'm generally pretty
  good about admitting when a bug is a bug.  That's my *job* as a
  developer.  Who does that job for cygwin?
  
 
 Well, that all generated more heat than light! I almost wish I hadn't set
 the hare running.
 
 I have never seen anyone react quite like this Faylor chap, from which I
 suppose:
 
 A. He already knew he has a problem with Cygwin's speed.
 
 B. He doesn't know how to fix it.
 
 C. We're unlikely to see it sorted any time soon.
 
 I'm more than willing to be proven wrong.
 
 Meanwhile, thanks to Andy for daring to enter the lion's den :-)

Cygwin is a bit of a lions den in that it has a *huge* user base.

Again I point folks to
http://cygwin.com/problems.html

And FWIW I think y'all are selling Chris short :-)
http://cygwin.com/ml/cygwin/2005-05/msg01329.html

I know it is easy to snipe off list but really :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: FlightGear startup time

2005-05-26 Thread Norman Vine
Martin Spott writes:
 
 Richard Bytheway wrote:
 
  Would it be possible to have a compiled form stroed on disk, which is
  automatically regenerated on startup of FGFS based on rules similar
  to make. If the ASCII version is newer than the compiled version,
  rebuild the compiled version.
 
 This is a very interesting approach that you present here - and
 probably the only one that doesn't destruct the whole idea of having
 human-adaptable configuration files. In my eyes _dropping_ ASCII XML
 files from the distribution should considered to be a no-go,

Dropping the ASCII XML files from the distribution is jsut as likely
and no less user friendly then dropping the source code files from
the distribution.

Just use the source Luke :-)

That said this is an excellent idea.  But I think that unlike C++ source
binary XML 'decompiles' into ASCII easily :-)

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: FlightGear startup time

2005-05-26 Thread Norman Vine
Martin Spott writes:
 
 Norman Vine wrote:
 
  Just use the source Luke :-)
 
 Yes, I do   right on the track to figure how much effort it would
 be to 'port' CWXML to IRIX/MIPSpro. Apparently they rely on having GCC
 as compiler on _every_ supported Unix platform.

You mean gcc isn't supported on IRIX ??

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] More startup speed work

2005-05-26 Thread Norman Vine
Andy Ross writes:
 
 
 Here's another startup speed patch (against plib this time) for
 windows users to try.

Nice one Andy  :-)

 Anyway, let me know if this produces any appreciable speedup under
 windows, and we can start the, ahem, bureacratic process of getting
 this into plib. :)

submit the patch 

I will see that it gets applied

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Potential startup speed fix

2005-05-26 Thread Norman Vine
 On Thursday 26 May 2005 22:48, Andy Ross wrote:
 
  Attached is a patch that pre-reads the directory contents ahead of
  time (currently that is a list of length zero) to avoid having to hit
  the kernel (twice!) for every airport.
 
  Under Linux, this doesn't provide much speedup.  But Windows (and
  especially the cygwin libraries) has a somewhat less robust I/O system
  in the face of many tiny operations.  Hopefully it will help there.
  Can someone on each of cygwin, mingw and/or MSVC try this out and see
  if it helps?

Hmm could you please whare with us what isn't 'robust' about the Cygwin 
file system.

It is slow compared to the Linux or Native Win32 file system in that it has to 
go 
thru an extra translation layer inorder to get Unix behaviour under Win32 
but . implying that Cygwin file operayions are not robust borders on pure 
fud

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: FlightGear startup time

2005-05-25 Thread Norman Vine
Gerard ROBIN writes:
 
   Durk Talsma wrote:
   
  Another issue that has been brought up a number of times is the ascii vs 
  binary file format disussion. While I absolutely believe that ascii/xml 
  files 
  are ideal for development work, combined they may have a pretty big impact 
  on 
  loading time. Therefore, would it be an idea to 'precompile' the .xml files 
  and use a binary version during runtime? I'm personally considering doing 
  this for the trafficManager files, because the parsing, initialization, and 
  checking against unknown airports is taking huge amounts of time. 
  
  Cheers,
  Durk
  
  
 I am, mainly a user.
 I do like fgfs, because of, direct access to data and parameters.
 ===It is not a game==
 The idea to precompile xml goes against that concept.
 
 I think: 
 on the game side, it is existing many others products which could answer
 to quick  startup and answer the players needs (products mainly
 closed)
 
 We can accept a delay when loading (the performance depends on the hard
 and soft configuration).

http://baron.flightgear.org/pipermail/flightgear-devel/2003-September/021434.html

I don't see the XML files as being any different then any other source file and 
source code needs to be compiled.

Thaks for bringing this up again :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] FlightGear startup time

2005-05-24 Thread Norman Vine
Vivian Meazza writes:
 
 Drew wrote
 
  FlightGear takes nearly a minute to start up from my Windows build,
  and I'm just wondering if there's an easy way to shorten this if I'm
  not using all of flightgear's features.  Is there one particular task
  that takes particularly long?
  
 
 Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for a brew
 a coffee - and that's on a pretty powerful machine. The majority of this
 time seems to be taken up by the loading of Airport and Navaid data. As I
 understand it, the program loads all that are available without regard for
 the location of the aircraft. Keeping this number to a minimum should help.
 The other variable under your control is the number of scenery objects, but
 this doesn't seem to take all that much tile anyway. 
 
 We really need to sort this one.

I adbandoned Cygwin for MingW years ago for just this reason

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: FlightGear startup time

2005-05-24 Thread Norman Vine
 
 * Drew -- Tuesday 24 May 2005 07:54:
  FlightGear takes nearly a minute to start up from my Windows build,
  and I'm just wondering if there's an easy way to shorten this if I'm
  not using all of flightgear's features.  Is there one particular task
  that takes particularly long?
 
 Because yesterday was the 200th bithday of the Wiener/Frankfurter/Hot-Dog
 sausage, I add my mustard (German saying; does probably not translate well :-)
 
 I know about the deficiencies of MICROS~1 Windos in general, but not about
 CygWin/MinG.

The problem is Cygwin emulates Posix streams and this adds significantly
to the overhead of stream based ops

The XML files require *many* stream ops

This addirional overhead is not present in MingW in that it uses
native Win32 streams.

I guess I should mention the deficiencies of non MSoft OSs but
I will leave the *flames* for another time :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: Re : [Flightgear-devel] Re: terrain elevation at a given position

2005-05-23 Thread Norman Vine
 BONNEVILLE David writes:
 
 That is the problem ;-)
 I am diving into SG code, but if Norman or somebody helped by Norman know 
 where
 i could find it, feel free to post a maessage :D

I haven't kept current with the code but AFAIK the elevation routines
live in FGFS / src / scenery / hitlist.xxx

The containing scenery tile for the point you are requesting elevation
for *must* be loaded into the scenegraph for these to work

I have forgotten exactly how to insure that an arbritrary tile is loaded 
and the code has probably changed anyway since I last worked on it

HTH

Norman
 
  But if you say at runtime, you possibly mean to get terrain elevation
  while flying, so you can't simply teleport the aircraft to some lon/lat
  just to read out a value. In this case you have to search for terrain
  intersecion code in sg. I'm no expert in that. But Norman has already
  pointed people there at several occasions, and you'll certainly find
  something about it in the archives.

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] SimGear as shared lib

2005-05-08 Thread Norman Vine
Jim Wilson writes:
 
 I think the real issue is that SimGear shouldn't be installed anywhere ever,  
 because it isn't a shared library (and 
 doesn't need to be).   It seems like it should be possible to fix the fgfs 
 build setup so that it just links libraries 
 right from the SimGear build directory.

or modify make install so that it emulates cp -p 

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New 3d clouds

2005-04-24 Thread Norman Vine
Erik Hofman writes:
  
 Another thing is that it seems to depend on glut functions which need to 
 be resolved for SDL users also.

Hmm...  a quick grep of the directory yields

f:\tmp\fgfs\SimGear\simgear\scene\sky\bbcache.cxx: #include SG_GLUT_H
f:\tmp\fgfs\SimGear\simgear\scene\sky\cloudfield.cxx: #include SG_GLUT_H
f:\tmp\fgfs\SimGear\simgear\scene\sky\newcloud.cxx: #include SG_GLUT_H

so it looks as if it is only that the headers are being included
but nothing is actually being used

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] AIManager and AIBase

2005-04-22 Thread Norman Vine

Not sure if I have pointed this out before or not

http://www.cert.fr/CERTI/

Currently Unix only but HLA would make a great addition 
to FGFS

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] YASim turbo/supercharger issues

2005-04-21 Thread Norman Vine
Andy Ross writes:
 
 Vivian Meazza wrote:
  I used the power form because it is easier to read, but if the other
  form produces a performance advantage, then of course we must use
  it.
 
 It's actually not so much about performance, really.  Readability can
 mean different things.  The problem is that when I see a trancendental
 function in code, I immediately start thinking that it much be some
 complicated formula typed in from a book, as these things don't occur
 in typical programmer's brains all that often.  Basically, even though
 in isolation it's easier to read pow(foo, 3) than foo*foo*foo,
 when you look at the whole expression, your original one is
 complicated to me:
 
   (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2))
+ (1.11 * rpm_norm);
 
 Whereas this one is just really obviously a polynomial, and I
 understand polynomials, they're simple and not scary at all:
 
rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25))
 
 I'll work up a version of the new one with the sign bug fixed, and try
 to get that checked in tonight.

Hmmm.

I find it all to easy to make silly mistakes with nested parentheticals
and usually avoid them unless absolutely needed


Python 2.4 (#1, Dec  4 2004, 20:10:33) 
[GCC 3.3.3 (cygwin special)] on cygwin
Type help, copyright, credits or license for more information.
 import math
 rpm_norm = 100
 a = (-0.25 * math.pow(rpm_norm,3)) + (-0.15 * math.pow(rpm_norm,2)) + (1.11 
 * rpm_norm)
 b = rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25))
 a == b
False
 a
-251389.0
 b
-152389.0
 rpm_norm_2 = rpm_norm*rpm_norm
 rpm_norm_3 = rpm_norm * rpm_norm_2
 c = (-0.25*rpm_norm_3) + (-0.15*rpm_norm_2) + (1.11*rpm_norm)
 a == c
True
 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] screen capture causes loss of control

2005-04-20 Thread Norman Vine
Curtis L. Olson writes:
 
 
 Hmmm, I wonder if this is a way to hide the cursor so it doesn't 
 appear in the screen shots?

Bingo !

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Building on Cygwin

2005-03-30 Thread Norman Vine
Vivian Meazza writes:
 Andy Ross wrote:
 
  Vivian Meazza wrote:
   I have the same problem with Main/renderer.cxx. Your solution (or
   one very like it) solves the problem. I guess near/far are reserved
   words in Cygwin?
  
  Goodness, that brings back memories.  The near and far keywords are
  holdovers from 16 bit DOS compilers.  They are still defined (as
  noops) for compatibility with ancient code.
 
 I'm amazed that you can remember all that! And so long ago! Very interesting
 explanation. Thanks.

That kind of pain is not easily forgotten :-)

Seriously 'near' and 'far' should be considered 'reserved words' that belong 
to the prehistoric days and be permanently banned from contemporary use 

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx

2005-03-27 Thread Norman Vine
On Mar 27, 2005, at 3:20 PM, Miles Gazic wrote:
Don't ever assume that all the components of a structure will be at the
same location within the struct on all architectures, or that the
structure size will be the same.  Processor architecture, language 
used,
compiler, and compiler flags all can change how a structure is packed.

That usually means that when an element of your structure is less than
the word size of the machine, it'll start the next element of the
structure at the next word boundary.  So if you have a char followed by
an int on a 32 bit machine, your compiler can decide to put the int 3
bytes after the char, instead of immediately following it.  Sometimes
you can change how things are packed by using compiler specific 
pragmas.
Sometimes you cannot.

- Miles
Excellent point however a responsable programmer can take this into 
account
when designing the data structures and account for this.  Again I point 
out the
myriad of image formats that demonstrate that you can successfully pass
structures over the Net.

Cheers
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Norman
Vine
Sent: Sunday, March 27, 2005 9:29 AM
To: FlightGear developers discussions
Subject: RE: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Paul Kahler writes:
Never block transfer a structure by providing a pointer and size,
there is simply no way for that to work cross-platform.
Please 
That this isn't true is amply demonstrated by all the images that get
passed around the net :-)
All one needs to do is make sure that the endian order of the data is
well defined !
There are many ways to do this perhaps the easiest is to just use a
'magic' cookie at the beginning of the data structure *or* have a well
defined structure that insures a certain endian order is imposed on the
creator.
Cheers
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Making FlightGear more deterministic

2005-03-04 Thread Norman Vine
Frederic Bouvier writes:
 
 Quoting Andy Ross:
 
  * Hopefully in a CPU-friendly way.  I know that older versions of
the NVidia drivers did this by spinning in a polling loop
inside the driver.  I'm not sure if this has been fixed or not.
 
 From my experience, the latest non-beta Windows NVidia driver seems to eat 
 CPU
 even with sync to vblank enabled. The CPU usage is always 100%.

Buried in the PPE sources is a 'hackish' but portable way to 
limit CPU usage if the desired framerate is met

  /*
Frame Rate Limiter.

This prevents any one 3D window from updating faster than
about 60Hz.  This saves a ton of CPU time on fast machines.

! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV !
  */

  static ulClock *ck = NULL ;

  if ( frame_rate_limiter )
  {
 if ( ck == NULL )
 {
   ck = new ulClock ;
   ck - update () ;
 }

 int t_ms = (int) ( ck-getDeltaTime() * 1000.0 ) ; /* Convert to ms */

 if ( t_ms  16 )
   ulMilliSecondSleep ( 16 - t_ms ) ;
  }

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Camera/FOV/View Frustum question.

2005-02-25 Thread Norman Vine
Curtis L. Olson writes:
 
 First let me explain what I need to do.  I need to configure an 
 asymmetric view frustum.  

..
 
 For what it's worth, I think the same issue is happening with the TR 
 tiled rendering routines that generate the ultra-highres tiled screen 
 shots ... that code suffers the same problem in view #0 with the outside 
 world seen through extreme overzoom (i.e. you only get a tiny, itsy, 
 bitty bit of the outside world expanded to fill the screen.)

Not very helpful but I think you are correct about this being the 
'same issue'

FWIW I never did figure out exactly what was causing this but IIRC 
this was a problem even when I implemented the TR view but was 
not an issue for me as I was only interested in the '2D' panel' if any 
when not in exterior view mode.

Norman



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] FW: [vtp] FW: Announce: Forum on Open Geodata, London, April 14th

2005-02-23 Thread Norman Vine


 -Original Message-
 From: Ben Discoe [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, February 23, 2005 4:58 PM
 To: [EMAIL PROTECTED]
 Subject: [vtp] FW: Announce: Forum on Open Geodata, London, April 14th
 
 
 
 I'm forwarded this announcement for those of you in the UK who are not on
 the freegis mailing list.
 -Ben
 
 -Original Message-
 From: Jo Walsh
 Sent: Wednesday, February 23, 2005 4:13 PM
 To: [EMAIL PROTECTED]
 
 List members concerned about the issue of access to state-owned geodata in
 the UK and Europe might find the following event interesting...
 
 Forum on Open Geo-Data
 ==
 
 == Where and When ==
   * When: Thurs April 14th 2005
   * Where:  Stanhope Centre, Marble Arch, London. 
 [http://www.stanhopecentre.org/about/directions.shtml Directions]
   * Who can attend: public. Registration is optional but useful so please
 notify us if you can via [EMAIL PROTECTED]
   * Who is speaking:
* Steve Coast ([http://openstreetmap.org openstreetmap])
* Roger Longhorn (geodata policy expert)
* Giles Lane ([http://socialtapestries.net social tapestries])
* Jo Walsh ([http://mappinghacks.com mapping hacks])
* TBC
 
 == Subject Matter ==
 
 ''One thing the projects in the civic information forum share, is a
 dependency for spatial information in their service; even if that's as
 simple as 'enter my postcode'...''
 
 The Open Knowledge Forum on geo-data is bringing together people working on
 free of copyright mapping and open geo-data projects, with those working on
 local government and NGO which need maps and spatial analysis.
 
 The UK is one of the best-mapped surfaces on the planet, but our national
 mapping resources are highly-priced and administered by a semi-private
 company that acts as a monopoly based on Crown Copyright.
 
 The Public Sector Information Directive emphasises the benefits and
 importance of access to geographic information. But local governments don't
 own the information they gather, and arguably millions are wasted providing
 expensive viewing services which present pictures of the data, instead of
 raw information.
 
 This forum will be a discussion about different applications with a civic
 society focus, such as participatory planning or problem reporting, which
 could be initially built using free base maps and geocoding facilities.
 
 For more information please see:
   * http://www.okfn.org/geo/
   * http://okfn.org/wiki/OpenKnowledgeForums
   * http://okfn.org/wiki/OpenGeoData
 
 
 
  
 Yahoo! Groups Links
 
 * To visit your group on the web, go to:
 http://groups.yahoo.com/group/vtp/
 
 * To unsubscribe from this group, send an email to:
 [EMAIL PROTECTED]
 
 * Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/
  
 
 
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] fgrun WIN32 double quoted path bug

2005-02-17 Thread Norman Vine
Geoff Air writes:
 
 I use msvc7, in XP, cygwin not installed, so also do not
 use pthreads ...

FYI  you do not need Cygwin to run with pthreads on Windows

see
http://sources.redhat.com/pthreads-win32/

Norman



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] SimGear CVS errors

2005-02-06 Thread Norman Vine
Frederic Bouvier writes:
 
  John Wojnaroski wrote:
 
  Started building a CVS version and bombed out in Simgear with the 
  following:
 
  RenderTexture.cpp: In method `RenderTexture::Render
  RenderTexture.cpp:151: `GLX_RENDER_TYPE_SGIX' undec
 
 
  RenderTexture.cpp:1774: `GLX_SGIX_pbuffer' undeclar
  RenderTexture.cpp:1779: `GLX_SGIX_fbconfig' undecla
  make[2]: *** [RenderTexture.o] Error 1
  make[1]: *** [install-recursive] Error 1
  make: *** [install-recursive] Error 1

 Perhaps John can enlight us on the system he use. My bet would be on 
 cygwin looking the way the error was clipped.

Here are my local changes to Simgear configure.ac that
should help in case John is on Cygwin and happens to have 
the XServer package installed

Norman


$ cvs diff -c configure.ac
Index: configure.ac
===
RCS file: /var/cvs/SimGear-0.3/source/configure.ac,v
retrieving revision 1.82
diff -c -r1.82 configure.ac
*** configure.ac18 Jan 2005 14:34:13 -  1.82
--- configure.ac6 Feb 2005 13:34:43 -
***
*** 121,127 

  dnl Determine an extra directories to add to include/lib search paths
  case ${host} in
! *-apple-darwin* | *-*-mingw32*)
  echo no EXTRA_DIRS for $host
  ;;

--- 121,127 

  dnl Determine an extra directories to add to include/lib search paths
  case ${host} in
! *-apple-darwin* | *-*-cygwin* | *-*-mingw32*)
  echo no EXTRA_DIRS for $host
  ;;

***
*** 258,264 
  case ${host} in
  *-*-cygwin* | *-*-mingw32*)
  dnl CygWin under Windoze.
!
  AC_SEARCH_LIBS(alGenBuffers, openal32)
  AC_SEARCH_LIBS(alutInit, [ openal32 ALut ] )
  LIBS=$LIBS -lwinmm -ldsound -ldxguid -lole32
--- 258,265 
  case ${host} in
  *-*-cygwin* | *-*-mingw32*)
  dnl CygWin under Windoze.
! INCLUDES=$INCLUDES -I/usr/local/include
! LIBS=$LIBS -L/usr/local/lib
  AC_SEARCH_LIBS(alGenBuffers, openal32)
  AC_SEARCH_LIBS(alutInit, [ openal32 ALut ] )
  LIBS=$LIBS -lwinmm -ldsound -ldxguid -lole32

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] SimGear CVS errors

2005-02-06 Thread Norman Vine
Giles  Robertson writes:
 
 In case anyone's interested, I have at times had to add -lwsock32 to
 LIBS to get some compiles working under mingw (with network programs).
 I forget if that's currently the case for FlightGear.

please use '-lws2_32'   it is a better library

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Simgear-cvs

2005-02-03 Thread Norman Vine
Vivian Meazza writes:
  
  Now Flightgear won't compile - stops as following:
  
  /usr/lib/gcc-lib/i686-pc-
  cygwin/3.3.3/../../../libplibjs.a(jsWindows.o)(.tex
  t+0
  5c9):jsWindows.cxx: undefined reference to [EMAIL PROTECTED]'
  collect2: ld returned 1 exit status
  make[2]: *** [js_demo.exe] Error 1
  
  I'm using plib 1.8.4. Any more good advice?
  
 
 I think I've worked around this one. I went back to an earlier cvs version
 compiled, then updated to today, and recompiled successfully. I don't know
 why that worked ... it's a computer :-)

A 'make clean; make' or maybe even just a 
 'cd $FGFS/src/Input; make clean; cd $FGFS; make' 
would probably have also worked.

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Simgear-cvs

2005-02-02 Thread Norman Vine
Vivian Meazza writes:
 
 I'm having a problem compiling Simgear-cvs under Cygwin. The compiler stops
 with the following error:
 
 In file included from soundmgr_openal.hxx:50,
  from xmlsound.hxx:40,
  from xmlsound.cxx:38:
 /usr/local/include/AL/alc.h:39: error: syntax error before `*' token
 /usr/local/include/AL/alc.h:51: error: `ALCcontext' was not declared in this
scope
 /usr/local/include/AL/alc.h:51: error: `alcHandle' was not declared in this
scope
 /usr/local/include/AL/alc.h:51: error: variable `ALCboolean
alcMakeContextCurrent' definition is marked dllimport.
 
 Thereafter follows a long list of similar errors.
 
 I would suppose that this is a consequence of Erik's latest improvements to
 the sound. We Cygwin users are still using Norman Vine's OpenAL stuff. 
 
 Any advice on fixing this?

Yes  I ran into this the other day  :-(

I changed a few defines in my AL/alc.h  and it seems to compile
but I don't have a soundcard on that machine so .

attached

Norman

alc.h
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Simgear-cvs

2005-02-02 Thread Norman Vine
Vivian

Haven't got time to investigate but I would try changing
line 4  alctypes.h

from
#if !defined(_WIN32)
to 
#if !defined(WIN32)

I won't be back online till late tonight

Norman

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Vivian
 Meazza
 Sent: Wednesday, February 02, 2005 5:55 AM
 To: 'FlightGear developers discussions'
 Subject: RE: [Flightgear-devel] Simgear-cvs
 
 
 Norman Vine wrote
 
 
  Vivian Meazza writes:
  
   I'm having a problem compiling Simgear-cvs under Cygwin. The compiler
  stops
   with the following error:
  
   In file included from soundmgr_openal.hxx:50,
from xmlsound.hxx:40,
from xmlsound.cxx:38:
   /usr/local/include/AL/alc.h:39: error: syntax error before `*' token
   /usr/local/include/AL/alc.h:51: error: `ALCcontext' was not declared in
  this
  scope
   /usr/local/include/AL/alc.h:51: error: `alcHandle' was not declared in
  this
  scope
   /usr/local/include/AL/alc.h:51: error: variable `ALCboolean
  alcMakeContextCurrent' definition is marked dllimport.
  
   Thereafter follows a long list of similar errors.
  
   I would suppose that this is a consequence of Erik's latest improvements
  to
   the sound. We Cygwin users are still using Norman Vine's OpenAL stuff.
  
   Any advice on fixing this?
  
  Yes  I ran into this the other day  :-(
  
  I changed a few defines in my AL/alc.h  and it seems to compile
  but I don't have a soundcard on that machine so .
  
 
 Close, but no coconut yet:
 
 In file included from soundmgr_openal.cxx:33:
 /usr/local/include/AL/alc.h:21: error: conflicting types for `typedef struct
ALCdevice_struct ALCdevice'
 /usr/local/include/AL/alctypes.h:6: error: previous declaration as `typedef
struct _AL_device ALCdevice'
 /usr/local/include/AL/alc.h:22: error: conflicting types for `typedef struct
ALCcontext_struct ALCcontext'
 /usr/local/include/AL/alctypes.h:8: error: previous declaration as `typedef
void ALCcontext'
 
 Something else needed?
 
 
 Thanks for your very rapid response, as usual
 
 Regards,
 
 Vivian
 
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)

2005-01-31 Thread Norman Vine
Jim Wilson writes:
 
 Norman Vine said:
 
  Jim Wilson writes:

   
   As far as the reason the existing alpha-blend code doesn't work may be 
   related
   to an update in 1.8.4 that was described in ChangeLog as smaller and 
   cleaner
   scene graphs.  That's just a WAG,  but it seems that this function would 
   be
   better accomplished through an API rather than writing directly back to
   scenegraph memory from SimGear anyway (I find it mildly irritating that 
   you
   can even do that :-/).
  
  My guess is that you aren't following the rules :-)
  http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node111.html
  
 
 You might be right.  From the above link, it says: If lighting is enabled,
 then the ambient and diffuse reflectance coefficients of the material should
 correspond to the translucency of the object.   So does this mean that when
 using the plib API it is necessary to set alpha in both the ambient _and_
 diffuse state colors?  I think I tried that but...
 
 ..for some reason I was seeing some bogus numbers ( 1.0 colors) come up for
 ambient when dumping the ssgLeaf objects concerned.  Maybe finding the source
 of that problem will fix things.

Hmm ...

I was alluding render ordering.

Note it could be that the 'optimization' code in ssgBranch.cxx is doing things
'behind your back' after loading that invalidates any assumptions about the 
render order being the inverse of the loading order. 
 not that you are necessarily making this assumption 

you are familiar with this
http://www.sjbaker.org/steve/omniv/alpha_sorting.html

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] [PATCH] Simgear support for emissive animationfor instruments (ver 2)

2005-01-30 Thread Norman Vine
Jim Wilson writes:
  
 
 As far as the reason the existing alpha-blend code doesn't work may be related
 to an update in 1.8.4 that was described in ChangeLog as smaller and cleaner
 scene graphs.  That's just a WAG,  but it seems that this function would be
 better accomplished through an API rather than writing directly back to
 scenegraph memory from SimGear anyway (I find it mildly irritating that you
 can even do that :-/).

My guess is that you aren't following the rules :-)
http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node111.html

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Runway lighting - What happened to the newterrain engine?

2005-01-29 Thread Norman Vine
Manuel Massing writes:
 
  It could be worthwhile looking into if we need to store large images.
  The SDK with source code is available at http://www.ermapper.com
 
 The terrain engine also supports the jasper JPEG2000 library. Unfortunately,
 the last time I tested, JPEG2000 decoding performed badly (in terms of
 runtime) compared to optimized JPEG decoding routines. 

The Jasper library is notoriously slow,  
You should at least test the ermapper library brfore you give
up on JPEG2000  :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored

2005-01-29 Thread Norman Vine
Geoff Air writes:
 
 Those who 'regularly' use system.fgfsrc, like I do,
 to control each run of FG, and use 'panel-less'
 aircraft, like ufo, have probably been 'adding' this
 patch to fg_init for 'years' ;=)) 

Oooh  it is not just me then who doesn't just 'use' 
all the eye candy :-)

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Runway lighting

2005-01-28 Thread Norman Vine
Erik Hofman wrote:
 
 The code to draw 
 untextured terrain has been removed some time ago.

Saddly :-(

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Runway lighting

2005-01-28 Thread Norman Vine


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman
 Sent: Friday, January 28, 2005 3:58 AM
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Runway lighting
 
 
 Ampere K. Hardraade wrote:
  How about not rendering ground textures at night?  Has this been done yet?
 
 I don't think turning off texturing makes any difference on common 
 hardware (including my O2, it will give me 1fps more). The code to draw 
 untextured terrain has been removed some time ago.
 
 Erik
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] How to convert from WGS84 coordinates?

2005-01-26 Thread Norman Vine
Robicd writes:
 
 I've found Geotrans Translator v.2.2.5 software; I tried using it for 
 converting from WGS84/NUTM33 to WGS84/Geodetic coordinates and I had 
 some not very good results.
 I don't know if I am making something wrong with that software or the 
 starting coordinates are not accurate (although they should be :-)
 I'll investigate more and download GDAL too. Let's see.
 
 Do you know Geotrans too? Is it of any value?

If this is the NIMA Geotans tool,  it is an excellent tool.

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] How to convert from WGS84 coordinates?

2005-01-25 Thread Norman Vine
Andy Ross writes:
 
 
  You're right, the picture shows a Projection field too. Complete infos are:
 
  Datum: WGS84
  Projection: NUTM33
 
  Coordinate top left
  x: 353620.2 y: 4225543.6
 
  Coordinate bottom right
  x: 354212.2 y: 4225976.1
 
 Those are odd looking numbers.  

These are UTM North Zone 33
http://www.dmap.co.uk/utmworld.htm

You probably will want to warp these into LatLon space
http://www.remotesensing.org/gdal/gdal_utilities.html#gdalwarp

is a quality tool for doing this,  there are others

HTH

Norman
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Terrain elevation question

2005-01-24 Thread Norman Vine
Curtis L. Olson writes:
 
 The terrain elevation system could stand to be looked at a bit.  I think 
 there is still a lurking bug where the wrong elevation can be returned 
 under some circumstances immediately after a tile boundary is crossed.  
 There are some optimizations in the current system that assume you are 
 reading ground elevation from the same tile or same position stream as 
 before.

My guess is one wants to look closely at the 'in airport', 'on airport border' 
and 'airport crosses tile boundary' cases.

Norman


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Terrain elevation question

2005-01-24 Thread Norman Vine
Durk Talsma writes:
 
 What I am really looking for is a hint where I can find the code in 
 FlightGear 
 that actually does these calculations. I tried tracing back through the 
 functions that eventually set the value of 
 the /environment/ground-elevation-m property, but couldn't really figure it 
 out. 

Durk

The code lives in 
$FGFS / scenery / 
  tilemanager.XXX
  hitlist.XXX

HTH

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] FG GUI toolkits

2005-01-23 Thread Norman Vine
Erik Hofman writes:
 
 Paul Surgeon wrote:
  Can someone comment on how FLTK works under OpenGL?
  
  Would it be possible to use FLTK and all it's nice widgets in FG and drop 
  the 
  rather crude PUI toolkit?
 
 To be honest, I did some small first steps in developing using fltk 
 recently and I didn't particularly like it (from a developers point of 
 view).

Nice thing about points of view is every one has one:-)

I actually appreciate FLTK's leaness and find it a joy to
work with in comparison to the do every thing nature of 
most of the other cross platform GUI kits.
 
 Also fltk works the other way around, you will have to design an fltk 
 program that displays OpenGL content.
 
 And third, I didn't think fltk allows one to display FlightGear in 
 full-screen mode, or does it?

Full screen mode is doable in FLTK
http://fltk.org/documentation.php/doc-1.1/Fl_Window.html#Fl_Window.fullscreen

FWIW when I used to run FGFS inside of PPE the FGFS GUI still worked 
as well as the PPE's FLTK GUI  and when PPE was in fullscreenmode:you 
didn't even know it was running  :-)

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] fgrun improvements

2005-01-21 Thread Norman Vine
Curtis L. Olson writes:
 
 Stewart Andreason wrote:
 
  Jim Wilson wrote:
 
  There are a couple bugs or at least they were there a week or so 
  ago.   One is
  just a mapping typo where latitude goes into both latitude and 
  altitude.   The
  other is under linux the fg-root and fg-scenery parameters don't get 
  saved and
  passed on to fgfs (no prefs.set done) unless you hit previous to display
  page[0] (the function that processes page[0] saves those strings).
 
 
  Ah, is this why fgfs get stuck in a freezing loop, when I give 
  latitude and longitude parameters at the command line?
 
  (Tries a few more runs)
  Ah! that's it. If I give a --lat that is less than the ground 
  elevation, it freezes in a loop. and ignores the --altitude parameter.
 
  I believe I reported this Jan.11, but had not figured out the exact 
  conditions that triggered it.
  Thanks Jim.
 
  A serious bug.
 
 
 I can explain the bug to you.  If you specify a lon/lat that lies on the 
 *exact* border between two tiles (i.e. --lat=90 --lon=45) then at 
 startup the ground intersection code can fail.  This means that the 
 scenery subsystem never returns a valid groud elevation.  Now the 
 problem is that the flight dynamics model *needs* to know the ground 
 elevation before it can position the aircraft.  Complicating the matter 
 is that when the FDM is first initialized the tiled scenery loader may 
 not have the current tile loaded yet.  So the FDM doesn't know if it's 
 in a dead lock state or if it just needs to wait a bit longer for the 
 threaded tile loader to catch up.
 
 The solution would be to make the ground intersection code more robust 
 to this boundary condition, but I believe that might be burried deep in 
 plib.

This might help

hitlist.cxx
inline static bool IN_RANGE( sgdVec3 v, double radius ) {
-return ( sgdScalarProductVec3(v, v)  (radius*radius) );
+return ( sgdScalarProductVec3(v, v) = ((radius*radius) +FLT_EPSILON) );
}

but I don't see where setting the lat less then the ground elevation 
has any bearing on this   this sounds more like a parsing error 

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] [OT] curve direction.

2005-01-20 Thread Norman Vine
Curtis L. Olson writes:
 
 This is kind of off today's topic, but I have an unrelated question.
 
 Working in 2d space, given 3 points, I know how to compute a circle 
 (center/radius) that passes through those three points.  Now I need to 
 compute the direction of curvature of the 3 points.  In other words, 
 moving from the 1st point through the second point to the 3rd point, is 
 the direction of the circle clockwise (curving right) or counter 
 clockwise (curving left.)

Classic problem with a classic solution :-)

grep clockwise on this page
http://exaflop.org/docs/cgafaq/cga6.html

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] splash screen

2005-01-16 Thread Norman Vine
maybe something like

static void fgIdleFunction ( void ) {
// printf(idle state == %d\n, idle_state);

if ( idle_state == 0 ) {
// Initialize the splash screen right away
if ( fgGetBool(/sim/startup/splash-screen) ) {
fgSplashInit(fgGetString(/sim/startup/splash-texture));
}

idle_state++;
} else {
if ( fgGetBool(/sim/startup/splash-screen) ) {
fgSplashUpdate(0.0, 1.0);
}   
}
if ( idle_state == 1 ) {




 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Jim Wilson
 Sent: Sunday, January 16, 2005 10:39 AM
 To: flightgear-devel@flightgear.org
 Subject: [Flightgear-devel] splash screen
 
 
 My guess is that there isn't anything quick and easy for this release,  but
 I'm wondering if anyone has ideas for getting the splash screen up on the
 screen faster.   Currently on my p4 2.4 it is taking 10 seconds for the splash
 screen to appear.  AFAIK all we need is the geometry and gamemode preferences
 to open the window.
 
 Best,
 
 Jim
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] May I help with scenery?

2005-01-13 Thread Norman Vine
Martin Spott writes:
 
 Martin Spott wrote:
 
  The tools to not only import VMAP0 data but GSHHS shorelines as well
  into a PostGIS database are already present. I think you also can use
  these tools to export back into VMAP0 or any other format.
 
 BTW, does anyone know which sort of agreement you have to sign when you
 intend to purchase the VMAP1 CD's ?
 
   http://www.mapability.com/info/vmap1_intro.html
 
 Myaybe you are free to use them as long as you dont' redistribute the
 data itself but only a derivated work instead (like FlightGear
 scnenery),

AFAIK all VMAP data is in the public domain unless classified

The purchase price is to cover distribution cost and the data

is freely redistributable.

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] May I help with scenery?

2005-01-12 Thread Norman Vine
Martin Spott writes:
 
 Norman Vine wrote:
 
  PostGIS can be used to serve a WFS or WCS that is built on top
  of the UMN Mapserver which will handle 'z' values just fine.
 
 Right, but this doesn't picture all the required features in this case.
 If we would erect a repository for manual scenery changes we would need
 to edit elevations inside the current data. To my knowledge, Mapserver
 is only one-way.

Right

don't know if this would help or not with grids
http://www.vividsolutions.com/jump/main.htm

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] May I help with scenery?

2005-01-12 Thread Norman Vine
Paul Surgeon writes:
 
 On Wednesday, 12 January 2005 10:29, Martin Spott wrote:
   One other possibility you might wanna consider is allowing uploads/
   dloads of terrain (e.g. tiles modified through fgsd).
 
  This is not as easy as it sounds because you'd have to redo the tiles
  on every scenery update. The right way to incorporate manual scenery
  changes would be to parametrize these changes and provide a method
  to add them to the automatic scenery build.
 
 Ideally all changes made to the terrain should be done at the source.
 i.e. VMAP0 and friends

No,  you do not change the source as it is a 'known' entity
You make changes in a copy of the source perhaps stored in a different format

 fgsd should be able to display, edit and save the vector data then use the 
 terrgear generation tools to build the new tile and display the results.
 
 One could have a live online central repository (db) that handles the storage.
 fgsd can connect, request a tile of vector data for editing (The db can do 
 some sort of locking on that tile to avoid simultaneous edits)
 Once the user is finished they upload the changes for everyone to use.

This is exactly why we are discussing PostGIS
 
 BTW : Does anyone know of a free VMAP0 editor for Linux?

No,  but Jump does many things including talking to PostGIS
as doew/will uDIG JUMPS successor
http://udig.refractions.net/

and there are several VMAP0 to shapefile translators and PostGIS
understands shapefiles

HTH

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] May I help with scenery?

2005-01-11 Thread Norman Vine
Martin Spott writes:
 
 Does anyone have experiences with portable GPS recievers ? Do they tend
 to increase the precision of their coordinate output if you remain at
 a location for several minutes ?

It depends but usually to some degree yes

It is a worthwhile experiment to plot the position of any GPS signal 
you are going to rely on over a 'longish' period of time at a fixed 
location occasionally, best if this is done at a 'known' spot  :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] May I help with scenery?

2005-01-11 Thread Norman Vine
Chris Metzler writes:

 I've been working
 on making a site in Zope that one can upload to/download from, with the
 intent of having pictures, a description, download links, and a comment
 log for each item. 

Cool !

Are you familiar with ZMapServer  ?
http://zmapserver.sourceforge.net/

If you want to play with it, a good place to ask questions
is  irc://irc.freenode.net/mapserver

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] alternative terrain engine integration

2005-01-10 Thread Norman Vine
Manuel Massing wwrites:
 Sent: Monday, January 10, 2005 7:33 AM
 To: flightgear-devel@flightgear.org
 Subject: [Flightgear-devel] alternative terrain engine integration
 
 
 Hi,
 
 I want to start to integrate an alternative terrain engine 
 with flightgear 
 (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html)
 
 For this, I need to adapt flightgear to use an abstract terrain API, which
 will encapsulate the current and new terrain engine transparently. 
 
 As this will involve some (mostly small) changes all over the place, it would 
 be great if I could work on a CVS branch.
  
 Would that be possible? What is the policy for gainining
 CVS write access to the fgfs repository?
 
 Of course, I will post planned changes on the mailing lists for 
 discussion, but I want to get the bureaucratic stuff sorted out first :-)
 
 cheers,
 
  Manuel
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d
 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] alternative terrain engine integration

2005-01-10 Thread Norman Vine
Manuel Massing writes:
 
 I want to start to integrate an alternative terrain engine 
 with flightgear 
 (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html)
 
 For this, I need to adapt flightgear to use an abstract terrain API, which
 will encapsulate the current and new terrain engine transparently. 

 Apologies for my earlier empty msg 

I think an abstract Terrain API is a great idea however please
keep in mind that FlightGear uses a round earth model and that 
this should be reflected in any FGFS Terrain API

Is this methodology you want to integrate ?
http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] alternative terrain engine integration

2005-01-10 Thread Norman Vine
Manuel Massing writes:
 
  I think an abstract Terrain API is a great idea however please
  keep in mind that FlightGear uses a round earth model and that
  this should be reflected in any FGFS Terrain API
 
  Is this methodology you want to integrate ?
  http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf
 
 yes, that's it.

In the paper this appears to be based on a 'flat Earth' model 
i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y

Perhaps I am missing something or you have extended the engine 
since this was written ?

Are you folks familiar with this work
http://globe.sintef.no/documentation/projection.html

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] alternative terrain engine integration

2005-01-10 Thread Norman Vine
Norman Vine writes:
 
 In the paper this appears to be based on a 'flat Earth' model 
 i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y

ooops ...
i.e. lon lat are taken to be simple X, Y or Cos(medianY)*X,Y

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] alternative terrain engine integration

2005-01-10 Thread Norman Vine
Norman Vine wrote:
 
 Manuel Massing writes:
  
   Is this methodology you want to integrate ?
   http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf
  
  yes, that's it.
 
another interesting read from this project :-)
http://cg.cs.uni-bonn.de/docs/publications/2004/harabasz-2004-out-of-core.pdf

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] FGNetFDM-time

2005-01-08 Thread Norman Vine
Arnt Karlsen writes:
 
 On Sat, 08 Jan 2005 14:47:20 +0800, Ivan wrote in message 
 [EMAIL PROTECTED]:
 
  G''day all.
  
  I''ve written a client that drives FG using the native-fdm I/O
  mechanism.
  
  For the ''time'' variable, I've tried entering zero, and then entering
  the value returned by (Win32's) GetTickCount() -- no difference.
  
  However, interestingly, I noticed that FG starts off at midnight (in
  its  internal world time) but the time advances at a phenomenal rate.
  After a  couple of minutes I actually see the sky lighten up, followed
  by the sun  rising in the east. Sunset follows about 2 min later.
  
  What gives ??
 
 ..a _guess_: the 32bit unix calendar ticks over sometime in 2038, 
 while the 32bit Wintendo calendar ticks over every 49? days, 
 I saw this given somewhere on the web as the reason Microsoft 
 used (they still do?) to recommend reboots about that often.

This is true a naive Win32 clock running of of timeGetTime() 
rolls over every 49 days but there are ways to prevent this
although I don't believe the FlightGear clock on Windows checks
for this.

However Ivan's problem is one of order of magnitude

SimGear / timing / timestamp.XXX is where this is spelled
out in code

Cheers

Norman


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] John: Church Fenton hangars need fixing?

2005-01-06 Thread Norman Vine
Jon Stockill writes:
 
 Yes, they do need fixing - I can see terrain through the furthest hangar 
 where you're looking through the mesh of the door runners. Anyone know 
 how to fix this? Is it just an object ordering problem?

Probably you are only using one-sided polygons and the walls are 
only render when looking at them from the 'outside'

Norman


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Infra srtucture for searching Mailman archives

2005-01-06 Thread Norman Vine
FYI
http://infothecary.org/jordan/mailman.html

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Individual aircraft downloads

2005-01-04 Thread Norman Vine
Martin Spott writes:
 
 Dave Martin wrote:
 
  How about a simple set of links on the same page to applications which can 
  handle tar.gz on Windows.
 
   ftp://ftp.uni-duisburg.de/Windows/Win32/apps/powarc61.exe


$ untarka
untarka v0.34: super untar + untar.Z + untar.gz
contains code (C) by [EMAIL PROTECTED] since 2003.01.28
This program is under GPL =2.0. There is NO WARRANTY. Use at your own risk!

Usage: untarka [-x] tarfile  to extract all files
   untarka -x tarfile fname ...  to extract selected files
   untarka -l tarfileto list archive contents
   untarka -hto display this help

Source code is in
$FlightGear / utils /fgadmin / src

Here is an executable
http://www.vso.cape.com/~nhv/files/untarka.exe

Cheers

Norman 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Diamond TwinStar Panel

2005-01-02 Thread Norman Vine
Paul Surgeon writes:
 
 Yeah I know about off screen rendering to textures but I don't know of anyone 
 who is willing to implement it for us.

There are at least two places this is already done in FGFS
that can be used as examples of different ways of doing this
3D Clouds and the jpeg server.  

Someone who wants fancy Panels just needs the itch :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] CVS Build on Cygwin

2004-12-31 Thread Norman Vine
attached find my home grown Makefile

to use copy it into $OPENAL/win

and excute make

You will have to figure out how to install it 

dll(s) go into $BIN
.a(s)  go into $LIB
$OPENAL/include/AL/*.* go into $INCLUDE/AL

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of John
 Wojnaroski
 Sent: Friday, December 31, 2004 10:49 AM
 To: FlightGear developers discussions
 Subject: [Flightgear-devel] CVS Build on Cygwin
 
 
 Hi,
 
 Could not find any info on the OpenAL website regards building the libraries
 on Cygwin. So tried the linux build. Well, it built, but thinking the
 install is suspect and Simgear complains as well. The headers are in
 /usr/local/include and the .a library is in /usr/local/lib along with a .dll
 file
 
 Any hints, info, suggestions on fixing the problem...
 
 Regards
 John W.
 
 
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d
 

GNUMakefile
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Real weather fetch

2004-12-29 Thread Norman Vine
Erik Hofman writes:
 
 David Luff wrote:
  I tried out the real weather fetch option for the first time yesterday.  
  It's absolutely excellent!  It just worked, 
 with no setup or bother, and gave the correct weather in Chicago according to 
 the forcast, and the correct weather in 
 Nottingham according to the view out of the window.
  
  I'm afraid I can't recall who is responsible for this - I can't always keep 
  up with all the list traffic, but whoever 
 it was - thanks :-)
 
 Melchior did the fetching code, Curt and me implemented most of the rest 
 using the Environment class of David Megginson. So basically everybody 
 did some wok on it :-)

Yes lots of people helped for example

http://jeremy.zawodny.com/perl/Geo-METAR/
http://www.schwarzvogel.de/software-pymetar.shtml

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Real weather fetch

2004-12-29 Thread Norman Vine
Erik Hofman writes:
 
 Norman Vine wrote:
 
  Yes lots of people helped for example
  
  http://jeremy.zawodny.com/perl/Geo-METAR/
  http://www.schwarzvogel.de/software-pymetar.shtml
 
 This sounds as if you think the METAR data is fetched only once. In fact 
 it isn't, it's fetched ever 30 sec. if the user is closer to a different 
 METAR station than to the previous one, or else it's fetched every 5 
 minutes or so.

Oh ..  I am 'quite familiar' with the algorithm used to find the closest
airport.efficiently   :-)

Cheers

Norman


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Bad elevation data in most recent scenery

2004-12-28 Thread Norman Vine
Curtis L. Olson writes:
 
 Our terrain data comes from SRTM which has a few warts and missing 
 areas.  I haven't started to think about how to blend data to address 
 this.  I was hoping that at somepoint someone would release a fixed 
 SRTM based data set.  I haven't heard of anything yet.  For what it's 
 worth there is also problems at one end of the grand canyon, parts of 
 Rhode Island, and often some prominant mountains are cut off too short 
 because the peaks didn't come out right in SRTM.  These problems are 
 extremely tedious (at best to fix by hand) and you need to have a better 
 reference data set to do anything about it.

It looks as if processed SRTM data is becoming available

http://edcsns17.cr.usgs.gov/srtm/index.html

This is not freely downloadable but is freely redistributable

These are still not 'perfect' but are much better then the 'raw' data 
FGFS currently uses 

Currently only available on CD 70 @ 45  = $ 3,150 US

available soon on DVD   couple of months 
I am assuming this will be 13 @ 60 $  = $ 780 US

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] are we switching from blender to ac3d?

2004-12-26 Thread Norman Vine
 
 [offlist]
 
 On Sat, 25 Dec 2004 19:02:47 -0500, Norman Vine wrote:
 
  Excuse me Curt but 
  
  This is bordering on FUD
 
 Exchange formats are designed to capture common information for many
 different uses; proprietary formats, like PLIB's SSG, are optimized
 for a single app or library.  Even if you (Norm) disagree with Curt's
 suggestion to avoid formats designed for a single app or library, I'm
 surprised that you cannot admit that this is something intelligent
 people can disagree on, rather than accusing Curt (of all people) of
 spreading fear, uncertainty, and doubt.

Excuse me but this is FUD !

SSG is certainly not propriatary in any reasonable man's vocabulary !!

The sggestion that FGFS who's native format is SSG would be somehow 
limited by using the native SSG load function esp. given there is an 'editable' 
model in the format of the Editor application that created the model is 
'bordering' on FUD.  

FWIW If and when FlightGear exchanges SSG for another internal 
SceneGraph I would suggest using that SceneGraph's native loaders
also !

Perhaps we would all get along better if we only spoke Esparanto 
outside of our homes also :-)

Merry Christmas all,

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] are we switching from blender to ac3d?

2004-12-26 Thread Norman Vine
David Megginson writes:
  
 Anyway, my original point was that whether you agree or disagree, you
 were being a little loose with the accusation of FUD against Curt. 
 He's making a legitimate point, not trying to mislead people into
 doubting plib.

If you reread my original post you will note I didn't accuse anyone 
of spreading FUD.

I think I chose my wording rather carefully i.e.   'bordering'

You may not agree with me but FlightGear would be better recieved 
if it used more pre-compiled objects and their appropriate loaders.

i.e. Just because FGFS is written in 'C++' doesn't mean you have
to re run a compiler over the whole source tree everytime you want
to use it.  

What-is-good-for-code-is-also-good-for-data'ly yr's

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] are we switching from blender to ac3d?

2004-12-25 Thread Norman Vine
Chris Metzler writes:
 
 No kidding.  It's really surprising that plib supports several proprietary
 3d modellers, but doesn't support the one really powerful and popular
 open source modeller. 

PLib was written *before* blender *was*
 
 A plib loader for .blend would, IMHO, be an incredible boon for FG. 

PLib is Open Source and If it itches ...  :-)

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] are we switching from blender to ac3d?

2004-12-25 Thread Norman Vine
James Turner writes:
 
 On 25 Dec 2004, at 14:43, Chris Metzler wrote:
 
 
  A plib loader for .blend would, IMHO, be an incredible boon for FG. 
 
 This is absolutely the wrong approach; the .blend file (like the .3ds 
 format) is a very, rich, complex format that evolves with Blender 
 releases. Just like 3DS, it is a dreadful format to import / export, 
 and no-one should try.
 
 The correct approach is to pick a format that makes sense for 
 FlightGear (whatever that may be), and write / find / improve a Blender 
 exporter script (which are written in Python) for that format.

If someone was to do this I would suggest exporting to 
the native .ssg binary format :-)

direct'ly yr's

Norman



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] FW: [Edu-sig] Learn to Program in Ten Years

2004-12-25 Thread Norman Vine
This is just to good not to pass along
 
  http://norvig.com/21-days.html
 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] are we switching from blender to ac3d?

2004-12-25 Thread Norman Vine
Erik Hofman writes:
 
 Norman Vine wrote:
 
  If someone was to do this I would suggest exporting to 
  the native .ssg binary format :-)
 
 If they could fix the .ssg endianness problem in the process I'm all for it.

Hi Eric,

[EMAIL PROTECTED] Intel really messed the world up didn't they :-)

However I don't think this should be very hard todo as
AFAIK all SSG low level file access goes thru the functions 
in  ssgio.cxx.  

We just need to decide which endianness is the default
and then wrap all the lowlevel code for the other method
with the appropriate inlines from PLIB::Util::ul.h

Which version gets compiled in would be controlled by the 
configure script.

Am I missing something here ?

Norman




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] GUI Improvements was: Things to do to improveFlightgear

2004-12-17 Thread Norman Vine
Matthew Law writes:
 
 Personally, I'd prefer to see a nice OpenGL based GUI like some of the
 other simulators and, dare I say it, games.  With this method you can
 throw out native look and feel and just have a very nice looking
 functional user interface that works on any platform with OpenGL
 support.

PUI  PLIB's GUI  can make much nicer looking interfaces then what 
is currently done in FGFS.  

Several commercial games use it for their GUI jsut for the reasons
you described including at least one EA title

Norman

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] control surface normalization

2004-12-17 Thread Norman Vine
Jon Berndt writes:
 
 Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately, 
 in this
 case, I appears that I did not consider all the needs of the animation 
 system. Neither one
 should have to be designed to make up for something the other doesn't do. So 
 I think the
 best thing to do, as we've hit on before, is to have the interface do the 
 translation.
 That's where the discussion should probably head.

As was suggested *very* early on in this thread :-)

being-right-like-beauty-is-in-the-eyes-of-the-beholder'ly yr's

Norman

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] CVS Error?

2004-12-17 Thread Norman Vine
#include stdio.h

#if defined(WIN32)  !defined(__CYGWIN__)
#define snprintf _snprintf
#endif


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of John
 Wojnaroski
 Sent: Friday, December 17, 2004 11:33 AM
 To: FlightGear developers discussions
 Subject: [Flightgear-devel] CVS Error?
 
 
 Hi,
 
 I may have posted this late last night, but seems to have been lost. If 
 a duplicate post, my apologies
 
 Compiling the CVS pre-release
 
 error in FGNozzle.cxx complaining about snprintf as implicit declaration 
 at line #74
 
 Currently running 0.9.5
 
 Did I miss something skipping over 0.9.6?
 
 Regards
 JW
 
 
 
 
 
 
 
 ___
 Flightgear-devel mailing list
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d
 

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Video card recommendations

2004-12-17 Thread Norman Vine
Curtis L. Olson writes:
 
 I am involved with a project where we are going to setup a multi-channel 
 visual system running flightgear.  (3 PC's, 3 monitors.)  We can budget 
 about $150-200 for the graphics cards, but the landscape has changed so 
 much since I last shopped I'm not sure what to do.  We are committed to 
 buying something nvidia/GeForce based.  The new 6800 cards are still way 
 out of our price range.  The 5900/5950 cards are probably a bit high 
 right now too.  But I see there area 5200's, 5500's, 5700's. and you can 
 still find the older ti4600/4800 cards floating around too.  I know that 
 some of these varients were designed more as low end/cheap consumer 
 cards, and I'd like to get something with the best 
 capability/performance I can within our budget.  Does anyone have any 
 recommendations?

If you have PCI motherboards  this looks like it will deliver
the most bang for the buck
http://www.anandtech.com/video/showdoc.aspx?i=2300

Norman

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] control surface normalization

2004-12-15 Thread Norman Vine
Jim Wilson writes:
 
 Jon Berndt said:
 
  Do 3D models use a normalized range to model aerosurface rotation, or
 actual degree
  magnitude? I've been looking at the JSBSim flight control code and the
 addition of the
  code that normalizes aerosurface (elevator, aileron, etc.) rotation
 positions confuses
  the code, and appears to only be relevant to 3D modeling.
 
 And the Simgear 3D animation code is all about taking those normalized values
 and translating them to a representation of degrees movement.  On the surface,
 this doesn't make sense to me either.

I can think of no other generalized expression of a 'control's state' 
whether it be rotation, fluid pressure, amps what ever :-)

Once you start specializing there is no end and IMO using the
Normalized Values makes perfect sense for the abstract Control Module.

Simple translators from Normallized to Actual value are all that is needed
and are already instantiated on the FGFS side.  Client applications such
a JSBSim can easily implement wrappers when talking to FGFS

my-two-cents'ly-yr's

Norman


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] control surface normalization

2004-12-15 Thread Norman Vine
Jon S Berndt writes:
 
 Absolutely. And JSBSim is used by more than FlightGear - which leads 
 to part of the concern I have. FlightGear should not require the FDM 
 to massage values that it should be massaging itself.

Just need a translation layer

IIRC 'Normalized Control Units' have been in FGFS for at least 5 years
probably more like 7 or 8.  not to say that this can't be changed but ...

Anyway I will go back to lurk status

Cheers

Norman

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] control surface normalization

2004-12-15 Thread Norman Vine
Vivian Meazza writes:
 
 Perhaps some of our longer standing developers can shed some light on the
 background to this important decision.

This was the easiest way to implement the system at the time insuring that 
only 'sane' values were ever passed.  ie 'clamped'

An alternative method would be to have all the extreme values default 
to some safe value and to have these actually set in the individual aircraft 
files.  The controls themselves would probably be best implemented as
pure 'property objects'.

This would be a much more flexible system but would require a fair bit of 
work to implement.  This would also add to the complexity of the aircraft
definition files.  Neither of these are show stoppers.  

The current method obviously works so so this requires someone with a 
strong incentive to make the change to step up and take on the job

FWIW I suggest that the new property tree be fully fleshed out ahead of 
time before any code was actually changed.

Note The FGFS code would then become nothing more but but a means 
for the FDMs to access the property tree values

Cheers

Norman





___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] control surface normalization

2004-12-15 Thread Norman Vine
Curtis L. Olson writes:
 
 Jon S Berndt wrote:
 
  Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot 
  be seen. Neither Amps nor fluid pressure are reported on a zero to one 
  scale. Aerosurfaces can be drawn and seen, and that's not done on a 
  zero to one basis either. Like I said, there are some things that can 
  be done on a zero to one basis, such as landing gear deployment. But, 
  aerosurfaces are reported in degrees, regardless of whatever aircraft 
  it is, it's already generalized to its lowest common denominator. 
  Why it should be further reduced and then reassembled to the exact 
  same value (one hopes) later on when rendered via SimGear - that's 
  defies description, IMHO.
 
  It is true that we can pollute our code (a.k.a. implement wrappers) 
  to satisfy FlightGear, but why? We know what the control surface 
  limits are. So, what do we do? Pass a normalized value AND the 
  aerosurface limits so they can be reconstructed later? Why not just 
  pass the raw value and be done with it?
 
  Code that massages physical parameters to make up for shortcomings in 
  the rendering/animation system doesn't belong in the FDM. If it 
  doesn't belong in SimGear or on the FlightGear side, it belongs in the 
  FGInterface class - but I don't think it even belongs there.
 
  I know this sounds forceful, and I don't mean to step on any toes 
  here, I just feel strongly about this.
 
 
 For what it's worth, I recall there being some sort of substantial 
 discussion at the time this was implemented, I just don't recall what 
 that discussion consisted of.  I tend to support your position John, 
 however, let's not act too hastily because a lot of code and animation 
 depends on this behavior.

It is realy quite simple 

you either have 

1) an abstract class with 'Normalized units'
class Control
or 
2) a bunch of specalized classes
class Angle_Controller
class Toggle_Controller
class Percentage_Controller
etc .

Both schemes have advantages

Quick question 
Do valves take 1 or 2 full rotations of the handle to fully open ?

Cheers

Norman








  

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] control surface normalization

2004-12-15 Thread Norman Vine
Curtis L. Olson writes:
 
 I think we are limiting the discussion here to only flying control 
 surface positions, i.e.

As you point out those are only a small subset of the 
Control class abstaction.

So specialize these if esired but 
IMO the 'slippery slope principal' is in play here

BTW  It is peculiar how one of the argument for using degrees
because it cuts down on 'conversion code'  in SimGear is not 
applied to using for Geocentric Coordinates internally as SimGear 
and the FDMs go to great pains to pass everything  as lat lons 
which requires duplicate conversions on both ends of the pipe :-)

Cheers

Norman

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] control surface normalization

2004-12-15 Thread Norman Vine
Jon S Berndt writes:
 
 
 This is irrelevant, also - at least for JSBSim. 

That is an excellent observation

FGFS is more then JSBSim though :-)

Cheers

Norman

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


  1   2   3   4   5   6   7   8   9   10   >