Re: [Flightgear-devel] Views
At 7/12/03, Erik wrote: Hi, I noticed the number of views accessible using the 'v' is increasing. I think it's a good idea to have a number of views, but I propose to limit the views accessible using the 'v' key to a maximum of three and only for views that are directly related to the aircraft. For other views I would propose to use a menu entry instead. That sounds fine with me. But if it were up to me, I'd keep all the views. I would like to ask, however, that a view menu structure be in place before removing the current various 'v'-key views. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Jim Wilson wrote: Just a thought: Wouldn't we improve the rendering efficiency by building downtown urban areas as a scene...e.g. single model with one ac file for all the buildings? A few things I can think of: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. That's a good idea, but after playing with ac3d a bit I still don't know how to use a section of the texture for a particular object. So it's making things a bit harder for model designers. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Probably yes. I had the same issue with audio files. I've managed to overcome this problem by implementing a 'cache' which holds the complete location of the file, and a pointer to the buffer containing the file. Maybe we can do this for textures also (before passing them to plib)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. That's a good idea, but after playing with ac3d a bit I still don't know how to use a section of the texture for a particular object. So it's making things a bit harder for model designers. Recent release(s) (this year) have a texture coordinet editor. It's on the menu. There was actually a way to do it before, but it was very time consuming. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Probably yes. I had the same issue with audio files. I've managed to overcome this problem by implementing a 'cache' which holds the complete location of the file, and a pointer to the buffer containing the file. Maybe we can do this for textures also (before passing them to plib)? There have been a few other reasons that I've been thinking that we should implement our own loader for 'ac' files. Two big ones are overriding texture file names in the xml wrapper, and having more control over the building of the scene graph (plib's optimization problems). This could be another one. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] nmea solved!
Right there is no problem with my box. What is happening is that the connection is opened (I checked netstat for this) I then decided to chance running Atlas and sure enough I get the plane and the movement. The only problem being flightgear is still printing the previous message to the log - even when it's working. -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: http://sourceforge.net/mailarchive/forum.php?thread_id=2748130forum_id=4479 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. We will have problems with non-flat terrains. Actually, I use fgsd to position buildings and the elevation is computed automatically from the scenery. I bought an image of the Financial District at TerraServer and with the metadata provided, I was able to position this image exactly in the scenery. Then positionning buildings is quite easy. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. A Blender loader would be cool too. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. That's a good idea, but after playing with ac3d a bit I still don't know how to use a section of the texture for a particular object. So it's making things a bit harder for model designers. Recent release(s) (this year) have a texture coordinet editor. It's on the menu. There was actually a way to do it before, but it was very time consuming. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Probably yes. I had the same issue with audio files. I've managed to overcome this problem by implementing a 'cache' which holds the complete location of the file, and a pointer to the buffer containing the file. Maybe we can do this for textures also (before passing them to plib)? Do you mean dynamic object textures are also duplicated ? There have been a few other reasons that I've been thinking that we should implement our own loader for 'ac' files. Two big ones are overriding texture file names in the xml wrapper, and having more control over the building of the scene graph (plib's optimization problems). This could be another one. I vote for to remove this sharp edge smoothing artefact. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
As a blender user I'd like to see blender supporting some of these formats natively... I'm getting the urge to do something about that, at the moment it falls about 20th on my TODO list. Above that is closer integration of blender and the gimp for UV textures through the python interface. On Sun, 2003-07-13 at 10:15, Erik Hofman wrote: Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: http://sourceforge.net/mailarchive/forum.php?thread_id=2748130forum_id=4479 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Views
Erik Hofman writes: I mean we now have a tower view, we might come up with a final Approach view and someday somebody will come by and asks for a windsock view. Those are really candidates for a view selection dialog. Two truly useful ones would be a ground-chase view and a nearest-airport view. When you're flying anything but a circuit, the control tower view gets useless very fast. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Urban building model efficiency
Jim Wilson writes: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. Static scenery should be positioned only once, when the tile is loaded, so there's no on-going overhead. 2) Use a single texture file containing all the textures mapped to the various buildings in the model. Rendering efficiency. I think all that matters is the total amount of texture memory used. 3) Savings for buildings that use the exact same texture. More efficiency. How often do different geometries use the same texture? In any case, we can accomplish the same thing with separate models, simply by making sure that no texture is loaded more than once. The 2D panel already does that, but we'd have to find a way to hook into the plib AC3D loaded. Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Any comment, plib types? We should also set up static model support in the scenery loader so that each static model is loaded only once and reference counted. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Frederic Bouvier writes: I vote for to remove this sharp edge smoothing artefact. All of our airplanes will start looking a lot worse. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Erik Hofman writes: I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: http://sourceforge.net/mailarchive/forum.php?thread_id=2748130forum_id=4479 I think that skyscrapers need a visual range of much more than 5 nm. As far as I understand, we are already cropping out anything beyond the current visual range, but when visibility is OK, we need to see skyscrapers from at least 20 nm (~40,000m) away. They are *extremely* visible from the air (try flying anywhere near Manhattan, Montreal, or Toronto, and you'll see what I mean). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urban building model efficiency
Jim Wilson writes: Erik Hofman [EMAIL PROTECTED] said: 1) Less effort positioning buildings (easier to move them around if need be). Just place the origin at some landmark in the scene and place the whole thing in one shot. I really think we should switch over to .ssg files for scenery objects. The problem with .ac files is that we need to recalculate the normal vectors (for each object?). I've tested them with some other file formats and they all load way faster. .ssg files are *much* faster loading then anything else. So long as we have a good converter, it should be fine to do that. One possibility would be to cache .ac files as .ssg files on the disk. From the modeler's perspective it is probably going to be easier to have .ac files in the base package. we could keep the .ac .3ds .whatever files as they are in the base package and require that you run a 'scenery' compiler before you actually run FGFS after a scenery update. AFAICT it would even be faster to keep the .ac name in the xml files and do the extension manipulation in our code and do a fstat() on filetimes and compile the .ac to .ssg if necessary Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rsync access to base package - again
Hi! I'm afraid of getting expelled from this list someday for bringing this subject up so often, but I haven't received an answer yet. My problem is that updating the basepackage via a dialup-connection and CVS seems almost impossible to me. First, the cvs client is obviously _sending_ every one of the local files to the server before updating my local copy. See this (partial) result of cvs -t update -APd: cvs update: notice: main loop with CVSROOT=:pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 - rename(CVS/Entries.Backup,CVS/Entries) - unlink(CVS/Entries.Log) - Sending file `AtlasPalette' to server - Sending file `ChangeLog' to server - Sending file `Thanks' to server - Sending file `joysticks.xml' to server - Sending file `keyboard.xml' to server - Sending file `large.sky' to server - Sending file `materials.dtd' to server ... Sending default.apt.gz alone kept my modem busy for about 5 minutes. Is there something wrong with my cvs-client or is this the normal behavior? Second, this method of updating seems a waste of bandwidth to me, as the bigger part of all the files transmitted to and from the server are likely not to have changed since the last update. Curt, could you therefore enable rsync-access to the basepackage at flightgear.org? This would make it possible for people without fast internet connections like me to run the latest release of flightgear. Thanks, Matthias ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync access to base package - again
Matthias Heukäufer wrote: Hi! I'm afraid of getting expelled from this list someday for bringing this subject up so often, but I haven't received an answer yet. My problem is that updating the basepackage via a dialup-connection and CVS seems almost impossible to me. First, the cvs client is obviously _sending_ every one of the local files to the server before updating my local copy. See this (partial) result of cvs -t update -APd: Well, CVS hos to know the difference between the file on the server and the local file. One way is to receive *all* files and compare them locally, but you could call this approach ftp ... Another way is to sent the file to the server and let the server decide if they are different. Sending default.apt.gz alone kept my modem busy for about 5 minutes. Is there something wrong with my cvs-client or is this the normal behavior? Second, this method of updating seems a waste of bandwidth to me, as the bigger part of all the files transmitted to and from the server are likely not to have changed since the last update. Try using cvs with the -z5 option. This compresses the files quite a bit. Curt, could you therefore enable rsync-access to the basepackage at flightgear.org? This would make it possible for people without fast internet connections like me to run the latest release of flightgear. While rsync is a very good way to sync two files, it really has an advantage when a binary marked file has changed in CVS. So for the base package this could give a faster download *and* less bandwidth consumption for the university. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urban building model efficiency
David Megginson writes: Jim Wilson writes: Is this true that the textures get reloaded, and is there some way to share textures between objects and not just save disk space? Any comment, plib types? SSG models should already be sharing textures based on 'Texture Name' see ssgTexture* ssgLoaderOptions::createTexture(..) and ssgTexture* ssgTextureArray::findByFilename ( .. ) for the mechanism used. Note that this can be changed see class ssgLoaderOptions and ssgSetCurrentOptions(). We should also set up static model support in the scenery loader so that each static model is loaded only once and reference counted. This should be easy enough todo SSG will 'just do' the correct thing wrt to memory as long as the refcnt mechanism is respected Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Erik Hofman wrote: I tested this one a bit today and even a LOD of 1 meters will give good results on the SFO skyscrapers for normal (non clear sky conditions), it has just one drawback: after conversion FlightGear doesn't seem to find the textures anymore: That's odd. After tweaking the utility a bit so it can support models without LOD, the textures reappeared after converting them with infinitive LOD ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Views
On 12 Jul 2003 22:49:22 +0100, Christopher S Horler [EMAIL PROTECTED] wrote: I like the idea of a menu for views... Is there a way to reset the view - I sometimes move the view outside of the plane around. I would like to see it simple - two views one of the outside and one of the cockpit (cycled by v). Then Ctrl v could be bound to resetting the view. All remaining views and customized views specified in some xml file could be in the 'view' menu. snip How about two basic views on 'v' in the standard setup, the rest on a menu and a capability to select items off the menu (or at least in XML) for addition to the 'v' (need a better term, 'hotkey views'?) views? One nice feature would be the ability to group sets of views together and switch between sets of 'hotkey' views. The user could, for example, set up view sets such as 'Landing', 'Taxi', 'Flight Test', '3D Model Test' ... Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - [Post attack] crew changes would have been based on crew availability.' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Simgear configure tweaks
Most systems are compatable with the STL So this should be only be needed for those that need a little extra compatability help :-)) Cheers Norman 650 SimGear $ cvs diff configure.ac Index: configure.ac === RCS file: /var/cvs/SimGear-0.3/SimGear/configure.ac,v retrieving revision 1.39 diff -r1.39 configure.ac 43a44,45 compatability_DIR= 52a55 compatability_DIR=compatability 398a402,403 AC_SUBST(compatability_DIR) 651 SimGear $ cvs diff simgear/Makefile.am Index: simgear/Makefile.am === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/Makefile.am,v retrieving revision 1.7 diff -r1.7 Makefile.am 16c16 compatibility \ --- $(compatability_DIR) \ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear configure tweaks
Norman Vine wrote: Most systems are compatible with the STL So this should be only be needed for those that need a little extra compatibility help :-)) Hmm, alright ... ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Views
On Sunday 13 July 2003 10:54, David Megginson wrote: Erik Hofman writes: I mean we now have a tower view, we might come up with a final Approach view and someday somebody will come by and asks for a windsock view. Those are really candidates for a view selection dialog. Two truly useful ones would be a ground-chase view and a nearest-airport view. When you're flying anything but a circuit, the control tower view gets useless very fast. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ I think a ground chase view would be great. I'd also like an air chase view that follows bearing but that shows gust and turbulence effects but something like that has been proposed, I think;) As for putting some of the views in menus - hmm... I'm less keen about that because when I change views I want to do it quickly and often I'll only want to check a view for a second. For example, when landing I'll often quickly switch between the cockpit, the two chase views and the tower views, using different magnication and orientation settings for each view, and spending less than a second in most of them. I suspect this would be tricky to do if some of them could only be accessed via a drop down menu - the moment would have passed and I'd have had to move one of my hands from the js or kb to grab the mouse. Setting up the views with some of them in a menu would be ok by default if it was still easy to add the extra entries to the kb list. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
On Sunday 13 July 2003 10:39, Frederic Bouvier wrote: I vote for to remove this sharp edge smoothing artefact. -Fred That would save me a lot of time:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Views
I agree with this completely. I do the same. I was wondering about an additional feature... Other than recording entire flights, I've never seen what my own [attempted] landing looked like Would it be possible to add a feature where the simulation would immediately be paused, and rewinded for say, 5 seconds to give an instant replay? When the replay catches up to simulation time, simply return to the paused state? Then, during the replay, I can watch from a chase or tower view, etc. Yes, my entire world was affected by my purchase of a TiVo. ;) -Matt Lee Elliott wrote: On Sunday 13 July 2003 10:54, David Megginson wrote: Erik Hofman writes: I mean we now have a tower view, we might come up with a final Approach view and someday somebody will come by and asks for a windsock view. Those are really candidates for a view selection dialog. Two truly useful ones would be a ground-chase view and a nearest-airport view. When you're flying anything but a circuit, the control tower view gets useless very fast. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ I think a ground chase view would be great. I'd also like an air chase view that follows bearing but that shows gust and turbulence effects but something like that has been proposed, I think;) As for putting some of the views in menus - hmm... I'm less keen about that because when I change views I want to do it quickly and often I'll only want to check a view for a second. For example, when landing I'll often quickly switch between the cockpit, the two chase views and the tower views, using different magnication and orientation settings for each view, and spending less than a second in most of them. I suspect this would be tricky to do if some of them could only be accessed via a drop down menu - the moment would have passed and I'd have had to move one of my hands from the js or kb to grab the mouse. Setting up the views with some of them in a menu would be ok by default if it was still easy to add the extra entries to the kb list. LeeE ___ 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
Re: [Flightgear-devel] Urban building model efficiency
On Sunday 13 July 2003 11:14, Norman Vine wrote: Jim Wilson writes: we could keep the .ac .3ds .whatever files as they are in the base package and require that you run a 'scenery' compiler before you actually run FGFS after a scenery update. While it's great that we _can_ use .3ds models, until we can texture them I think we should consider them only temporary (I haven't forgotten the TSR2 or A10 - they've got to be re-done) LeeE AFAICT it would even be faster to keep the .ac name in the xml files and do the extension manipulation in our code and do a fstat() on filetimes and compile the .ac to .ssg if necessary Norman ___ 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
Re: [Flightgear-devel] Urban building model efficiency
On Sunday 13 July 2003 11:07, David Megginson wrote: Frederic Bouvier writes: I vote for to remove this sharp edge smoothing artefact. All of our airplanes will start looking a lot worse. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. I get around this by splitting area into separate surfaces, which apart from extra work, increases the object and vertex count (though I dunno how much of a problem that might be). LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
On Sunday 13 July 2003 00:01, [EMAIL PROTECTED] wrote: Hello, [snip] 3. What about AI controlled airplanes AND ships? It would be great to see some airplanes in the air and ships on the sea in flighgear that fly/drive their routes. Is such a dynamic scenery feature in development? If yes, how long do you expect (in months) will it take to see such feature in a stable version? Will this feature be scalable? In other words, the faster my computer the more ships and airplanes i will be able to see? Ships sounds like a great idea and shouldn't be too difficult to implement (not that I'm volunteering). Someone mentioned carrier landings recently didn't they? :) 4. Citys at night seem to be a problem. Last week i flew over Los Angelas by night in flightgear, but the city was very very dark by night. In realitiy Los Angelas is extremly bright at night. So the question is, is someone working on this? Are their any night city scenery textures in the work including support for brighter ambient light (- like bright clouds and yellow/orange looking fog and things like that)? Night textures would be nice too but texture space is at a bit of a premium atm. ;) There are already some nice sky effects though. http://www.overthetop.freeserve.co.uk/YF23-20030615-fgfs-screen-017.jpg LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some Questions about Flightgear
Lee Elliott writes: Night textures would be nice too but texture space is at a bit of a premium atm. ;) There are already some nice sky effects though. Texture space shouldn't be a problem I am assuming of course that the 'daytime' and the 'nighttime' textures wouldn't need to be in memory at the same time :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
On Sunday 13 July 2003 14:38, Norman Vine wrote: Lee Elliott writes: Night textures would be nice too but texture space is at a bit of a premium atm. ;) There are already some nice sky effects though. Texture space shouldn't be a problem I am assuming of course that the 'daytime' and the 'nighttime' textures wouldn't need to be in memory at the same time :-) Norman I think they'd have to be blended to look any good at dusk/twilight. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some Questions about Flightgear
Lee Elliott writes: On Sunday 13 July 2003 14:38, Norman Vine wrote: Lee Elliott writes: Night textures would be nice too but texture space is at a bit of a premium atm. ;) There are already some nice sky effects though. Texture space shouldn't be a problem I am assuming of course that the 'daytime' and the 'nighttime' textures wouldn't need to be in memory at the same time :-) Norman I think they'd have to be blended to look any good at dusk/twilight. Good point but ... It would be cool to have lights in the windows and I doubt if we need to 'blend' them on :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
Lee Elliott writes: On Sunday 13 July 2003 14:38, Norman Vine wrote: Lee Elliott writes: Night textures would be nice too but texture space is at a bit of a premium atm. ;) There are already some nice sky effects though. Texture space shouldn't be a problem I am assuming of course that the 'daytime' and the 'nighttime' textures wouldn't need to be in memory at the same time :-) Norman I think they'd have to be blended to look any good at dusk/twilight. How would you do night texture for buildings, with lit windows that need emissive color. Do we need multitexturing to apply an emissive map ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
On Sunday 13 July 2003 15:33, Norman Vine wrote: Lee Elliott writes: On Sunday 13 July 2003 14:38, Norman Vine wrote: Lee Elliott writes: Night textures would be nice too but texture space is at a bit of a premium atm. ;) There are already some nice sky effects though. Texture space shouldn't be a problem I am assuming of course that the 'daytime' and the 'nighttime' textures wouldn't need to be in memory at the same time :-) Norman I think they'd have to be blended to look any good at dusk/twilight. Good point but ... It would be cool to have lights in the windows and I doubt if we need to 'blend' them on :-) Cheers Norman My bad - was thinking about ground area scenery textures, not model building textures. My first thought when I realised I had the wrong end of the stick was you're right - you wouldn't need to blend the lights in on a building - exactly the opposite in fact. It's just occurred to me though, that the 3d s/w I use makes use of blending to achieve global illumination effects. While the algorithm it uses would be too heavy and complex for a sim, I wonder if it still might be workable. What I'm thinking is that if an illuminated window had a degree of blurring it would lighten the surrounding area too. I think it would need to be done in two stages - the first to deal with the window area, with hard edges, and the second to handle the blur/lighting overspill, which would blur/smear/spread the light over a larger area of the texture. It would have to be at a distinctly lower intensity so that the window outline is still clear and sharp through the blur but light enough to mimic the overspill. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Lee Elliott writes: Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. It's a bit of a mess, really. The problem is that AC3D is (or was, until recently) the only general format that worked fully with plib, but AC3D files do not contain information on normals. If there's a better semi-standard format that we can use -- one that we can easily get From AC3D and Blender and import into plib with object names, normals, and texture information intact -- I'll be happy to switch to it. All the best, david -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about clouds in Flightgear vs. FS2004
There has been work started on very impressive 3D clouds. That said there's a lot that FlightGear has them MSFS probably never will have. That sounds great. :) I tried to compile the cvs version last night but got an error, do you have a screenshot of those 3d clouds? BTW maybe you can help me with that error of the cvs version: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/games/flightgear-cvs/lib/FlightGear\ -g -O2 -c -o main.o `test -f main.cxx || echo './'`main.cxx main.cxx:42: simgear/screen/extensions.hxx: No such file or directory make[2]: *** [main.o] Error 1 make[2]: Leaving directory `/home/oliver/x/src/flightgear-cvs/source/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/oliver/x/src/flightgear-cvs/source/src' make: *** [all-recursive] Error 1 Sounds like an error with SimGear. Do i need to install the cvs version of simgear or is SimGear 0.3.3 new enough? Not the least of which is the fact that if you know how to program you can get those cool clouds before MSFS 2004 gets released by finishing the work that was started by someone else. And you won't have to shell out $50 every year or two to the selfish little pseudogeek's empire anymore. Yes, i allready started learning OpenGL. :) I bought a book about OpenGL and i am on page 255 of 433 at the moment but i still need some weeks/months for the rest (including learning how plib and flighgear works). Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
Lee Elliott writes: Ships sounds like a great idea and shouldn't be too difficult to implement (not that I'm volunteering). Someone mentioned carrier landings recently didn't they? :) That's harder -- we'll have to do some work to make sure that the planes on the carrier move when the carrier itself moves -- otherwise, it will just slip out from under the planes on its deck. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
I am the one that designed the San Francisco buildings ( and San Mateo Bridge ). They look great, very good work. I am not aware of development for other cities. I would not design the whole earth alone. People are invited to contribute for other places. I have a question about this. Yesterday i visited the terragear Project website an read at the following page ( http://terragear.sourceforge.net/docs/scenery-tutorial/fg-scenery-tutorial.html ) about vmap that sentence: This dataset (formerly known as the Digital Chart of the World) contains non-airport vector data for all of North America, including landmass (shorelines), lakes, rivers, cities, towns, roads, railroads, rivers, landcover, and many other coverages that we are not using yet. Now my question is, why are you don't using those vmap data? And if you use those, at what detail do you use them? At maximum detail: everything the vmap data gives or lower details to save framerates or internet hosting costs? I also visited the the FlightGear Scenery Designer Home Page which is for creating excat sceneries but the terragear website says: TerraGear generates FlightGear scenery automatically from free, publicly-available geographical datasets: you do not have to (and are currently not able to) paint roads, rivers, and so forth by hand. So my question is when i don't have to create those things by hand because vmap data is available and accurate enough why do i need that Scenery Designer to modify the landscape? (That i need it for buildings too is obvious, that's not what i mean) Or other question, are the vmap data (especially Areas over Europ) not accurate enough so that i have to use the Scenery Designer and edit the landscape by hand? (like on those screenshots: http://fgsd.sourceforge.net/screenshots.html) Good source of information about Sky Scrapers are here : http://skyscrapers.com http://skyscraperpage.com Thanks for the link. Their would be a problem of hosting those models that don't fit in the base package. So if i edit some sceneries does that mean that they wouldn't be added to the additional scenery data? http://www.flightgear.org/Downloads/world-scenery.html Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about clouds in Flightgear vs. FS2004
On Sun, Jul 13, 2003 at 05:02:44PM +0200, [EMAIL PROTECTED] wrote: There has been work started on very impressive 3D clouds. That said there's a lot that FlightGear has them MSFS probably never will have. That sounds great. :) I tried to compile the cvs version last night but got an error, do you have a screenshot of those 3d clouds? I get a core dump in 0.9.2 when trying to run it with 3d clouds. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
I wonder if it's possible to write a plib loader for blender files? On Sun, 2003-07-13 at 16:00, David Megginson wrote: Lee Elliott writes: Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. It's a bit of a mess, really. The problem is that AC3D is (or was, until recently) the only general format that worked fully with plib, but AC3D files do not contain information on normals. If there's a better semi-standard format that we can use -- one that we can easily get From AC3D and Blender and import into plib with object names, normals, and texture information intact -- I'll be happy to switch to it. All the best, david -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about clouds in Flightgear vs. FS2004
There has been work started on very impressive 3D clouds. That said there's a lot that FlightGear has them MSFS probably never will have. That sounds great. :) I tried to compile the cvs version last night but got an error, do you have a screenshot of those 3d clouds? go to http://www.first-day.org and rummage around in the jpgs directory ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
Oliver C wrote: I have a question about this. Yesterday i visited the terragear Project website an read at the following page ( http://terragear.sourceforge.net/docs/scenery-tutorial/fg-scenery-tutorial.html ) about vmap that sentence: This dataset (formerly known as the Digital Chart of the World) contains non-airport vector data for all of North America, including landmass (shorelines), lakes, rivers, cities, towns, roads, railroads, rivers, landcover, and many other coverages that we are not using yet. This dataset is only accurate and complete to create maps at the scale 1:1.000.000. They do not match well compared to data at 1:25.000 ( topo maps ). For exemple, it doesn't include the width of rivers. Now my question is, why are you don't using those vmap data? vmap was used to build the latest scenery at randtechnologies by William Riley ( see the download page ) And if you use those, at what detail do you use them? At maximum detail: everything the vmap data gives or lower details to save framerates or internet hosting costs? I also visited the the FlightGear Scenery Designer Home Page which is for creating excat sceneries but the terragear website says: TerraGear generates FlightGear scenery automatically from free, publicly-available geographical datasets: you do not have to (and are currently not able to) paint roads, rivers, and so forth by hand. So my question is when i don't have to create those things by hand because vmap data is available and accurate enough why do i need that Scenery Designer to modify the landscape? (That i need it for buildings too is obvious, that's not what i mean) It depend on how accurate you want your scenery. If it is OK for you to see the rivers at the top of mountains, crops instead of forrest, and missing lakes, FGSD is useless for you. But you wouldn't cure the whole world with fgsd. It would be more efficient to find a better dataset, but I am afraid they are not free. Or other question, are the vmap data (especially Areas over Europ) not accurate enough so that i have to use the Scenery Designer and edit the landscape by hand? (like on those screenshots: http://fgsd.sourceforge.net/screenshots.html) vmap0 seems to be evenly (not) accurate around the world, but good terrain elevation at good accuracy ( 90m or less ) is not freely available ( yet ?) for outside America ( that is new. I year ago, it was only US ). FGSD is there to enhance scenery by hand using image data ( map, aerial photo ). This is only applicable for very narrow areas ( a town or an airport ). ( Disclaimer: FGSD, which I maintain, is for from being usable for anything else than placing 3D object in the scenery for the moment. And I am distracted creating 3D models for fg ) ... Their would be a problem of hosting those models that don't fit in the base package. So if i edit some sceneries does that mean that they wouldn't be added to the additional scenery data? http://www.flightgear.org/Downloads/world-scenery.html The world is based on data ( height, contours, airports ). If you don't have data made by other at hand ( building, bridge, special hand-edited contours ), they will not appear in the scenery. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Golden Gate Bridge
A new bridge, the famoust, is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-golden-gate-01.png -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
[EMAIL PROTECTED] writes: This dataset (formerly known as the Digital Chart of the World) contains non-airport vector data for all of North America, including landmass (shorelines), lakes, rivers, cities, towns, roads, railroads, rivers, landcover, and many other coverages that we are not using yet. The default scenery in the base package uses the vmap0 data at maximum available resolution. Curt's official scenery for the rest of the world does not, yet, but this scenery does: http://www.randdtechnologies.com/fgfs/newScenery/world-scenery.html Note that the vmap0 scenery is nominally 1:1,000,000 resolution, like the World Aeronautical Charts (WAC's). In fact, it *is* the WACs, at least around here -- I bought the Canadian WAC for the area around Ottawa, and it contains exactly the same polygons and errors as the vmap0 dataset, right down to a missing city to the west of Ottawa. At that resolution, you cannot expect every twist and bend of a road or riverbank to be modelled accurately. vmap0 does a much better job of the Great Lakes shorelines than the other dataset we were using, but it can be a bit off on other stuff -- it's not unusual to find a road 100m or so off of where it should be (possibly much more outside North America). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
Christopher S Horler writes: I wonder if it's possible to write a plib loader for blender files? Very much so. An easier solution, though, would be to fix plib's VRML1 loader so that it works with *.wrl files exported by Blender. Nobody likes VRML1, but everybody can import and export it, and I think that it can include explicit normals. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Golden Gate Bridge
Frederic Bouvier writes: A new bridge, the famoust, is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-golden-gate-01.png Gorgeous! I've been waiting for this one for a long time -- Marin County looked so lonely sitting there with no link to SF. Does anyone want to put a static model of a freighter steaming under it? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
Frederic Bouvier writes: This dataset is only accurate and complete to create maps at the scale 1:1.000.000. They do not match well compared to data at 1:25.000 ( topo maps ). For exemple, it doesn't include the width of rivers. There is a cutoff where rivers switch from polygon to line coverage. I'm guessing that it might be around 500m wide, but I'm not sure (and I'm not even sure if it's consistent across vmap0). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Questions about Flightgear
Lee Elliott write: True, the carrier landings would require more work but a few ordinary ships on the oceans would make flying across vast expances of water a bit more interesting. Just design a few ship models, the dynamic scenery would do the rest. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about clouds in Flightgear vs. FS2004
On Sunday 13 July 2003 17:26, John Wojnaroski wrote: There has been work started on very impressive 3D clouds. That said there's a lot that FlightGear has them MSFS probably never will have. That sounds great. :) I tried to compile the cvs version last night but got an error, do you have a screenshot of those 3d clouds? go to http://www.first-day.org and rummage around in the jpgs directory Those clouds look terrific. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Golden Gate Bridge
On Sunday 13 July 2003 12:25, David Megginson wrote: Frederic Bouvier writes: A new bridge, the famoust, is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-golden-gate-01.png Gorgeous! I've been waiting for this one for a long time -- Marin County looked so lonely sitting there with no link to SF. I agree, that looks Great! I've been waiting to see it as wll :) WillyB Does anyone want to put a static model of a freighter steaming under it? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Golden Gate Bridge
James Turner writes: Another thing to consider is the flip-side - being able to taxi *on* bridges, You can do this in FGFS now You just can't fly lower then the highest point at any location I don't know how much collision detection SSG handles, SSG doesn't do collision detection period, SSG does do HOT height over terrain but this is almost a diirect copy of what I worked out for FlightGear If you want collision not HOT I suggest you look into integrating 'ode' or 'opcode' into FlightGear http://opende.sourceforge.net/ode-collision-porting.html http://www.codercorner.com/Opcode.htm Note http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/plib/plib/demos/ode_demo/Attic/simple.cpp?rev=1.1content-type=text/vnd.viewcvs-marku p Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Turbulence Change
So far, JSBSim is the only FDM that supports turbulence. Up until now, turbulence was controlled by a single variable setting its magnitude; now, it's controlled by both magnitude and rate. Here are the new properties, replacing /environment/turbulence-norm and its equivalents in the weather config: /environment/turbulence/magnitude-norm /environment/turbulence/rate-hz The magnitude is a value from 0.0 (none) to 1.0 (severe). JSBSim treats it as a curve rather than a line, so severity increases slowly at the start and then rapidly toward the highest values. This is the highest (or lowest) peak that the turbulence is capable of hitting. The default is 0.0. The rate is the maximum number of times per second that the turbulence can move from neutral to its extreme high or low, or back again. This information is also available online at http://www.seedwiki.com/page.cfm?doc=turbulenceinfowikiid=2418wpid=0 All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Suggested Flight
Here's a suggested flight, after you do a cvs update on the base package to get the latest SF scenery. Start at Half Moon Bay, Runway 30, with 32km visibility: fgfs --airport=KHAF --runway=30 --visibility=32000 Takeoff in the C172 and climb to 1000 feet, then continue north over the water, near the shoreline. Look out the right window frequently. Fly up the coast, overfly the Golden Gate Bridge, continue around the top of the peninsula past downtown SF, then fly on to KSFO for a landing. We now have lots to see. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about clouds in Flightgear vs. FS2004
go to http://www.first-day.org and rummage around in the jpgs directory Thanks, those clouds look good on the screenshot but it would be interesing to see how they look and behave in game when fyling into them. I managed to compile the cvs version, now it works but when i try to start it with the option --enable-clouds3d it gives me the following error message: Unknown option '--enable-clouds3d' From ./fgfs --help -v i can see that --enable-clouds3d should be the right option to activate them but that doesn't work. So how can i enable those 3d clouds? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Suggested Flight
fgfs --airport=KHAF --runway=30 --visibility=32000 Nice work folks! I noticed one recent and rather awkward change though -- FlightGear changes the keyboard repeat settings of the X server! Not good, since all other programs are also affected! Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Views
At 7/13/03, Erik wrote: Michael Selig wrote: I would like to ask, however, that a view menu structure be in place before removing the current various 'v'-key views. That was the intention. Did something go wrong? Something go wrong --- I did not mean to imply that. I've not done a cvs check-out lately. My main point in making the comment was let's not lose capability along the way! But again, I'd rather keep all current v-key views. It's a lot faster hitting a single key than mousing around while trying to fly. At a minimum, I'd like to keep three views that function w/ the v-key: - cockpit of course - chase (external) - chase (external w/ fixed view direction, e.g. always looks North or whatever direction w/ the mouse) With the latter two, it'd be really nice to get back the 2D HUD (vs the 3D one that moves around). I used the old 2D HUD a lot w/ demos and in my own model development. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about clouds in Flightgear vs. FS2004
So how can i enable those 3d clouds? You will have to do some coding. We got it working but it was never fully integrated with the plib scene graph and it was decided to turn-off the code. Can't tell you what is needed since I've not kept pace with the 0.9.2 release or CVS versions.You might go back and follow the thread on cloud discussions over the past year for some insight and history on the subject. JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Views
On Monday 14 July 2003 00:35, Michael Selig wrote: At 7/13/03, Erik wrote: Michael Selig wrote: I would like to ask, however, that a view menu structure be in place before removing the current various 'v'-key views. That was the intention. Did something go wrong? Something go wrong --- I did not mean to imply that. I've not done a cvs check-out lately. My main point in making the comment was let's not lose capability along the way! But again, I'd rather keep all current v-key views. It's a lot faster hitting a single key than mousing around while trying to fly. At a minimum, I'd like to keep three views that function w/ the v-key: - cockpit of course - chase (external) - chase (external w/ fixed view direction, e.g. always looks North or whatever direction w/ the mouse) With the latter two, it'd be really nice to get back the 2D HUD (vs the 3D one that moves around). I used the old 2D HUD a lot w/ demos and in my own model development. Regards, Michael Same here about using the HUD for development. The mini HUD still works ok in rotated chase views though. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Views
Lee Elliott writes:
On Monday 14 July 2003 00:35, Michael Selig wrote:
With the latter two, it'd be really nice to get back the 2D HUD (vs the 3D
one that moves around). I used the old 2D HUD a lot w/ demos and in my own
model development.
Same here about using the HUD for development. The mini HUD still works ok in
rotated chase views though.
Nothing says you can't change your local source
The following reverts to the previous HUD
Norman
$ cvs diff hud.cxx | tee hud3d.diff
Index: hud.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/hud.cxx,v
retrieving revision 1.4
diff -r1.4 hud.cxx
245,246c245,246
if( HUD_style == 1)
{
---
//if( HUD_style == 1)
//{
248,250c248,250
factor = 1;
factor = (640./55.) / factor;
}
---
//factor = 1;
//factor = (640./55.) / factor;
//}
996,1000c996,1000
if( HUD_style == 1)
{
fgUpdateHUDVirtual();
return;
}
---
//if( HUD_style == 1)
//{
//fgUpdateHUDVirtual();
//return;
//}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Suggested Flight
Major A writes: Nice work folks! I noticed one recent and rather awkward change though -- FlightGear changes the keyboard repeat settings of the X server! Not good, since all other programs are also affected! We're not smart enough to do that ourselves (i.e. FlightGear doesn't understand its host OS that thoroughly). Something must be going wacko in plib, or, more likely, glut. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about clouds in Flightgear vs. FS2004
[EMAIL PROTECTED] [EMAIL PROTECTED] said: go to http://www.first-day.org and rummage around in the jpgs directory Thanks, those clouds look good on the screenshot but it would be interesing to see how they look and behave in game when fyling into them. I managed to compile the cvs version, now it works but when i try to start it with the option --enable-clouds3d it gives me the following error message: Unknown option '--enable-clouds3d' It looks like all you need to do is go into the SimGear/simgear/scene/sky directory and uncomment the SUBDIR line in the Makefile.am file. This is the way building the 3d clouds was disabled in the last release. Other than that, I'm not exactly sure how well they are working. They need more work, the most significant step would be moving the rendering over to a plib scene graph. BTW if you are reading about Open GL, you might find plib interesting. It can save a lot of programming time, not to mention it provides a 3D application framework (which FlightGear is using). You may find it useful to work at learning the plib API and then eventually digging deeper to understand the underling Open GL work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Golden Gate Bridge
Frederic Bouvier [EMAIL PROTECTED] said: A new bridge, the famoust, is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-golden-gate-01.png Wow! What a nice view :-) I've been having a ball flying circles around the new construction the last couple weeks, checking it all out. Great work! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Urban building model efficiency
David Megginson [EMAIL PROTECTED] said: Lee Elliott writes: Is there any way to set a constriant on it? It's fine when it's smoothing angles 90deg 270 but it would be better if it didn't try to do sharper angles. This seems to be the cause of the artifacts often seen on models, for example at the wing traiing edges. It's a bit of a mess, really. The problem is that AC3D is (or was, until recently) the only general format that worked fully with plib, but AC3D files do not contain information on normals. If there's a better semi-standard format that we can use -- one that we can easily get From AC3D and Blender and import into plib with object names, normals, and texture information intact -- I'll be happy to switch to it. A lot (but not all) of the mess we've seen has to do with bad modeling work. I know because I've done the worse of it. With the normals being generated on the fly the right way to construct the model is with surfaces assigned to separate objects if they are sharpy edged, like the ailerons. While there are certain advantages to other methods (with greater control over the normals), this ac3d method really isn't difficult to do at all. If we further developed the ac3d loader for our purposes we might solve most of the problems. Much of the annoying issues with ac3d loading has to do with the optimization step. I feel that if we copied this loader code into SimGear and interact with plib at a lower level on this, we could eliminate some of the things that don't help us, and add to it some features that would help us. It'd be nice to have the ability to substitute textures for example. Plus we might be able to track our own table of loaded textures so that their use can be optimized. We may also be able to implement some of our own extensions and certainly could probably look at implementing some of the ac3d features that aren't currently supported in the plib loader (like selected flat shading for things that really are square edged!). Having a VRML1 loader would be useful. It would be great to move to something so widely supported, but I think we should still develop our own laoder and have it oriented toward loading and supporting simulation models without worrying about fitting in with the plib development goals. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Win32 binaries
Where are these two versions of the win 32 binarys (and the associated files) now located? Be happy to mirror them on my site if that would be helpfull. jj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] T38 gear instrument fix
Could someone with CVS access to the base package please commit this file: http://home.comcast.net/~davidculp2/t38/Instruments/T38-gear.xml which goes in Aircraft/T38/Instruments. It fixes the current gear handle. Thanks, Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] REference
Jon Berndt wrote: Jim wrote: Before we get too worked up about this... It has absolutely nothing to do with modeling the aircraft. It is only a reference point for positioning the 3D model in the scene. All the nose is, sans pitot tubes and other items that are not centered, is a location easy to identify on almost all aircraft. With this in mind, now, we go back to the stated problem. Let's say we (FDM/JSBSim) are reporting the lat/lon of the nose of the aircraft to FlightGear's visual subsystem. We know where our CG is in lat/lon, and we know where the nose is relative to that. So we report in lat/lon/alt coordinates the position of the nose. Now, let's say we drop a payload and the CG shifts. In the FDM, the position in lat/lon/alt is still the same. However, the location of the nose has now shifted with relation to the CG, because the CG has shifted. If we report the new nose position to the FlightGear visual subsystem, there will be an instantansous shift in the visual position of the aircraft. We have always used the "empty weight" CG of the given aircraft in the development of our Weapons Systems Trainers (WST), Part Task Trainers (PTT) for military, as well as Flight Training Devices (FTD) for commercial. It doesn't move, and it is significant with respect to the flight dynamics... The visual systems we use have the ability to offset the eyepoint from the control point so with a little up front math, the graphic artist can use any origin for the 3D model... -- Russ Conway's Law: "The structure of a system tends to mirror the structure of the group producing it." -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] electrical
Has anyone been able to turn off the volume of the marker beacon using configuration files? I can turn it off from the property browser, but these don't work: --prop:/radios/marker-beacon/audio-btn=false or --prop:/radios/marker-beacon/power-btn=false or, in the -set.xml config PropertyList ... radios marker-beacon power-btn archive=yfalse/power-btn audio-btn archive=yfalse/audio-btn /marker-beacon /radios ... /PropertyList I also made a null electrical system, and that didn't work either: ?xml version=1.0? !-- null electrical system -- PropertyList supplier nameBattery/name prop/systems/electrical/suppliers/battery/prop kindbattery/kind volts0/volts amps0/amps /supplier /PropertyList Anyone know what I'm doing wrong? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
All you need to do is specify: interval-sec0.05/interval-sec for the binding in question and you will get a 20 per second repeat rate. Makes sense to me. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] test
-- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery
I know I should be learning how to do 3D modeling myself, but until then I was wondering if someone looking for things to model would try to make the approach lights systems for 28L and 28R in KSFO. I flew into KSFO the other day, after a few year's absence, and saw that the approach light system is very obvious. At most airports the structure that supports the lights is not very noticable, but at KSFO, or any airport with a lighting system that extends into the water, the structure is very apparent. Now, how to get a photo of it? Dave David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] newer stuff
The quote that comes to mind goes something like Sure the Mustang can't do what the Spitfire does, but doesn't do it over Berlin. Spitfires, like the Me's and Fw's lacked range because they were conceived of as tactical, not strategic, aircraft. They did their job very well, being more maneuverable that the Mustang, but all had difficulties operating cross channel, much less at the longer ranges required to escort bombers into Germany, even with drop tanks. Some British pilots, after seeing the Mustangs, asked about changes in the Spitfire to achieve comparable range only to be told that the structural changes needed just weren't feasible. Regards, Charlie Jim Wilson wrote: Lee Elliott [EMAIL PROTECTED] said: I thought one of the major features of the p51 was it's range. I think it was one of the few, if not the only fighter that had the range and endurance for bomber escort duties from the UK into Germany. I believe that the German a/c were generally of lower range and were more likely to be flown from captured airfields nearer the battle front for the attack role. Fighters based in Germany would be there primarily for defence against attacks and so didn't need great range. That's right AFAIK. They added drop tanks to really extend the range. Of course there were the Spitfires, which I think must have flown missions into Germany. Pretty much all the fighters were involved in either bomber escorts or enemy bombing mission intercepts. That's about all fighters are good for. It was just the Japanese that decided they could be used as bombs as well. Best, Jim ___ 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
[Flightgear-devel] glass cockpit
Take a peek at www.first-day.org/jpgs for some examples. These are designed for a full size flight deck sim so some of the detail may not be possible. Also don't forget the five overlays for weather, airports, vortacs, waypoints, and route ETAs on the ND As far as I can tell you are using bitmaps from our software in those screenshot... could you please explain? Is it a cut paste job to illustrate what you intend to do? Enrico Schiratti www.projectmagenta.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Windsock Model
Frederic Bouvier writes: David, do you still have the blender model ? If you can't fix it, could you send it to me ? I haven't looked at these in ages: windsock.blend Description: Binary data windsock.rgb Description: Binary data All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem to compile the flightgear-0.9.2 with Cygwin
Title: Problem to compile the flightgear-0.9.2 with Cygwin Hi I try to compile the source code of flightgear-0.9.2 with Cygwin compiler. I have installed the cygin with version 2.249.2.5 on my windows 2000 computer. I installed the plib-1.6.0, zlib-1.1.4 and metakit-2.4.9.2 packages. However, I still get the following error when I try to run the CONFIGURE OF the Simgear-0.3.3 package. checking mk4.h... yes checking for metakit 2.4.3 or newer... wrong version configure error: Install metakit 2.4.3 or later first. Or, the compiler may not be finding your libmk4.so library. Please check the config.log file for specific details of the failure if you believe you have the correct metakit version. Also, look up this issue in the FlightGear FAQ. Can someone give me the suggestion for fixing this problem? Thanks for help!!! Chengbi Dai ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Lot's of Fun!
I know (and can appreciate) that there is some sensitivity to warfare kinds of themes in FlightGear. However, I wonder if there might be some acceptance of re-enactments of WWI/WWII dogfighting tactics - for historical research and education, etc. A few years back I was hooked on a game called Air Warrior III, which had massively multi-player scenarios, including renactments of actual campaigns. It was wy too much fun! I eventually had to erase the program from my computer to save myself from becoming Tron (now there's a blast from the past). The people who ran the server had to have flying moderators in order to catch people gaining unfair advantage by hacking the program. In FlightGear it would be trivial to give your Messerschmidt 10,000,000 horsepower. You couldn't even call it hacking. Since we already have an OV-10 we could stick a J-85 engine on top of it and make an OV-10Z, which the German airforce uses (or used) for gunnery training. It would pull a large dart behind it on a long cable, which fighters would then attack. The benefit here is that solving the dart-towing programming would then lead directly to sailplane towing. Anyway, here's a Lot's of Fun screen shot for all to enjoy. http://home.comcast.net/~davidculp2/fw190.jpg Dave Culp -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] test
-- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] REference
So, the distance (x,y,z) to the model reference point will have to change as the CG moves, right? If the x-offset is -240 inches at the beginning of the simulation, and I make the CG move an inch aft instantaneously, then I need to (during the same dt) reset the x-offset to -241 inches. That sound right? Dave David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem for compiling and installing the Simgear-0.3.3 package
Title: Problem for compiling and installing the Simgear-0.3.3 package Hi I try to compile the source code of flightgear-0.9.2 with Cygwin compiler. I have installed the cygin with version 2.249.2.5 on my windows 2000 computer. I installed the plib-1.6.0, zlib-1.1.4 and metakit-2.4.9.2 packages. When I try to install the Simgear-0.3.3 package, I get the following error. checking mk4.h... yes checking for metakit 2.4.3 or newer... wrong version configure error: Install metakit 2.4.3 or later first. Or, the compiler may not be finding your libmk4.so library. Please check the config.log file for specific details of the failure if you believe you have the correct metakit version. Also, look up this issue in the FlightGear FAQ. Can someone give me the suggestion for fixing this problem? Thanks for help Chengbi Dai ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New Wiki Page: Flight Gear Janitors
I started a new wiki page tonight located here: http://seedwiki.com/index.cfm?doc=FlightGearJanitorswikiid=2418 Feel free to add to it. I could only think of a few things to put on it but wanted to get it up there so we can collectively turn it into something useful for the newbies and less-involved developers like myself. Thanks -- Cameron Moore [ If con is the opposite of pro, what is the opposite of progress? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
