RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Norman's intersection testing works just fine for the moving carrier as well. In fact this was discussed on the list almost six months ago. So you would not fly through the deck. Yes your FDM should recieve the current scenery altitude and compute landing gear reactions accordingly. All those issues of aircraft and carrier coordinates are easily handled as pointed out by Jon S Berndt. In fact I have implemented all of it in FORTRAN. I can steer on deck, launch from deck and land on deck and get arrested all the time with the carrier moving. The only hack I use is for the ski-jump. Although I recieve ski-jump ramp height from FlightGear intersection calculations, I dont use that since it is too coarse to accurately simulate ski-jump launch dynamics, so as long as the aircraft is within the deck (on or over) I use height over deck as computed by the FDM, until aircraft leaves the deck. This check is done using longitudinal and lateral coordinates of the deck, i.e a/c posn in deck coords. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Sent: Friday, April 05, 2002 2:30 AM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] Moving carrier, and Repositioning questions Justin Palamar writes: > 1) A design goal was to have a moving aircraft carrier within the simulator > with the option to land on its deck > Right not we have only been able to insert the static model by editing the > appropriate .stg scenery file, including > "OBJECT_STATIC saratoga.3ds -122.353617 37.624617 -130 0" > We know this has been done before, there is code in the main.cxx file that > refers to a carrier, and a model was included in the 0.7.8 release. Is > there any way to get this working using the higher level .xml files, and > avoid editing the C++ source code? You'll need the carrier to be in the main scene graph so that collision and ground detection works -- otherwise, you'll fly right on down through the deck. From an SSG perspective, all you need is an ssgTransform node between the carrier model and the rest of the scene graph, and then to updated that node with the carrier's new position and orientation (relative to scenery centre, which is the only tricky part). In fact, Curt's code in FGTileEntry::load (src/Scenery/tileentry.cxx) already creates the ssgTransform node when it loads the OBJECT_STATIC model. If you save a pointer to the transform (somehow) and update it in each frame, the carrier will move. Note especially this code: sgCoord obj_pos; WorldCoordinate( &obj_pos, center, lat, lon, elev, hdg ); ssgTransform *obj_trans = new ssgTransform; obj_trans->setTransform( &obj_pos ); You can use something similar in your update routine, using the current scenery centre and supplying new lat/long/elev/hdg params. > 2) When loading our blackhawk model (again by editing/adding .xml files > from the ./Aircraft directory our model appears about 3 meters into the > ground. We have attempted to reposition the model using the instructions > from the flighgear website (rather than pointing directly to the model, > point to a .xml wrapper file with repositioning information in it that also > points to the model) but we an ssgLOAD error: Unknown file type .xml. As > if it is trying to see a graphic file and sees an .xml and doesn't know > what to do with it. I'm not sure if this is a change in the newest > release, of if I'm missing something. Yes, you need the latest CVS code. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Well I had something similar in mind when I wrote fgLoadDCS() and fgUpdateDCS() in main.cxx. I had used a limit of 32 objects since I guessed that more than that might affect frame rates. Presently repositioning is possible thro network, albeit tied to fdm=ada, but thats trivial to change to make it more widely usable. So far I have used scenery/objects.txt file instead of .xml for loading objects. Is what you have in mind drastically different from whats been implemented so far. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. Olson Sent: Friday, April 05, 2002 1:01 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Moving carrier, and Repositioning questions What I would like to see implimented is a 'standard' DCS system (where DCS stands for dyanamic coordinate system which is industry lingo for objects that move in the scene ... their local coordinate system is 'dyanamic'. I'm envisioning a DCS manager where you can register 'entities' with an associated 3d model and an associated 'behavior'. The behavior could be a preset path to follow, or something more AI-ish, or even something like JSBSim or YAsim (or perhaps entity positions could be driven externally from a server to produce a 'shared' world for collaborative flying.) I'm thinking we could create some simple "FDM's", one that replays a preset path, and one that impliments ultra-simple-light-weight flight dynamics which would be good enough for 'realistic' robot planes viewed from a distance, but simple enough so we can compute the dyanmics for "many" planes each frame. The DCS system would take care of loading and attaching the 3d models to the correct place in the scene graph and removing them. It would call the update() routine for each of their "engines". And it would probably provide some sort of property interface to the positions, orientations, and velocities of these dynamics entities. That doesn't solve all the problems and address all the issues, but I think it would be a good start. Anyone want to work on this? I could even give you your own subdirectory. :-) Regards, Curt. Andy Ross writes: > Justin Palamar wrote: > > 1) A design goal was to have a moving aircraft carrier within the > > simulator with the option to land on its deck > > There are actually two problems here. The first, making the object > move, is relatively easy. It will require C++ code, though. One way > I've thought about doing it is to put the object in the property tree > rather than the static scenery description. Something like: > > /scenery/objects[n]/model-file=Models/carrier.ac3 > /lat-deg=nn.nn > /lon-deg=nn.nn > /alt-ft=nnn > /hdg-deg=nnn > /speed-kt=nnn > > And then the "dynamic scenery" code would update the lat/lon > accordingly. This could be extended with extra orientation and > velocity parameters for a full 6DOF model animation, controllable via > properties. > > But there's another problem -- the current FDMs model gear force using > only the aircraft's velocity. They assume the ground is fixed and > unmoving. This means that you could land on the carrier, but would > then come to a stop relative to the earth, while the carrier slipped > smoothly out from under you. > > I'm not quite sure about the "right" way to do this -- doing it in the > low-level ssg "hitlist" collision detection is going to be rather > complicated, and won't perform well. Perhaps the best way to handle > it would be to special case "carrier deck" objects (more generally, > anything moving on which the gear are expected to rest), and expose > them directly to the FDMs via a "ground velocity" parameter. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Plotting tool
Regarding the thread you are referring to - The code is presently with Alex Perry and he is in the process of integrating it into SimGear (?) and should be available soon. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Quint Mouthaan Sent: Wednesday, April 03, 2002 6:27 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Plotting tool Hi there, my name is Quint Mouthaan and I'm a student at the Technical University Delft in the Netherlands. I'm working a project in which we want to use FlightGear. The first thing we want to do is analyze some flight data. I saw a thread a little while ago about a tool that would be added to FlightGear that could be used to plot some data real time. Is that tool already available and if it is how can I obtain it? Thanks, Quint. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] idea ... (?)
I have just sent the code **as is** to Curt alongwith a sample data file for testing and a brief user doc. Once it is in CVS you can let me know the changes you need. The code was written by my colleague Miss Suma J, under my guidance. Hope its useful. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Perry Sent: Sunday, March 10, 2002 6:39 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] idea ... (?) I suggest that you submit it mostly as-is and have Curt place it into CVS so we can all see how it's implemented ... that way we will have a basis to give you realistic answers to those questions (instead of guessing). > OK. I will do so on Monday (11th March). Do you want > me to integrate it into SimGear so that its offline > plotting function could be used by people who work > with one PC and the stand-alone executable could be > used by those who have more than one PC.? Or Should I > just send the stand-alone code to Curt?. > As a first step I will just integrate it as is, test > it with our FDM (for real-time) and our ascii format > data file (for off-line) and send it to Curt. Once I > recieve suggestions from you I could get it to work > with other FDMs of FlightGear. > Regards > Ranga > --- Jon Berndt <[EMAIL PROTECTED]> wrote: > > This sounds ideal! I vote that you submit it! :-) > > > > What are the code dependencies? SimGear? > > > > Jon > > > > > I have a stand-alone real-time and off-line > > plotting > > > tool written in C/C++ (tested in > > Cygwin/WinNT/Win2K & > > > Linux) that is meant to be used as a flight test > > > engineer's station. It has just been completed and > > it > > > works, but I am yet to put it to serious use. The > > code > > > is designed to run a separate PC and recieve data > > via > > > network from the FDM and the plots are > > configurable > > > via xml. Offline plots have zoom facility, scales > > (x/y > > >... > > > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > __ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ancient 'ascii' scenery format
Curt, How about leaving the ascii format as it is 'without further support', so that we could continue using it. If its possible to leave it in a working condition without breaking that would be wonderful. Afterall the ascii format's similarity with Wavefront .obj format makes it quite useful for people like me to modify scenery without TerraGear. I just havent started using TerraGear and hope I would not be forced to do so. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. Olson Sent: Sunday, March 03, 2002 11:10 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] ancient 'ascii' scenery format I would be able to clean up a *lot* of code if I could jettison support for the old 'ascii' scenery format. None of the scenery on the ftp server is in the old ascii format. It consumes more space to represent the same geometry, file loading is slower, it hasn't been updated to support newer features of flightgear (nor do I want to do this.) The code to support this format is messy, and continuing to support it is messy, and we could clean up a lot of this by just dropping support for the ascii format Is anyone still using this ancient file format? Does anyone have any objections to ending support in flightgear for it? Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urgent: Network and external flight model
Erik, Yes I mean multicast and not broadcast. The destination address is the group still, unless I have different multicast groups - one for IG, one for the engineer etc. That would be a waste. Regards Ranga -Original Message- Are you shure you don't mean broadcast here? For what i know, multicast has the destination ip-addresses inside the packages, so only intended computers should receive the data. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urgent: Network and external flight model
Roman, >but I think that for IGs - best is multicast (no delays between channels) Theoretically speaking, yes. But practically what delays are we talking about even with a 10 Mbps dedicated network. We will be fast enough for realtime. Synchronisation problems would not happen at the network level but could happen at the tile-loading/culling/rendering stages of each IG **if** no. of polygons/textures are different for each IG (or view). Yes multicast can certainly be useful, like httpd, for remote IGs but not for local IGs around a dedicated network. With it I could perhaps join your multicast group half way round the globe and watch you fly, bandwidth permitting. Regards Ranga > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan > Polley > Sent: Friday, February 01, 2002 7:16 AM > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] Urgent: Network and external flight > model > > > David, > > At work, I run a proprietary FDM on a Sun Workstation and feed the > data to FlightGear. I use the '--fdm=external' and '--native_fdm=...' > options (--native_fmd= uses the same parameters as --native). I did > make some changes to Network/native_fdm.cxx to properly manage the > byte-order issues, but it works like a champ. IMHO, --native_fdm= has a > cleaner interface than does --native=. To see the data structure that > the FDM needs to generate, look in Network/raw_fdm.hxx. > > Jonathan Polley > > p.s. I have submitted my edits. > > On Thursday, January 31, 2002, at 06:37 PM, David Findlay wrote: > > > Just checking a couple of details - you can run an external flight > > model on a > > machine other than the one running FGFS right? Thanks, > > > > David > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urgent: Network and external flight model
Roman, This was dicussed earlier on this list. I found one disdavantage of using multicast. My packet size or structure kept growing as I added more computers on the network that are **not** image generators but pcs used as flight test engineer station or fcs monitoring station etc. Why should image generators receive data that is not intended for it and vice versa. So I find non-blocking udp fast enough while maintaining packet sizes to the minmum required and I suppose bandwidth requirements are not too high to cause perceptible delays. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Polley Sent: Friday, February 01, 2002 7:16 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Urgent: Network and external flight model David, At work, I run a proprietary FDM on a Sun Workstation and feed the data to FlightGear. I use the '--fdm=external' and '--native_fdm=...' options (--native_fmd= uses the same parameters as --native). I did make some changes to Network/native_fdm.cxx to properly manage the byte-order issues, but it works like a champ. IMHO, --native_fdm= has a cleaner interface than does --native=. To see the data structure that the FDM needs to generate, look in Network/raw_fdm.hxx. Jonathan Polley p.s. I have submitted my edits. On Thursday, January 31, 2002, at 06:37 PM, David Findlay wrote: > Just checking a couple of details - you can run an external flight > model on a > machine other than the one running FGFS right? Thanks, > > David > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Post 0.7.9 priorities (lights)
Roman,
If you know the light posns in runway (object) coords all you need to know
is the lat, lon and alt of the centre/corner (0,0,0) of the runway.
Construct transformation matrix as is done for dynamic objects in main.cxx.
Rotate first for lat, lon and translate by Objtrans (see below).
//object gbs-posn in cartesian coords
Point3D obj_posn = Point3D( obj_lon,obj_lat,obj_alt);
Point3D obj_pos = sgGeodToCart( obj_posn );
// Translate object w.r.t tile center
Point3D Objtrans = obj_pos - tile_center;
This should work. This can be done offline and stored in a seperate file or
done on the fly.
Regards
Ranga
-Original Message-
Okey guys, I'm trying to implement runway lights but I have some
mathematical trouble:
I know 4 corners of runway in local tile coordinates O1 O2 O3 O4 {x,y,z}
And I have runway sheme of lights for example let O1 will have {100,100,100}
in FG coordinates and {0,0,0} in local lights coordinate system. All I need
to have formulas to convert this local lights coordinates to tile fg
coordinates. I know that I can construct plane by 3 points using plib sg
routine but wthat formulas?
O2O3
y
|
0--00
||
||
||
0--00-->x
O1O4
so in runway coordinate system we have 6 points
{0,0,0}{100,0,0}{200,0,0},{0,50,0},{100,50,0},{200,50,0} and have simple
routine to convert it to tile coordinate system
I try many formulas but no success :((
So if some on do it we HAVE runway lights
because you simply construct it using tileentry.cxx routines
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lights
>>Also I complied flightgear to see lights usung MSVC but when I use cygwin I
>>got nothing cygwin's glut does not support opengl extensions :
>>As I understand now you are working on Mandrake and use Nvidia linux
>>drivers that support extensions
>>when i compiled on linux should I simply rename wgl to xgl and all works
>>fine? Your comments?
>No I use the gl-extensions only on Win2k machines, not on linux. You tell me
>how to make it work with Linux. To begin with gl.h from nvidia distribution
>does not seem to support the point parameter extension, which is supported
>on win2k with the help of glext.h.
further to my earlier mail on this thread
gl.h on linux/nvidia machines does seem to have the GL_EXT_point_parameters
functions, but how do you obtain the entry address to these functions in the
api library. I mean what is the equivalent of wglGetProcAddress("xxx").
Regards
Ranga
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lights
On Thursday 17 January 2002 13:35, you wrote: > using your ksfo airport I use lp tokens and turn on runway lights > now i got shemes on position our russian runway lights and try to place > runway lights according scheme "Ray" or "Lutch" in russian transcription runway x y z - define runway direction. > as i understand rway_dir variable shows us landing direction on runway it's > normalize vector Yes > rway_normal it's normal to runway or what? normal to point light? or > raycasting direction It is direction of the light. (yes, raycasting dirn.). for allround lights it becomes the runway normal. for red/green threshold lights its the runway direction. for vasi it is again the runway direction (red/white elliptical beams centered about the runway direction vector emanating from the light.) The setclor() and setcolor2() functions produce texture maps about these directions. > in tileentry.cxx there is a code > //EDGE > setColor(0.0,0.0,-1.0,180.0, 1, 1, 0.5, 1); > why 180 and not 360? > and on vasi > //VASI lights > setColor(0.0,0.0,1.0,360.0, 0, 0, 0, 0); > setColor2(10.0, 40.0, 1, 1, 1, 1); > setColor2(6.0, 40.0, 1, 0.5, 0.5, 1); > setColor2(5.0, 40.0, 1, 0, 0, 1); > why here 360 > and 10, 40, 6, 5 Sorry, I never bothered to troubleshoot this, because it was not worth the effort as long as it works. setcolor2 divides angles by 2, I discovered. So this hack. 10 gives 5 degrees in elevation (2.5 up and 2.5 down about the horizontal) and 40 gives total 20 degrees arc in azimuth. So you see red from 0 to 2.5 degrees and white when glideslope greater than 2.5 degrees wrt to the vasi lightpoint. > Also I complied flightgear to see lights usung MSVC but when I use cygwin I > got nothing cygwin's glut does not support opengl extensions : > As I understand now you are working on Mandrake and use Nvidia linux > drivers that support extensions > when i compiled on linux should I simply rename wgl to xgl and all works > fine? Your comments? No I use the gl-extensions only on Win2k machines, not on linux. You tell me how to make it work with Linux. To begin with gl.h from nvidia distribution does not seem to support the point parameter extension, which is supported on win2k with the help of glext.h. Regards Ranga _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] runway lights
Roman, Runway lights code is encapsulated using #ifdef FG_EXPERIMENTAL_LIGHTING and is being used (as far as I know, only by me so far) for deck lights on the carrier. Yes, the same could be used for runway lights too. The info on lights is intended to be held in the same file that holds vertex/polygon info of tiles and not the objects.txt file. setcolor() and setcolor2() functions produce textures on the fly for env. mapping (coded by Christian Mayer) to produce directional lights. setcolor2() is used for lights that have different visibility in elevation and azimuth, while setcolor() produces symmetric visibility. At present runway lights' coords are read only in the fgLoadDCS() function in main.cxx which is used to load moving objects like the aircraft carrier. To get runway lights on ground you have to copy **this code** to obj.cxx (preferably) or tileentry.cxx (using a seperate file with only runway light coords tied to a particular tile as is done for other static objects). The light point coords are entered as: IMPORTANT *** I use object coords for runway direction, normals and coords since the aircraft carrier is loaded using object coords. To draw runway lights on ground you have to use Tile coodinates.*** runway 1.0 0.0 0.0 edgelight 0.0 0.0 1.0 lp 4.5000 0.20.2100 lp16.5000 0.21.0100 lp 4.5000 0.20.2100 ... ... red 0.0 0.0 1.0 lp -137.2735-7.173617.2100 lp -137.2735-7.173614.2100 lp -137.2735-7.173611.2100 ... ... green 0.0 0.0 1.0 lp 47.6133 36.3383 21.5000 lp 47.3350 38.3189 21.5000 ... ... vasi or rabbit or ... lp ... lp ... Repeat for each runway. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Roman Grigoriev Sent: Wednesday, January 16, 2002 5:04 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] runway lights Hi guys! Still try to implement runway lights find some section in tileentry.cxx RWY_LIGHTS but i think it's unfinished also when i looked in tile_entry.cxx i found various runway lights initialsations but i don't understand angular_size in setcolor() function and elev_size and azimut_size in setcolor2 function could you please explain it? also i find section in main.cxx that read lights from object.txt does someone use it? Thanx in advance bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Objects
David, -Original Message- > What's FG_EXPERIMENTAL_LIGHTING? And is it used by default? It is code to enable lighting on the aircraft carrier incuding an Optical Landing aid (fixed at 3.75 deg). It is not enabled by default unless you add that define. As far as I know only I am using it. If you haven't already written code for billboarding trees there is fgbillboard() function (unused so far) in tileentry.cxx. You may use it. It works fine and I used it earlier for polygon based runway lights. You may need to change the arguments depending on your implementation. Regards Ranga _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] buildings or planes?
Hi Norman, I never noticed !!. I remember having sent them long back to Curt. Anyway I am sending one carrier.zip file to [EMAIL PROTECTED] I would be grateful if you could put it up someplace so that anyone else who is interested could also download, or Curt could or John could include it into the base package. The saratoga.obj and saratoga.mtl files go to ~models/geometry and the rgb/bmp textures go to ~models/textures directory. Thanks. Maybe I'll get PPE and learn to use it. Regards Ranga >The .obj file is in the FlightGear / Models directory but I have >never seen see the associated .mtl file or any of the materials :-( >Are these available ? >FYI - PPE can load .obj files >As a general rule any file that FlightGear can load PPE >can load as they both use the SSG file loaders :-) _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] buildings or planes?
Hi everyone, I have been following this thread. >> Pretty sure Objects/Geometry/saratoga.obj is a carrier > Yes, this would be cool.Definitely. > Jon Jon, as pointed out by John, we already have an aircraft carrier. It is one with a ski-jump and 3 arrestor wires. We use it in our design work. Andy, You can see the carrier in FlightGear by giving the lat,lon,alt in ~scenery.objects.txt. Or use the 3dexplorer (windows only) shareware viewer. If you are interested I could send you the wavefront .obj file format specs. The carrier model is a simple low polygon one which I edit manually!!. It uses object coordinates with its (0,0,0) at waterline (or metacenter, there is no hull below waterline in this model). You can use 3dexplorer to convert it some format that PPE supports and then use PPE to edit. But I havent tried that. I'll be glad to help anyone who is interested in using it. Regards Ranga >I've never touched the geometry side of fgfs, so any pointers would be >appreciated. What can I use to look at this thing? I don't recognize >wavefront .obj format (although it's ASCII at least -- big plus). I'm >not a big modelling guy, so be gentle. I just need to figure out the >coordinate system and where the deck plane and arrestor wires are. >If plib supports it, then is Pretty Poly the best editor to use? Does >ssg support API-side inspection of the geometry once it's loaded? >(dumb question, I could just look it up...) _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding airport buildings and runways to fgfs
Hanish, You can still use ascii format scenery with FlightGear. Regards Ranga On Sunday 25 November 2001 18:32, you wrote: > Hello all, > > I am interested in adding some airport buildings and runways to fgfs. The > info what I found on the net seem to relate to a older version of fgfs with > ascii format for sceneries. But I am using fgfs-0.7.8 from debian. What > should I do to achieve the above. > > Or is there any document available on the net which describes the same, if > so please to provide the links. > > > Keep :-) > HanishKVC > www.hanishkvc.com > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
