Re: [Flightgear-devel] Scenery DB (Was: San Jose)
> > I would like to see all new scenery object contributions to end up in > > the scenery database. However, the last time I wanted to sync the base > > package and the DB there were more than one objects in the same space > > because of automatic object generation. btw it looks pretty cute sometimes --- e.g., a skyscraper "swallowing" a radio tower and thus it looks like a skyscraper with a smaller antenna tower on its top; such things happen in real life as well :) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lightning
Dave Culp wrote: > Currently, in CVS FlightGear, it's possible to place an AI thunderstorm in > the > FlightGear world which has both turbulence and lightning. See the AI > scenario called bigstorm_demo.xml. The turbulence is controlled by each > instance of the thunderstorm, so you could have several storm AI entries, > each one defining an area of turbulence within a specified diameter and with > a specified strength. (It's hoped that you'll define the turbulence diameter > to correspond to the visual model's diameter. There is no way for the > AIStorm object, which controls the turbulence, to automatically know the > diameter of the 3D model. ) > > The lightning however is controlled from one property, > "environment/lightning/flash". Because of this, if you have more than one > storm they will all flash at the same time. I was thinking about changing > this so that each instance of a storm will have its own property to be used > as a flash trigger, however it would be best if the flashing could instead be > completely a part of the 3D model animation, with no external trigger needed. > > All you experienced modelers, please tell me, is this possible? Can you set > a > piece of a model to flash somewhat randomly using only XML animation code? > > Dave > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > I'm pretty sure you would need to have each t-storm running its own instance of a simple Nasal script. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE:SAN JOSE
Hi Guys 1. I want to add some static AI models at SAN JOSE so as to make it look like some heavy planes are there, can someone tell me where I can get to these models and 2. Where can i get a model of a terminal building to add to SAN JOSE. Regards Shelton. This email was sent from Netspace Webmail: http://www.netspace.net.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Yes, it'd need to install the contents of the tarballs to ...Scenery/ rather than ...Scenery/Terrain I guess I'm just being picky ... it would also have to look in two places when removing scenery ... nothing insurmountable, just kind of messy in places. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On November 4, 2005 04:23 pm, Durk Talsma wrote: > So, for starters, I would like to explore > some models of the more popular airliners series, i,e., the Boeing 7[0-8]7, > Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and Fokkers of > course :-)). I'd build them myself If I had shown any signs of talent in > the field of 3D modeling :-(. > > Cheers, > Durk I have data on every single aircraft of Airbus. I just need the time to be able to work on them. On November 5, 2005 03:22 am, Durk Talsma wrote: > On Friday 04 November 2005 23:40, Christian Mayer wrote: > > Wouldn't it be better to add those models to the existing (and yet to > > come) "high"-poly models as a different LOD? > > Would be possible, but aircraft loading and unloading time is going to be > an issue. Unless we can move the aircraft loader into a separate thread, or > come up with a very sophisticated multiframe aircraft loader, I would > prefer to start with using something that is simple from the start. > > Cheers, > Durk Having done multiple Level-of-Details for the MD-11, using multiple models for different Level-of-Details don't really excite me. Beside, when one is inside an airport, where planes are lined up wingtip by wingtip, such a scheme doesn't really reduce polycount by much, if at all. In my opinion, it would be more flexible and more efficient to have a single high-poly model for the aircraft instead. If the model is divided into sufficient number of objects, then it would be a simple matter of hiding more and more objects as the aspect ratio of the aircraft decreases. For example, a wing can be divided into the following components: wing +leading edge - +slats - - +top portion - - +bottom portion - - +sides - +slot of slats +middle portion - - +front spar - - +rear spar - - +top portion - - +bottom portion +trailing edge - +spoilers - - +top portion - - +bottom portion - - +sides - +flaps - - +leading edge - - +sides - - +remaining portions One can hide the objects starting from the bottom-most of the tree, and work toward the root of the tree as the plane becomes more and more out of range. One can also hide objects that are hidden, such as the bottom of the spoilers and the leading edge of the flaps when the plane is in a clean configuration. The latter ability will be very useful when the AI Aircraft is inside an airport. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] lightning
Currently, in CVS FlightGear, it's possible to place an AI thunderstorm in the FlightGear world which has both turbulence and lightning. See the AI scenario called bigstorm_demo.xml. The turbulence is controlled by each instance of the thunderstorm, so you could have several storm AI entries, each one defining an area of turbulence within a specified diameter and with a specified strength. (It's hoped that you'll define the turbulence diameter to correspond to the visual model's diameter. There is no way for the AIStorm object, which controls the turbulence, to automatically know the diameter of the 3D model. ) The lightning however is controlled from one property, "environment/lightning/flash". Because of this, if you have more than one storm they will all flash at the same time. I was thinking about changing this so that each instance of a storm will have its own property to be used as a flash trigger, however it would be best if the flashing could instead be completely a part of the 3D model animation, with no external trigger needed. All you experienced modelers, please tell me, is this possible? Can you set a piece of a model to flash somewhat randomly using only XML animation code? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Curtis L. Olson wrote: Jon Stockill wrote: Curtis L. Olson wrote: That might be what we have to do, but that implies a change in where scenery files are extracted relative to the scenery tree which would could cause a fair amount of confusion ... not that the current process is completely unconfusing ... It takes things back to how they were - you unpack everything directly in your scenery directory - the scenery tarballs then contain everything that should be below that. I have in mind the "fgadmin" utility which installs and removes scenery and knows where everything should go. That is going to require quite a bit of modification I suspect. Yes, it'd need to install the contents of the tarballs to ...Scenery/ rather than ...Scenery/Terrain Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Curtis L. Olson wrote: That might be what we have to do, but that implies a change in where scenery files are extracted relative to the scenery tree which would could cause a fair amount of confusion ... not that the current process is completely unconfusing ... It takes things back to how they were - you unpack everything directly in your scenery directory - the scenery tarballs then contain everything that should be below that. I have in mind the "fgadmin" utility which installs and removes scenery and knows where everything should go. That is going to require quite a bit of modification I suspect. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Curtis L. Olson wrote: That might be what we have to do, but that implies a change in where scenery files are extracted relative to the scenery tree which would could cause a fair amount of confusion ... not that the current process is completely unconfusing ... It takes things back to how they were - you unpack everything directly in your scenery directory - the scenery tarballs then contain everything that should be below that. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Curtis L. Olson wrote: Jon Stockill wrote: Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon, I see a distribution issue which I'd like to discuss. The object database lives in it's own separate tree. Right now to use your object database a person needs to add a set of models to their base package. Then they need to install the object tree. However, from my perspective, if I want to roll up a 10x10 chunk of terrain + objects I have a big problem. I need to either roll these two trees together in one big tree (which makes it hard to change or upgrade the objects.) Or I need distribute 2 tgz files (and the end user needs to download and correctly install 2 tgz files) for each 10x10 chunk. Would it make sense to make your object database (for the entire world) part of the official base package and put it all in cvs? If we want to leave these objects as user-add-on-after-the-fact entities, then it's ok how we are doing it now, but they add a *lot* to the flightgear experience so I would really like to make them part of the default some how without imposing an overwhelming burden on the end user to do extra complex downloads and installs by hand. I'm not sure I'm explaining the issues very well, but hopefully someone understands what I mean and can offer suggestions. It would be easy enough for you to include the latest version of the database when you built the scenery - the Terrain and Objects split works really well to make this relatively easy, and simple for someone to add the latest version of the objects before the next scenery update. If your scenery package were to have the following (example) structure in the tarballs: Objects/w010n50/ Objects/w010n50/w002n53 Objects/w010n50/w002n53/29.stg <-- entries just for objects (Static scenery models would be included here) Terrain/w010n50/ Terrain/w010n50/w002n53 Terrain/w010n50/w002n53/29.stg <-- entries for airports (Airport and terrain tiles appear here) roll the whole lot up in a tarball for w010n50 and it can be installed as a single package under your scenery directory. If anyone wants to update the models at a later date then they can just replace the Objects/ tree with the latest version. That might be what we have to do, but that implies a change in where scenery files are extracted relative to the scenery tree which would could cause a fair amount of confusion ... not that the current process is completely unconfusing ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Curtis L. Olson wrote: Jon Stockill wrote: Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon, I see a distribution issue which I'd like to discuss. The object database lives in it's own separate tree. Right now to use your object database a person needs to add a set of models to their base package. Then they need to install the object tree. However, from my perspective, if I want to roll up a 10x10 chunk of terrain + objects I have a big problem. I need to either roll these two trees together in one big tree (which makes it hard to change or upgrade the objects.) Or I need distribute 2 tgz files (and the end user needs to download and correctly install 2 tgz files) for each 10x10 chunk. Would it make sense to make your object database (for the entire world) part of the official base package and put it all in cvs? If we want to leave these objects as user-add-on-after-the-fact entities, then it's ok how we are doing it now, but they add a *lot* to the flightgear experience so I would really like to make them part of the default some how without imposing an overwhelming burden on the end user to do extra complex downloads and installs by hand. I'm not sure I'm explaining the issues very well, but hopefully someone understands what I mean and can offer suggestions. It would be easy enough for you to include the latest version of the database when you built the scenery - the Terrain and Objects split works really well to make this relatively easy, and simple for someone to add the latest version of the objects before the next scenery update. If your scenery package were to have the following (example) structure in the tarballs: Objects/w010n50/ Objects/w010n50/w002n53 Objects/w010n50/w002n53/29.stg <-- entries just for objects (Static scenery models would be included here) Terrain/w010n50/ Terrain/w010n50/w002n53 Terrain/w010n50/w002n53/29.stg <-- entries for airports (Airport and terrain tiles appear here) roll the whole lot up in a tarball for w010n50 and it can be installed as a single package under your scenery directory. If anyone wants to update the models at a later date then they can just replace the Objects/ tree with the latest version. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] gui dialogs: selecting buttons via keyboard
Melchior FRANZ wrote:
> FYI: a few days ago I committed an extension to the GUI system that
> allows to select buttons via keyboard. This is currently only used
> for the "ATC communication" dialog ('-key), where the first transmission
> option can be chosen with the "1" key, the second with the "2" key
> etc. (The Alt modifier is currently not reported to the GUI, so Alt-1,
> Alt-2 will work too.) Approach is a busy phase, and not having to
> search for the mouse when you want to transmit a "going around" is
> quite convenient. All it takes to make use of keyboard accelerators
> is to add e.g. 27 to that button in the XML dialog
> config (or to any other widgets with assigned s). 27 (Esc)
> could be used for the "Cancel" button.
>
> m.
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
Neat! At some point I am planning to make a plane specific menu for the
B29. This will include lot's of tasks that the crew would normally
perform and that the pilot doesn't actually have any controls for. I was
also going to include things like help, POH, checklists, systems like
weapons, and livery selection. I know that there is a pulldown for some
of this stuff, but like Melchior says it can get busy at times and it
would be nice to have access to all the special function in one place
that is accessible through keystrokes.
Maybe it would make sense to just have the comms stuff under the `-key
and then at the bottom of that menu hang the whole aircraft specific
menu as a standard practice. At the least it would be nice to always be
able to get the POH by hitting the same keys. Thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon, I see a distribution issue which I'd like to discuss. The object database lives in it's own separate tree. Right now to use your object database a person needs to add a set of models to their base package. Then they need to install the object tree. However, from my perspective, if I want to roll up a 10x10 chunk of terrain + objects I have a big problem. I need to either roll these two trees together in one big tree (which makes it hard to change or upgrade the objects.) Or I need distribute 2 tgz files (and the end user needs to download and correctly install 2 tgz files) for each 10x10 chunk. Would it make sense to make your object database (for the entire world) part of the official base package and put it all in cvs? If we want to leave these objects as user-add-on-after-the-fact entities, then it's ok how we are doing it now, but they add a *lot* to the flightgear experience so I would really like to make them part of the default some how without imposing an overwhelming burden on the end user to do extra complex downloads and installs by hand. I'm not sure I'm explaining the issues very well, but hopefully someone understands what I mean and can offer suggestions. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Josh Babcock wrote: Jon Stockill wrote: Martin Spott wrote: Yes, it _is_ nice to have an ensemble that represents the entourage of an airport or a city centre, but a single tower somewhere "in the boonies" that VFR pilots typically use for navigation is a valuable addition as well. Yesterdays addition was a set of wind turbines for Finland, with position data kindly supplied by Esa Hyytia - you don't even need to be able to model objects to help - positions for placing models that are already available are just as useful. Jon, Is there a way to tag a number of entries in the DB as a package? It would be nice to just be able to DL "Baltimore" or "KADW" instead of figuring out what the area is and then grabbing all the objects in that area. Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Curtis L. Olson schrieb: It sounds like you aren't current with your flightgear source or executable? Could you still be running an older build of flightgear (or not fully up to date with your source code?) Curt. Did you upgrade your data from the cvs? Vassilii Hi Curt and Vassilii, after I got this error the first time (after downloading the latest CVS source and data) I did a full recompile with ./autogen.sh; configure --prefix=/fg-cvs; make; make install I worked around the problem by just changing the version file but this is not the solution. Trying now to make another CVS download and another recompile with deleting autom4te.cache (what has been a hint some time ago when I had other problems). If it does *not* work I will ask again! Thank you for your very prompt replies Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery DB (Was: San Jose)
Erik Hofman wrote: > Paul Surgeon wrote: > >> Since it's in the default San Francisco area you can submit it to Erik >> or Curt or you could sumbit it to the FlightGear scenery database. >> http://fgfsdb.stockill.org/ >> >> I'm just not sure if Curt will include objects from the FG scenery db >> into the default scenery area. Curt what's the plan with regards to >> models and the next scenery build? > > > I would like to see all new scenery object contributions to end up in > the scenery database. However, the last time I wanted to sync the base > package and the DB there were more than one objects in the same space > because of automatic object generation. > > Once that's sorted out I want to sync the base package and the DB prior > to a new release. > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > I was thinking at some point that there should be a system by which FG could figure this out automatically. If every automatically generated object had a unique ID this could be possible. An object loaded from a path listed earlier in $FG_SCENERY (and therefore probably not from the base scenery) that has the same ID could prevent the original object from being loaded. The main drawback I see is that once the ID numbers of the automatically generated objects are assigned they have to be persistent. I don't know it it's possible to do this between releases. Just to clarify, by automatically generated objects, I mean the ones that are automatically generated from other data sources by Curt's scripts. Additionally you could just not allow two objects at the exact same lat/lon. Assuming that the lat/lons in the source data never change that could serve as the unique ID. This would require some additional rules for stacking objects on top of each other. e.g. I have a somewhat generic water tower at KADW with a generic military beacon sitting on top of it. They should definitely be separate objects, but both have the same lat/lon. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Did you upgrade your data from the cvs? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Out of Town next week
On Monday 07 November 2005 12:39 pm, Durk Talsma wrote: > Tomorrow, I'm flying out to Canada I have two words for you: Sleeman Dark http://www.sleeman.com/en/html/beer/sl_brands/dark/index.htm Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Durk Talsma wrote:
> On Monday 07 November 2005 14:20, Josh Babcock wrote:
>
>>Durk Talsma wrote:
>>
>>>On Friday 04 November 2005 23:40, Christian Mayer wrote:
>>>
Durk Talsma schrieb:
>To get AI traffic going in the forseeable future, we could use quite
>a few low-polygon count aircraft models in various paint schemes. So,
Wouldn't it be better to add those models to the existing (and yet to
come) "high"-poly models as a different LOD?
>>>
>>>Would be possible, but aircraft loading and unloading time is going to be
>>>an issue.
>>
>>Good point, but I still like Christian's idea. Maybe we should settle on
>>a standard name for low poly models. I already like to include lots of
>>LOD in my models, and it is no problem to simply pull out the low poly
>>versions and save them under a different xml file. If we could come up
>>with a standard that included the following, it wouldn't be that hard to
>>follow through:
>>
>
> I've been playing a lot with the organization of some FS98 MDL files I
> downloaded over the weekend, and came to the conclusion that this might
> indeed be a good idea. One thing I thinking about aiming for is to create an
> {aircraft}-set.xml like file for the AI aircraft, that acts as both a wapper
> for the animations, models, textures, and also contains the traffic pattern
> associated with these aircraft. More specifically, what I'm thinking of is
> one xml file, that associates a model with a particular texture directory
> (a.k.a. paint scheme, a.k.a. skin, a.k.a. livery :-), which also contains the
> routing table for all aircraft of this type/livery.
>
> I'm trying to work out this idea a bit further and then we can see how it
> combines with the animations code. The most important animation is probably
> gear up/down, because that's quite visible. Flap extension/retration would
> probaly also be quite visible.
>
> Cheers,
> Durk
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
Hey, that's great. I don't have any time to help on this, but if you
come up with some sort of system I will adapt the b29, Canberra and
possibly the Colditz glider to follow it. BTW, how come the Colditz
never made it into CVS, IIRC it's GPL, and I personally thought it was a
pretty neat little project. Anyway...
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: > Martin Spott wrote: > >> Yes, it _is_ nice to have an ensemble that represents the entourage of >> an airport or a city centre, but a single tower somewhere "in the >> boonies" that VFR pilots typically use for navigation is a valuable >> addition as well. > > > Yesterdays addition was a set of wind turbines for Finland, with > position data kindly supplied by Esa Hyytia - you don't even need to be > able to model objects to help - positions for placing models that are > already available are just as useful. > Jon, Is there a way to tag a number of entries in the DB as a package? It would be nice to just be able to DL "Baltimore" or "KADW" instead of figuring out what the area is and then grabbing all the objects in that area. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Martin Spott wrote: > Hello Josh, > > Josh Babcock wrote: > > >>[...] If you can think of any other big visible structures that you >>would like to see (sorry, I'm not tackling the bridges yet, there's >>issues with the VMAP data I don't want to deal with) let me know. No >>promises though. I don't know what your schedule is, but it's probably >>moving a lot faster than mine will be. > > > Regarding these scenery objects I'd say we're not tied to any sort of > schedule at all. O.k., it actually does make sense to have a correct > representation of what belongs into the base package but that's all. > Aside from that I welcome _every_ contribution, may it be a complete > set of buildings that somehow belong together or just a single building > somewhere on our world. > Yes, it _is_ nice to have an ensemble that represents the entourage of > an airport or a city centre, but a single tower somewhere "in the > boonies" that VFR pilots typically use for navigation is a valuable > addition as well. > > Cheers, > Martin. Well, I wouldn't call http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp;JSESSIONID_ASRSEARCH=DM7BJsjBX9bNuL8dOLD7fhrXCV6r3tYmap9ZrMdr21pxzokI2Vef!1385871423!382264138?regKey=601116";> 9th and Peabody NW the boonies (in fact, I didn't even really feel comfortable leaving my car unattended there) but I get your point about scattered towers. Then again, there you have it, those are the ones you can see from 1000' AGL. I do think you will get a kick out of KADW when it's done. Lots of neat taxiways to play on, and plenty of hangars including the nuke-proof monster that they keep the presidential VC-4's in. There's even a big water tower with the air force logo painted on the side (it's the one that has the airport beacon on it). It's pleasantly close to the mall too, so once that gets done (and I'm sure it will one way or another) there will be a nice place to fly within easy UAV range. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] building plib, simgear and flightgear without scripts using make
Hi, I had originally been building plib, simgear and flightgear with a variety of build scripts. These scripts were hard to maintain, and I often found cross platform incompatibilities when I tried to use a script written for one os or shell on another os or different shell. I've been working on ways to improve cross platform building of plib, simgear and flightgear for a while now using make to handle the top level build (at the moment I've got Cygwin and Mac OS X), both with OS changes and with directory changes just for my personal use. I've got a (moderately flexible) makefile (gpled) that I'd like to offer perhaps for inclusion via the faq or in developer information or flightgear wiki (makefile attached). To avoid naming conflicts, I've named it makefile.ima. Build with make -f makefile.ima or rename it to makefile or Makefile. See the makefile for targets, some are: make co -- checks out plib, simgear and flightgear from cvs make allnoinstall -- checks out and builds plib, simgear and flightgear make all (or make with no arguments) -- checks out, builds and installs plib, simgear and flightgear cvs passwords are assumed to be in .cvspass. You can force cvs login by giving CVSLOGIN=1 as an argument to make. The makefile itself goes in BUILDDIR (see below), and make is run from the BUILDDIR directory. Please make sure that the install variable in your environment is set correctly for your os, I think that linux requires a -c option, where mac os x requires -C and cygwin -p in order to not install a file that is no different from the one already installed. This will avoid unnecessary rebuilds of dependencies. I am no makefile expert, but I hope that someone might find this helpful. Perhaps the makefile would help users trying to build their own source from CVS who are new to cvs and the unix build process. The build structure is similar to D(arrell) W(alliser)'s as that's the flightgear build process that I started with. The makefile assumes BUILDDIR and CONFIGPREFIX to be set to a valid directory for the build, a toplevel directory which contains src/lib/bin/include for plib, simgear and flightgear. Please see the makefile for documentation on both the directory hierarchy and these and other variables. I appreciate any and all comments. I'm sure the makefile's got lots of problems, but I offer the makefile as a first draft of something that might eventually be useful. Thank you! Best regards, Ima makefile.ima Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Feature/change/update/fix list since v0.9.8
* Vivian Meazza -- Monday 07 November 2005 22:11: > aircraft carriers (and fly under bridges). At the moment, carrier operations > are restricted to aircraft models using YASim FDM only. Yes, unfortunately. But I suggest that the JSBSim-carrier patch and the plib color patches are applied by packagers to make things work that aren't yet supported by the respective libs. I wouldn't wait for the projects to catch up. The carrier patch waits since a year now, doesn't it? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Georg Vollnhals wrote: Hi, after compiling the latest CVS and running the new build this message occurs ***Base package check failed ... Found version 0.9.9-pre1 at: /fg-cvs/data*** I know that Curt did some changes regarding the new version in the CVS and there must be a very simple trick a don't know to get it running right, kann you please help me :-) Thank you in advance It sounds like you aren't current with your flightgear source or executable? Could you still be running an older build of flightgear (or not fully up to date with your source code?) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
Erik Hofman > Vivian Meazza wrote: > > > You might consider adding the following: > > > > * Carrier - added working arrester wires and catapults. The carrier is > > selectable as a starting position. AI has been added to the > > carrier in the form of an operating box and an automated turn > > into/outof wind. TACAN beacon added. > > Also: > * Added a generic, XML configurable, autopilot framework, and several > high level, configurable filter implementations for use by autopilot > designers. > * Added a transponder and Altitude encoder. > * Made the instruments code much more configurable, it is now possible > to only include instruments that are actually present. > * Implemented the groundcache code which made it possible for aircraft >to follow the ground precisely and, as a result, made it possible to >land on aircraft carriers (and fly under bridges). At the moment, carrier operations are restricted to aircraft models using YASim FDM only. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Please upgrade to version: 0.9.8
Hi, after compiling the latest CVS and running the new build this message occurs ***Base package check failed ... Found version 0.9.9-pre1 at: /fg-cvs/data*** I know that Curt did some changes regarding the new version in the CVS and there must be a very simple trick a don't know to get it running right, kann you please help me :-) Thank you in advance Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
Vivian Meazza wrote: You might consider adding the following: * Carrier - added working arrester wires and catapults. The carrier is selectable as a starting position. AI has been added to the carrier in the form of an operating box and an automated turn into/outof wind. TACAN beacon added. Also: * Added a generic, XML configurable, autopilot framework, and several high level, configurable filter implementations for use by autopilot designers. * Added a transponder and Altitude encoder. * Made the instruments code much more configurable, it is now possible to only include instruments that are actually present. * Implemented the groundcache code which made it possible for aircraft to follow the ground precisely and, as a result, made it possible to land on aircraft carriers. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Monday 07 November 2005 18:53, Harald JOHNSEN wrote: > Durk Talsma wrote: > >I'm trying to work out this idea a bit further and then we can see how it > >combines with the animations code. The most important animation is > > probably gear up/down, because that's quite visible. Flap > > extension/retration would probaly also be quite visible. > > > >Cheers, > >Durk > > I was about to commit a few lines of code for those animations > (AIAircraft class only). > Hi Harald, Sounds interesting. Could you give us clue what your code does? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
Curtis L. Olson > I was scanning through the cvs logs trying to refresh my memory on what > has been changed, added, and fixed since the release of v0.9.8 (last > January). Here's what I came up with, although after staring at cvs > logs for 2 hours I started having minor hallucinations. So I'm posting > this here in hopes that people can add to it, or correct my mistakes. > If you contributed something that is missing, or poorly described here, > please send me something better. > > Thanks! > > Curt. > > For upcoming v0.9.9 ... > > * New well integrated volumetric clouds by Harald Johnsen > * Removed 'old' 3D clouds code. > * Fixed the jitter problem with 3d cockpits. > * Volumetric shadows are now supported so that aircraft can cast > shadows upon themselves as well as the ground. > * Better support for redoing livery textures on an individual aircraft. > * Support for seasonal terrain textures. (Updates to summer textures > plus new winter textures added.) > * Add status updates to the initial splash/startup screen. > * Allow switching the tower view location at any time. > * Add support for configuring views with asymmetric view frustums. > * Many updates to gui/dialog box infrastructure. Ability to alter > border thickness, change fonts, dialog boxes are draggable across > the screen, you can enable automatic line wrapping, select > colors, allow key presses to be bound to widgets, . > * Updates and enhancements to many of the dialog boxes to fix problems, > expose new features, enhance usability, etc. > > * Updated JSBSim version since the last release. (More updates > pending after this release.) > * YASim: expose "spool-time" of a jet engine as a config parameter, > add an oil temp model, support gear compression along any arbitrary > axis, > reworked MP calculations for super/turbochargers. > * Allow setting individual sample/update rates for any of the PID > autopilot stages. > > * Support TACAN instruments for mobile and fixed beacons. And an IVSI instrument. > * Deprecated old (somewhat less the spectacularly conceived) > electrical system model in favor of a much more flexible script based > system that can be tailored to any individual aircraft. > * Include an external utility that can feed saved nmea tracks back > into FlightGear. If you take a gps on a real flight with you and > capture the output, you can replay your flight in FlightGear. > > * Many updates and fixes to the joystick configuration files, many new > joysticks directly supported. > > * Removed all lingering dependencies on plib's SL sound library. > * Add support for OpenAL 1.1 and alut. > * Better cross platform compatibility with our standard network > structures. > * More cpu friendly frame rate throttling code that can leave more cpu > available for other apps. > * Various Nasal (scripting) bug fixes and language improvements. > * Various bug fixes, various platform/compiler compatibility fixes, > several memory leaks fixed. > > * New aircraft available (in various stages of developement): A380, > Boeing 314 (seaplane), Citation Bravo (glass cockpit), F-8E > Crusader, Hurricane IIb, MiG-15bis, TU-114, B29, C150, and SR20. > > * Aircraft that have had updates since the last release: 737, A-10, > AN-225, B-52F, BAC-TSR2, Citation-II (550), Comper Swift, Concorde, > Hunter, OV10, Spitfire, T37, B1900d, bo105, C172 et. al., DHC2F > (Beaver), F16, Fokker DR1 Triplane, Fokker 50 (turboprop), Fokker > 100 (jet), J3 Cub, P51, Santa, Seahawk, and 1903 Wright Flyer. > > You might consider adding the following: * Carrier - added working arrester wires and catapults. The carrier is selectable as a starting position. AI has been added to the carrier in the form of an operating box and an automated turn into/outof wind. TACAN beacon added. Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Out of Town next week
Hey Guys, With signs of a new release coming up, and a few interesting discussions I'm involved in, I thought I'd drop a note to let you know that I'm going to be out of town next week. Tomorrow, I'm flying out to Canada (Toronto and Kingstone) for a work related meeting followed by a conference. I'm back by next tuesday. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Durk Talsma wrote: I'm trying to work out this idea a bit further and then we can see how it combines with the animations code. The most important animation is probably gear up/down, because that's quite visible. Flap extension/retration would probaly also be quite visible. Cheers, Durk I was about to commit a few lines of code for those animations (AIAircraft class only). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Monday 07 November 2005 14:20, Josh Babcock wrote:
> Durk Talsma wrote:
> > On Friday 04 November 2005 23:40, Christian Mayer wrote:
> >>Durk Talsma schrieb:
> >>>To get AI traffic going in the forseeable future, we could use quite
> >>>a few low-polygon count aircraft models in various paint schemes. So,
> >>Wouldn't it be better to add those models to the existing (and yet to
> >>come) "high"-poly models as a different LOD?
> >
> > Would be possible, but aircraft loading and unloading time is going to be
> > an issue.
>
> Good point, but I still like Christian's idea. Maybe we should settle on
> a standard name for low poly models. I already like to include lots of
> LOD in my models, and it is no problem to simply pull out the low poly
> versions and save them under a different xml file. If we could come up
> with a standard that included the following, it wouldn't be that hard to
> follow through:
>
I've been playing a lot with the organization of some FS98 MDL files I
downloaded over the weekend, and came to the conclusion that this might
indeed be a good idea. One thing I thinking about aiming for is to create an
{aircraft}-set.xml like file for the AI aircraft, that acts as both a wapper
for the animations, models, textures, and also contains the traffic pattern
associated with these aircraft. More specifically, what I'm thinking of is
one xml file, that associates a model with a particular texture directory
(a.k.a. paint scheme, a.k.a. skin, a.k.a. livery :-), which also contains the
routing table for all aircraft of this type/livery.
I'm trying to work out this idea a bit further and then we can see how it
combines with the animations code. The most important animation is probably
gear up/down, because that's quite visible. Flap extension/retration would
probaly also be quite visible.
Cheers,
Durk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Passing values through the property tree
On Monday 07 November 2005 00:22, Vassilii Khachaturov wrote:
> > What I've tried to do is the following (AIModels/AIBase.cxx: about line
> > 166)
>
> Why don't you send us the cvs diff -u of that file?
Sending the file by itself isn't much use. My question isn't really related to
the syntax in this particular piece of code, but more related to the
overarching property tree design. In the mean time, I did find out that the
texture-path property does get set in the tree, but that the model loading
mechanism isn't picking it up, due to the organization of the AI model I'm
trying to load.
>
> > model = manager->getModel(path, tpath);
> > if (!(model))
> > {
> > if (tpath != "")
>
> I sincerely hope that this comparison works as expected. If e.g. tpath is
> a char* it surely is not doing what you mean :))
>
Yes, this is verified and correct. I'm tpath is a C++ string object.
Cheers,
Durk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS "make" error (Cygwin)
On Monday 07 November 2005 16:28, George Patterson wrote: > On Mon, 2005-11-07 at 15:02 +, Kevin Jones wrote: > > Hi, > > > > CVS FG source at 2:30pm (UK time) Monday 7th November fails to "make" > > on Cygwin with the following error: > > > > make[2]: Entering directory /source/src/MultiPlayer > > make[2]: *** No rule to make target `tiny_xdr.cpp', needed by > > `tiny_xdr.o'. Stop. > > > > Can anyone help? > > > > Kevin. > > Kevin, > > You need to do a make clean and re-./configure before building... The > file tiny_xdr.cpp has been renamed tiny_xdr.cxx. > You can also just delete the .deps directory under src/MultiPlayer and rerun ./configure ; make. Saves you the long rebuild time. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS "make" error (Cygwin)
On Mon, 2005-11-07 at 15:02 +, Kevin Jones wrote: > Hi, > > CVS FG source at 2:30pm (UK time) Monday 7th November fails to "make" > on Cygwin with the following error: > > make[2]: Entering directory /source/src/MultiPlayer > make[2]: *** No rule to make target `tiny_xdr.cpp', needed by > `tiny_xdr.o'. Stop. > > Can anyone help? > > Kevin. > Kevin, You need to do a make clean and re-./configure before building... The file tiny_xdr.cpp has been renamed tiny_xdr.cxx. George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS "make" error (Cygwin)
On Monday 07 November 2005 15:02, Kevin Jones wrote: > CVS FG source at 2:30pm (UK time) Monday 7th November fails to "make" > on Cygwin with the following error: > make[2]: Entering directory /source/src/MultiPlayer > make[2]: *** No rule to make target `tiny_xdr.cpp', needed by > `tiny_xdr.o'. Stop. Not just on cygwin, lots of people (including me) will have been finding that. Try "make distclean" first. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS "make" error (Cygwin)
Hi, Kevin Jones wrote: Hi, CVS FG source at 2:30pm (UK time) Monday 7th November fails to "make" on Cygwin with the following error: make[2]: Entering directory /source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Can anyone help? Had the same error yesterday on Linux. You need to rerun ./autogen.sh in the FlightGear source root. Hope this helps, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS "make" error (Cygwin)
Hi, CVS FG source at 2:30pm (UK time) Monday 7th November fails to "make" on Cygwin with the following error: make[2]: Entering directory /source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Can anyone help? Kevin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
Vassilii Khachaturov > > Hey, someone noticed :-) It was fixed in cvs Thursday last though. > > :) Of course, I keep looking at the CVS commits since I am learning FG. > Actually I kept thinking of doing this one myself, since nobody answered > my challenge yet to tell me about smth interesting to do for FG while > learning GL. > > Eventually, this should probably be configurable wrt individual > G-tolerances, and adapted to all aircraft. > I'm considering adding a selectable anti-g suit, thus upping the g tolerance. The feature can be easily added to any aircraft, but I suppose in theory ought to be added to _all_. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Martin Spott wrote: Yes, it _is_ nice to have an ensemble that represents the entourage of an airport or a city centre, but a single tower somewhere "in the boonies" that VFR pilots typically use for navigation is a valuable addition as well. Yesterdays addition was a set of wind turbines for Finland, with position data kindly supplied by Esa Hyytia - you don't even need to be able to model objects to help - positions for placing models that are already available are just as useful. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Hello Josh, Josh Babcock wrote: > [...] If you can think of any other big visible structures that you > would like to see (sorry, I'm not tackling the bridges yet, there's > issues with the VMAP data I don't want to deal with) let me know. No > promises though. I don't know what your schedule is, but it's probably > moving a lot faster than mine will be. Regarding these scenery objects I'd say we're not tied to any sort of schedule at all. O.k., it actually does make sense to have a correct representation of what belongs into the base package but that's all. Aside from that I welcome _every_ contribution, may it be a complete set of buildings that somehow belong together or just a single building somewhere on our world. Yes, it _is_ nice to have an ensemble that represents the entourage of an airport or a city centre, but a single tower somewhere "in the boonies" that VFR pilots typically use for navigation is a valuable addition as well. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Durk Talsma wrote: > On Friday 04 November 2005 23:40, Christian Mayer wrote: > >>Durk Talsma schrieb: >> >>>To get AI traffic going in the forseeable future, we could use quite >>>a few low-polygon count aircraft models in various paint schemes. So, I'd >>>be interested to know if anybody with reasonable 3d modeling skills would >>>be interested in contributing in this field. Although the traffic system >>>shouldn't be limited to commercial airliners, this is probably the area >>>I'd be working on mostly initially. So, for starters, I would like to >>>explore some models of the more popular airliners series, i,e., the >>>Boeing 7[0-8]7, Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and >>>Fokkers of course :-)). >> >>Wouldn't it be better to add those models to the existing (and yet to >>come) "high"-poly models as a different LOD? >> > > > Would be possible, but aircraft loading and unloading time is going to be an > issue. Unless we can move the aircraft loader into a separate thread, or come > up with a very sophisticated multiframe aircraft loader, I would prefer to > start with using something that is simple from the start. > > Cheers, > Durk > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Good point, but I still like Christian's idea. Maybe we should settle on a standard name for low poly models. I already like to include lots of LOD in my models, and it is no problem to simply pull out the low poly versions and save them under a different xml file. If we could come up with a standard that included the following, it wouldn't be that hard to follow through: - a naming convention for the AI/multiplayer version XML file - how many levels of detail to include and how many polys each - how much animation is acceptable to include, and what properties will drive those animations (gear and control surfaces basically, maybe some other stuff can be passed for common animations like wing sweep, engine exhaust and the concord's nose) That way, flyable planes get all the heavy stuff: panels, high poly count, sounds, extensive animations, neat Nasal routines, and all the models get a completely separate slimmed down version that can be used for planes that don't need to cater to a pilot (on the local machine at least) So for instance, I could create b29-low-poly-set.xml and b29-low-poly.ac to go along with the myriad other stuff that the b29 is made up of. The xml file would contain nothing but a description, the basic animations and "none" or some such listed as the FDM. The ac file would have however many LOD levels we settle on, and be referenced by the xml file. Once someone has gone to the trouble to make a plane that has LOD, moving this stuff over should be trivial. We just need to standardize it so that the AI and multiplayer systems know how to use them. And there's nothing to stop you from making a model that's nothing but the slimmed down version. With the "none" FDM it could just be filtered out in any frontends, and additionally FG would refuse to load it for flying. If this sounds feasible, I can cook up an example for you all to review. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Ima Sudonim wrote: >> Ima Sudonim wrote: >> >> > Oh, DC scenery, one of the many things i'd like to do if I ever get >> > around to it (health permitting) 8-) I even got a gps to plot >> > buildings' locations... just was never able to do anything. >> >> >> For what ever it's worth, Google maps seems to do a surprisingly good >> job of giving up lat/lon coordinates of objects. You have to be a >> little careful of the way urls get cached and delayed in a web >> environment, but if you get a link to the current image, you can easily >> read the lat/lon coordinates out of the link. Just click on the object >> to make sure it is centered. > > > I'll give google a try then > >> >> With a hand held gps, you aren't going to ever get to stand at the >> center of the roof (well maybe rarely) so google has a lot of advantages > > > I was planning on walking the perimeter of the buildings, but with > arthritis walking isn't really my thing. 8-( Or perhaps getting the > lat/long of one or two corners of a building and then trying to > extrapolate orientation and wall sizes from public information. Your > way is much better! > >> and might even be more accurate than doing the surveying yourself >> manually. (The wording of that last phrase didn't come out very well on >> my first attempt, but I think the final edit is slightly less >> ambiguous.) :-) > > > "surveying oneself manually" -- I think I got your meaning but it > sounds illegal in a Southern state 8-) > > Ima > >> >> Curt. > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > At one point Chris Metzler and I were talking about making a bunch of models for DC, but we both got busy. I have about half of Andrews AFB done, and am just waiting for the next scenery release when all the taxiways I did go in to place those buildings. I can send you all that stuff. I also did the Metro PD radio tower (the one that looks like the Eiffel) but haven't put it in the repository yet. Next on the list are the Nat. Cathedral, Basilica of the Immaculate Conception, Mormon Temple, Pentagon and then the Mall. Not sure what timetable I'm looking at though. If you can think of any other big visible structures that you would like to see (sorry, I'm not tackling the bridges yet, there's issues with the VMAP data I don't want to deal with) let me know. No promises though. I don't know what your schedule is, but it's probably moving a lot faster than mine will be. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
On Monday 07 November 2005 12:05, Martin Spott wrote: > You should have a closer look at the upcoming XOrg-6.9/7.0 that'll > contain OpenSource drivers for the ATI Radeon X8x0 series. Good news indeed - I knew there were OS drivers for ATI cards in exisistance, but hadn't heard too much about their usability yet... > This is why I typically buy ATI: There _is_ a chance that OpenSource > drivers appear after some time while you still have closed binary > drivers to fill the gap. With nVidia you can be certain that you'll > _never_ see OpenSource drivers. I think this makes an essential > difference. I agree with you, of course; only if one is working on a project which needs solid graphics support _now_ then one doesn't have quite the same flexibility. From what I see, the ATI binary drivers are a good bit behind nvidia in the "fit and forget" hassle-free stakes. For my own (FG!) use, though, I'll be watching the progress of those open source drivers closely because my own nvidia card is nearing retirement age and I have an aversion to running any non-open source drivers. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
AJ MacLeod wrote: > I really don't like closed source anything, and device drivers in particular, > but IME nvidia's offerings are about as good as could be hoped for in the > circumstances (although obviously not perfect.) > > I'd switch allegiance in a flash if well performing, stable, open source > drivers were available for some other reasonably priced cards though. You should have a closer look at the upcoming XOrg-6.9/7.0 that'll contain OpenSource drivers for the ATI Radeon X8x0 series. This is why I typically buy ATI: There _is_ a chance that OpenSource drivers appear after some time while you still have closed binary drivers to fill the gap. With nVidia you can be certain that you'll _never_ see OpenSource drivers. I think this makes an essential difference. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
On Sunday 06 November 2005 14:47, Mathias Fröhlich wrote: > But looking at those problems with ATIs closed source drivers, I must say > that NVidia seems to work better. Certainly I've stuck with nvidia for all jobs involving graphics ever since Matrox fell behind, and I've not had reason to regret it so far... > On the other hand, many people see massive performance hits with current > NVidia drivers in presence of OpenGL points (all our lights are such > points ...). The NVidia card at work does not show any problem with FG at > night, but that one is a extremely expensive Quadro card certified for > professional CAD use (often many points/lines). AFAIK this bug disappeared a while ago - it only affected a particular driver release (or releases, I'm not certain). Certainly I upgraded the nvidia drivers on an affected machine last week and framerates were back to normal. > All together no 'better choice' ... I really don't like closed source anything, and device drivers in particular, but IME nvidia's offerings are about as good as could be hoped for in the circumstances (although obviously not perfect.) I'd switch allegiance in a flash if well performing, stable, open source drivers were available for some other reasonably priced cards though. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
