Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
On Fri, 28 Jan 2005 20:15:41 + (UTC), Martin wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > > ..amen, fact update: > > http://www.groklaw.net/article.php?story=20050121014650517 ..I forgot http://www.gnu.org/philosophy/java-trap.html , another part of Sun's recent history. > Great, we finally now have the chance to come to the point of the > whole issue. The article contains nothing new ..true for those who knows all this, however it also advices it will take some time until the rest of us learns more. > and, most important, it doesn't contain a single hint why I could be > at risk after ordering a set of Solaris10 install media and compiling > FlightGear on that platform. ..just make sure you do get what you want and not any of their "free" CDDL stuff, my understanding is Solaris10 and OpenSolaris is the same, the latter only stripped slightly down and put under the CDDL. ..to me, that sounds like you can be accused of quite a few things without ever trying, here Microsoft Windows is safer, as it's source code is _completely_ useless to GNU/(andnot) Linux or Unix people. ..the wee hints I see, is a Java-trap like omission in Sun's CDDL, which essentially is Mozilla.org's MDL-1.1 _minus_ the "Mozilla clause" (on who wrote what), Sun argues "the CDDL doesn't need it because the GPL doesn't require it", (which is true, that bit is covered by copyright law, not by the GPL, the authors uses the GPL to allow distribution on terms such as source code distribution etc, which is otherwise banned under copyright law), and _plus_ Sun implicitly asking us to trust them "there are no hidden Microsoft or Sun's submarine patents" to "go after" GPL code, or GPL coders, Java-trap style. ..dropping your own Java-trapped code is a _lot_ easier than patent litigation, and it _is_ Microsoft who is in Sun's drivers seat. ..the CDDL license for Open Solaris has a potential problem that is unique to Sun and which comes from its recent agreement with Microsoft. Specifically, Marbux (he's one of Groklaw's retired attorneys) spotted a way that it would be possible for people seeing etc Open Solaris to someday find themselves blocked from distributing code to say FlightGear by a Microsoft patent infringement claim, on say "leaving Sun's CDDL community", because of their cross-licensing deal with Microsoft. ..so we will have to wait and see how this ordeal plays out. > > EOT, > Martin. ..I'm torn between appending new developments here, could make this thread useful as a legal and licensing resource, or simply move this thread in extenso to Groklaw and just post the links on the thread and updates there, here? ..would be far less annoying here and buys us more eyes, and might even buy us some new FG developers and users, but my thread move requires Martin's, Dave's, Andy's and Erik's approval under copyright law and Groklaw's Creative Commons License, as "in extenso" pushes PJ's idea of fair use a bit, and I'll also need to weed out our email addresses. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 January 2005 19:44, Curtis L. Olson wrote: > Oliver C. wrote: > >Are there plans or better a planned release date > >when the missing features will get added into plib? > > You'll have to ask the plib people. Steve is very persnickety about > this section of the code and I suspect he may not allow significant > changes unless he does them himself, especially in the area of shaders. > And he is another extremely busy person so who knows when that will ever > happen. That sounds not so good. :( Are there alternative ways when this is taking to long like a special plib specially designed for the needs of flightgear? (in other word, a fork?) > > Be a bit careful here. I've seen a demo of Manuel's engine and it was > extremely impressive. However, it was only for a very small area. It's > unclear if he's put any thought at all into paging textures or terrain > data in real time without pauses. I also don't know how he handles his > coordinate system and if he suffers map maker distortion problems, or if > he can maintain a seamless wgs-84 oblate ellipsoid earth? > > If he has all these things, then that's wonderful, he has done an > impressive piece of work. I'm not trying to be critical here, I'm just > pointing out that this is *very* difficult stuff. It's one thing to do > a nice little demo, it's something else entirely to tackle all the > issues of doing this in a full sim where you are trying to model the > world seamlessly. > > >I understand. > >Are there ways to follow the changes and engine integration? > > I assume when something is workable, it will be in CVS. > Thank you for answering all my questions. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
> The real problem is that it's hard to get detailed textures for the whole > world (and storage hungry!!). What I'd like to experiment with later on is > to let a classifier run over the globally available 28.5m landsat textures, > and use the resulting classifications to generate missing detail at > runtime. But first things first... There is a trick to create textures with a 15 m resolution based on landsat data: http://www.terrainmap.com/rm29.html BTW: Is it possible to use this classifier to create a new vector map with a larger landcover variety than Vmap0? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
Jon Stockill wrote: One thing it is showing up is quite a few missing scenery tiles in the 0.9.8 scenery. I noticed the missing tiles last week, but found they were introduced a while back, as they are also in scenery-0.9.5, (at least the 3 I managed to download last year) I've almost got all the 0.9.8 scenery for the 48 states, and have been making a list of the errors. Curt, as I'm not on the terragear list, and the errors seem to be in the source data, please make a note of these. Am I correct in observing this is something we can't fix without getting the source data repaired? unfinished squares, hole in Scenery Terrain w082n23 w083n23 w087n41 w081n48 w073n49 w074n49 w075n49 square elevation errors w083n30 large diamond w079n34 large was not in 0.7.8 w094n41 medium square w106n30 large diamond w117n41 small was not in 0.7.8 w072n41 medium diamond shoreline blocks: w081n21 w082n21 w085n21 w080n42 Stewart ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hello, > I do have a few questions though : > Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. > What sort of texture resolutions will it be able to scale down to? > (meters/pixel) The rendering is output sensitive, so only visible detail accounts for scene complexity. However, updates (i.e. paging&decompressing) can be a bottleneck; if you're moving fast, you could get into trouble trying to update all the high-res textures. The easy solution is to limit texture and geometry detail as a function of speed - i.e. don't display 1 m textures at mach 5 (motion blur!). The real problem is that it's hard to get detailed textures for the whole world (and storage hungry!!). What I'd like to experiment with later on is to let a classifier run over the globally available 28.5m landsat textures, and use the resulting classifications to generate missing detail at runtime. But first things first... > How is the mipmapping handled (if it currently uses mipmaps)? Well, in a way, the texture LODs emulate aspects of mipmapping. The ground texture is partitioned in a quadtree scheme, where each quadtree node holds part of the texture at constant resolution (e.g. 128x128 pixels). The root covers the whole texture domain, and children always cover their respective quarter of the parents domain. So, effectively, each parent is a downsampled version of its children. The LODs are choosen in a way which ensures that supersampling orthogonal to the viewer is limited by a factor of 2 (the factor can be higher along the viewing direction, however). Together with anistotropic filtering, this gives very good results. > What will the maximum visual range be? Also depends on the available detail, resolution, permitted screen space error - hard to tell, but I think nothing to worry about. For example, I get good performance (1024x768, Duron 1GhZ, GeForce3, Mach2) without limiting visibility for a whole UTM-zone dataset (with 28.5 m textures, normal maps and SRTM3 elevation), that should be a few hundred kilometers of visual range. As stated earlier, the nearer (fast-moving) detail is more problematic than the distant scenery because of the frequent updates; for the same reason, hard turns are evil :-) hope to have answered your questions, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 Jan 2005 21:21, Paul Surgeon wrote: > Yes, I'm sure there are plenty of users who are happy with the current > scenery engine and one of the advantages it has is that there is no paging > of huge textures while flying. This allows for high speed flights without > any pausing and can also be run on older hardware or where CPU cycles are > best used elsewhere like instrument updates or FDM's. > Last time I tried a Mach 5 flight in FS2004 I ended up with blank/grey > scenery tiles because it couldn't build and page the textures fast enough. > :) For sub-sonic speeds and VFR flight an eye candy terrain engine would be > very much appreciated. > > Paul > One of the drawbacks of *photographic* scenery is manky shadows on flat buildings / bridges etc. The 'suspension of disbelief' tends to be better when the scenery is less 'realistic' but has no shadows etc to spoil the mental picture. I believe that satellite photos can be used well in certain circumstances but on the whole 'blanket coverage' can look far worse - you literally get the feeling that you are flying over a 'polaroid'. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday, 28 January 2005 22:14, Manuel Massing wrote: > I completely agree with you on the integration part. I think the engine > is technically adequate for its intended purposes (i.e. satellite-textured > landscapes). If you have any questions concerning the technical side, feel > free to ask. I would love to see an alternative terrain engine that supports satellite/aerial images. I do have a few questions though : Does the current code that you have handle texture paging? What sort of texture resolutions will it be able to scale down to? (meters/pixel) How is the mipmapping handled (if it currently uses mipmaps)? What will the maximum visual range be? Are you using any sort of texture compression like S3TC/DXTC to save space in VRAM? > In this light, its also important to see it as an alternative, > not a replacement, for the current scenery, because each engine will have > its own set of advantages and disadvantages. Yes, I'm sure there are plenty of users who are happy with the current scenery engine and one of the advantages it has is that there is no paging of huge textures while flying. This allows for high speed flights without any pausing and can also be run on older hardware or where CPU cycles are best used elsewhere like instrument updates or FDM's. Last time I tried a Mach 5 flight in FS2004 I ended up with blank/grey scenery tiles because it couldn't build and page the textures fast enough. :) For sub-sonic speeds and VFR flight an eye candy terrain engine would be very much appreciated. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hello,
> As with everything, really, the key here is integration. Make it work
> with FlightGear so we can test. Saying "here is code, can we use it?"
> just isn't enough. It needs to be "here is a patch, try it and tell
> me what breaks". Until we get that far, there really isn't much to
> argue about.
I completely agree with you on the integration part. I think the engine
is technically adequate for its intended purposes (i.e. satellite-textured
landscapes). If you have any questions concerning the technical side, feel
free to ask. In this light, its also important to see it as an alternative,
not a replacement, for the current scenery, because each engine will have its
own set of advantages and disadvantages.
By using an abstract API, a terrain engine could be choosen at runtime.
But it will definitely take some work to abstract out the terrain engine.
The good thing is, such an abstract API would make the scenery subsystem
more modular and easier to use than in its current, tightly coupled form.
I have attached what I could imagine as a useable terrain API (modulo
conflicts with reality :-)).
regards,
Manuel
/**
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* \short Abstract class to define the API for the terrain rendering subsystem.
*
* written by Manuel Massing, (c) 2004 by Manuel Massing
*/
#ifndef TERRAIN_H
#define TERRAIN_H
#include
#include
using namespace std;
class GeocCoord;
/**
* \short Abstract class which defines an API for the terrain rendering subsystem.
*
* Offers methods for:
* - rendering & detail management
* - Airport management
* - collision & elevation queries
*/
class Terrain {
public:
enum RenderEntity {
trTerrain = 1,// The basic landscape
trRunways = 2,// Runway structures
trRunwayLighting = 4,// Runway lighting
trStaticGroundObjects = 8,// Landmarks, buildings, trees which were placed at scenery generation time
trDynamicGroundObjects = 16// Procedurally generated ground objects, e.g. trees, buildings
};
/**
* Prepare rendering for the given viewing paramaters and the
* configured detail levels.
*/
virtual bool update(FGViewer *viewer) = 0;
// Interface it with scene graph or via a render() method?
// Returning a scene-graph node is probably the better solution,
/**
* Render the terrain using the viewer position and the given rendering flags.
* \note that rendering entities which where disabled during the update() call (i.e. entities with a detail setting of zero) will not be rendered.
*/
virtual void render(RenderEntity renderFlags) = 0;
/**
* Return a scene-graph node which
*/
//SGNode *getSceneNode(RenderEntity flags);
/**
* Set the detail level for the indicated rendering entity.
*
* Valid range is 0 (disable rendering) to the value returned by getDetailLevels(enum Renderflags),
* which corresonds to maximum detail.
*
* \param RenderEntity
* \param detailLevel The desired detail level, in the range 0 to getDetailLevels(entitiy).
*/
virtual void setDetailLevel(RenderEntity entity, const unsigned int detailLevel) = 0;
/**
* A clear text (human-readable) explanation of detail level modalities.
* e.g. getDetailLevelFeatures(trTerrain, 1) could return
* "Render terrain within 32 pixels accuracy.\n"
* "Disable texture mapping.\n"
* "Disable shading.\n"
*
* This is needed to offer an abstracted but descriptive representation for the user interface.
*/
virtual string getDetailLevelFeatures(RenderEntity entity, int detail_level) const = 0;
/**
* Indicates whether airport definitions can be dynamically added at runtime.
* Otherwise, the terrain implementation only supports pre-compiled airports
* (i.e. airports included at terrain-build time).
*/
virtual bool supportsDynamicAirports() const = 0;
/**
* Add specified airport.
*
* Fails if airport already exists or dynamic airports are not supported.
*
* \param ID Zero-terminated string of the airport identifier
* \param airport An instance holding all the relevant information about the structure of the airport to be added.
*
* \returns true on success, otherwise false.
*/
//virtual bool addAirport(char *ID, const Airport &airport) = 0;
virtual bool remove
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
Arnt Karlsen wrote: > ..amen, fact update: > http://www.groklaw.net/article.php?story=20050121014650517 Great, we finally now have the chance to come to the point of the whole issue. The article contains nothing new and, most important, it doesn't contain a single hint why I could be at risk after ordering a set of Solaris10 install media and compiling FlightGear on that platform. EOT, 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] Runway lighting - What happened to the new terrain engine?
Curtis L. Olson wrote: > If he has all these things, then that's wonderful, he has done an > impressive piece of work. I'm not trying to be critical here, I'm > just pointing out that this is *very* difficult stuff. It's one > thing to do a nice little demo, it's something else entirely to > tackle all the issues of doing this in a full sim where you are > trying to model the world seamlessly. Let me just chime in to agree with Curt. Some of the long-timers here will remember that one of the first things I wanted to do when I discovered FlightGear was write a "modern" terrain engine to replace the tile system we're currently using. Since then, I've contributed an FDM and an extension language. No terrain. I spent the spring of 2003 working on my own project full time and produce a ton of working code. Until I got to the terrain engine, which I got partially working, then burned out. No terrain. It's hard, really. It's not impossibly hard, but the distance between something that works well as a demo and something that ships well as a product is very long. As with everything, really, the key here is integration. Make it work with FlightGear so we can test. Saying "here is code, can we use it?" just isn't enough. It needs to be "here is a patch, try it and tell me what breaks". Until we get that far, there really isn't much to argue about. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
On Fri, 28 Jan 2005 15:53:58 + (UTC), Martin wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > > ..true, the problem remains how Sun's new licensing and patenting > > regime plays out, not how their good old benevolent ways did. > > Please have a look at the facts before spreading FUD, ..amen, fact update: http://www.groklaw.net/article.php?story=20050121014650517 -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
That might be the best solution...I'll look into that. On Fri, 28 Jan 2005 18:09:54 +, Dave Martin <[EMAIL PROTECTED]> wrote: > On Friday 28 Jan 2005 17:25, Drew wrote: > > Well, FYI, it can be done with Windoes. > > > > The difference is I want the instructor station on the PRIMARY > > display, but right now I get the unsightly window border on the > > secondary display. > > > > > Does Windows allow you to switch the 'border' attribute on a window? > > I use this on Linux to switch FlightGear from Windowed to fullscreen without > needing any 'locking' control over the WM. > > If you can do that on Windows, just start FG with the correct geometry and > then set the window as 'borderless' or something along those lines. > > Dave Martin > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Alcatraz
"Jim Wilson" wrote: > Great landmark, and excellent model. Thanks Frederic for all the great > scenery models. They really impress the ladies [...] Indeed :-) In order to magnify this effect it would really be nice to get at least a minimal heliport back into the scene. Currently when you start at CA27 you find yourself sitting somewhere below ground level - this doesn't look _that_ sweet :-) 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] Runway lighting - What happened to the new terrain engine?
Oliver C. wrote: Are there plans or better a planned release date when the missing features will get added into plib? You'll have to ask the plib people. Steve is very persnickety about this section of the code and I suspect he may not allow significant changes unless he does them himself, especially in the area of shaders. And he is another extremely busy person so who knows when that will ever happen. But this is because of the landsat textures. I was more interested in the engine itself. At the moment we use generic textures to cover the whole world. This approach is okay, because it allows us to keep the scenery data small. But the thing that is missing at the current engine is multi texturing. With multi texturing we could still use generic textures but the scenery would look more diversified because multitexturing allows us to add random distorting textures to the base textures, the result is more variety. MS does use the same approach at their FS2004, but we can't use this at the moment because plib and the existing FG engine does not (AFAIK) support multitexturing. The other nice things which the alternate Engine allows and are good to have are the imposter in the background, VBO rendering etc. So i was more thinking about using this new engine to render generic multitextured sceneries instead of large landsat images. But of course it would also be good to be able to use landsat images for selected areas like large cities. Be a bit careful here. I've seen a demo of Manuel's engine and it was extremely impressive. However, it was only for a very small area. It's unclear if he's put any thought at all into paging textures or terrain data in real time without pauses. I also don't know how he handles his coordinate system and if he suffers map maker distortion problems, or if he can maintain a seamless wgs-84 oblate ellipsoid earth? If he has all these things, then that's wonderful, he has done an impressive piece of work. I'm not trying to be critical here, I'm just pointing out that this is *very* difficult stuff. It's one thing to do a nice little demo, it's something else entirely to tackle all the issues of doing this in a full sim where you are trying to model the world seamlessly. I understand. Are there ways to follow the changes and engine integration? I assume when something is workable, it will be in CVS. 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] Alcatraz
Frederic Bouvier said: > Quoting Dave Martin: > > > On Friday 28 Jan 2005 16:01, Curtis L. Olson wrote: > > > With help from Thomas Markowitz, I have posted a side by side comparison > > > of the FlightGear Alcatraz model versus a real photo here: > > > > > > http://www.flightgear.org/Gallery/ > > > > > > Good work Frederic! > > > > > > Regards, > > > > > > Curt. > > > > It really cuts the mustard. > > > > Was the terrain at Alcatraz designed 'by hand' or is it the regular terrain > > data? > > This is the smallest photo scenery we have ;-) > It is a blender model that was made after a topo map and an aerial photo from > terraserver-usa. The buildings are after google image search. I removed the > flat land area that was in the scenery with fgsd. > > The real photo can be seen here : http://www.nps.gov/alcatraz/ > Great landmark, and excellent model. Thanks Frederic for all the great scenery models. They really impress the ladies (well, my wife anyway) and anyone else who I manage to cajole into sitting down and checking out the latest FlightGear. :-) Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
On 28/01/2005 at 17:55 Jon Stockill wrote: >It builds ok on Slackware Linux 10.0, --headless seems to work ok with >Map - I'm running it remotely at the moment. I'll test the Atlas app >when I get home and it finishes building the maps. > >One thing it is showing up is quite a few missing scenery tiles in the >0.9.8 scenery. > Yes, there's one just north of Cambridge. I checked, and it is a definite missing scenery tile, not a Map/Atlas error. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
On 28/01/2005 at 09:15 Adam Dershowitz wrote: >I have never tried to build Atlas before, but just tried with this >release. >I am working on a Mac and ./configure gives me the following errors: > >checking for pthread_exit in -lpthread... yes >checking for glNewList in -lGLcore... no >checking for glNewList in -lGL... yes >checking for gluLookAt in -lGLU... yes >checking for glutGetModifiers in -lglut... no >checking for glutGameModeString in -lglut... no > >Unable to find the necessary OpenGL or GLUT libraries. >See config.log for automated test details and results ... > >In order to build flightgear, a little while ago, it was necessary to make >a >few changes to the source code to get it to properly find GLUT stuff. But >these changes are now all incorporated into FG. These locations are now >all >captured in simgear/compiler.h. >In the time that I have been working with the code, no changes were >required >to the config stuff, only some of the paths in the source itself, now in >compiler.h. >The truth is that I have not done much with automake, so I am not really >sure how to go about fixing this. But clearly something is different in >how >Atlas checks for GLUT versus how Simgear and FG do it, since they succeed >just fine in finding and using that stuff. >If you can point me in the right direction I can try to work with it some >more. > Hi Adam, I'm afraid I don't use a Mac, and I'm not good with shell or configure scripts. If you want to have a try at fixing this, then configure.ac is the file you need to edit (try looking in FlightGear's configure.ac for inspiration), and you'll need to run ./autogen.sh before ./configure after making any changes to configure.ac. Unfortunately, the whole glut/gl section of the Atlas/FlightGear configure.ac files appears to be somewhat different - I don't think it's a matter of just dropping a mac test in from the FG one to the Atlas one. It really needs someone who know's what they're doing in this area to take a look at it. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 January 2005 18:20, Curtis L. Olson wrote: > Oliver C. wrote: > >On Friday 28 January 2005 05:14, Curtis L. Olson wrote: > >>I'm told there is a way to do this with shaders, but plib/ssg doesn't > >>support shaders. :-( > >> > >>Curt. > > > >What happended about Manual Massing's new alternative terrain engine? > >http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html > > > >Does it support shaders and does it get now integrated into Flightgear? > >As far as i understood, it is using its own scene graph so > >we would be independent from the plib library and this allows us to use > >VBO, shaders and multitexturing without the need to wait for an update of > > the plib library. > > It's not that easy. The plib scene graph lib is woven throughout our > code. 3d models of aircraft, 3d cockpits, all the animation code is > hardwired into plib structures. Are there plans or better a planned release date when the missing features will get added into plib? > > We will look into Manual's new terrain engine, Nice to hear. :) > but there again, he may > have a few small areas available to fly in, but it's not just a drop in > replacement that gives us the whole world. From what I've seen it does > a nice job of drawing quality terrain. But it's unclear how well that > will scale to the entire world. Certainly the data sizes to represent > the whole world for this engine will be extreme. Probably 100x what our > current approach uses. But this is because of the landsat textures. I was more interested in the engine itself. At the moment we use generic textures to cover the whole world. This approach is okay, because it allows us to keep the scenery data small. But the thing that is missing at the current engine is multi texturing. With multi texturing we could still use generic textures but the scenery would look more diversified because multitexturing allows us to add random distorting textures to the base textures, the result is more variety. MS does use the same approach at their FS2004, but we can't use this at the moment because plib and the existing FG engine does not (AFAIK) support multitexturing. The other nice things which the alternate Engine allows and are good to have are the imposter in the background, VBO rendering etc. So i was more thinking about using this new engine to render generic multitextured sceneries instead of large landsat images. But of course it would also be good to be able to use landsat images for selected areas like large cities. > > This is some *very* difficult stuff and we need to move slowly and > cautiously to avoid breaking everything. I understand. Are there ways to follow the changes and engine integration? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Aircraft model releases
The 1/26 updates should be fine, but there are quite a few changes going in (and one already in CVS) for the p51d that will make it incompatible with the last flightgear release. Not sure how this should be handled. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
On Friday 28 Jan 2005 17:25, Drew wrote: > Well, FYI, it can be done with Windoes. > > The difference is I want the instructor station on the PRIMARY > display, but right now I get the unsightly window border on the > secondary display. > > Does Windows allow you to switch the 'border' attribute on a window? I use this on Linux to switch FlightGear from Windowed to fullscreen without needing any 'locking' control over the WM. If you can do that on Windows, just start FG with the correct geometry and then set the window as 'borderless' or something along those lines. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Note the diff file has been renamed from the earlier submission. This version works better with more complex models. This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make "lights" appear to dimm. This is an example of a configuration entry which should explain how it is used: material-emission Face /controls/lighting/instruments-norm 1.0 0.8 0.5 Note the color entries are the emissive colors when the "property" value is 1.0. They are useful for tinting the light. The "property" itself must be float or double and is clamped to values between 0 ~ 1.0 inclusively. The "property" value is multiplied against the colors to get the actual material properties. Thus property value 0.0 = darkest, and 1.0 = brightest. Best, Jim Patch file: http://www.spiderbark.com/fgfs/emissanim2.diff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
David Luff wrote: Hi all, I've put a release candidate of Atlas-0.3 up at: http://www.nottingham.ac.uk/~eazdluf/Atlas-0.3.0-rc1.tar.gz If a few folk could take the time to download this and try it out that would be great. It builds ok on Slackware Linux 10.0, --headless seems to work ok with Map - I'm running it remotely at the moment. I'll test the Atlas app when I get home and it finishes building the maps. One thing it is showing up is quite a few missing scenery tiles in the 0.9.8 scenery. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear Scenery Object Database
In an effort to provide a central repository for placing models within the flightgear scenery Martin Spott and I have been working on a database system to handle the collection and storage of this data. The first stage of this project is now complete, and an initial data set containing navaids for the entire planet, and a handful of other models is now available. DOWNLOADING THE DATA The database can be found at http://fgfsdb.stockill.org/ with downloadable scenery add-ons and extra shared models available from http://fgfsdb.stockill.org/downloads/ CONTRIBUTING MORE OBJECTS If you wish to help populate the world with interesting objects (yes, we really are aiming for total world domination here :-) then we'll need the following details: * Full name of author (required if not already known) * EMail of author (required if not already known, will not be published, just as a reference) * additional short comment on the author (optional) * any sort of explicit notice that the submission is covered by the GPL, we won't accept a single submission which lacks this notice (required) * the 3D model itself in a format supported by FlightGear or a reference to a model already present in the database (required) * Position (if appropriate. Either lat/on, or Ordnance Survey grid - other grids can be added on request) * heading (if appropriate), * country (if known to the author), * elevation (if known to the author), * a 320x240 thumbnail containing an advantageous view on the model/object (not required but preferred). Facilities to handle the uploading of your own model data are not yet complete, but the data can currently be submitted in 2 ways: 1) By Email Send a message containing the info above, to (sorry for the anti spam measures, I'm sure you understand): fgfsdb at stockill dot org or Martin dot Spott at mgras dot net 2) By anonymous FTP Put all the info described above into an archive (.zip or .tar.gz format) and upload it to: ftp://ftp.ihg.uni-duisburg.de/FlightGear/incoming/ Comments on improvements/additions/errors can be sent to: fgfsdb at stockill dot org -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
Like I said, I don't know what SDL is, so I'm using GLUT, and I do have Fredric's project files. On Fri, 28 Jan 2005 18:21:57 +0100, Frederic Bouvier <[EMAIL PROTECTED]> wrote: > Quoting "Curtis L. Olson" : > > > Drew wrote: > > > > >I'm not sure what SDL means, but it will run on the primary display > > >without the secondary one going black, so I don't think what you said > > >is true...at least in my case. > > > > > >I'm using the latest stable version of flightgear, which I compiled > > >myself from the source using VisualC++. So I can make changes to the > > >code if necessary. > > > > > > > > > > Drew, > > > > My experience is that SDL works fine on a multiheaded system (two video > > cards) if you are running in default window-dressing mode. > > > > If you try to go full screen, (at least on Linux) then the other windows > > are locked out. It may behave better on windows, or maybe newer > > versions of SDL behave better (???) Just reporting my experience on > > linux, fullscreen, w/ 2 video cards (not a single multiheaded video > > card) ... > > > > For me, this caused a big problem because I wanted to run an instructor > > station on the 2nd head (but it was totally locked out with full screen > > SDL.) > > If Drew uses my project files, then GLUT is linked and used, not SDL. > > -Fred > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
Well, FYI, it can be done with Windoes. The difference is I want the instructor station on the PRIMARY display, but right now I get the unsightly window border on the secondary display. On Fri, 28 Jan 2005 11:11:37 -0600, Curtis L. Olson <[EMAIL PROTECTED]> wrote: > Drew wrote: > > >I'm not sure what SDL means, but it will run on the primary display > >without the secondary one going black, so I don't think what you said > >is true...at least in my case. > > > >I'm using the latest stable version of flightgear, which I compiled > >myself from the source using VisualC++. So I can make changes to the > >code if necessary. > > > > > > Drew, > > My experience is that SDL works fine on a multiheaded system (two video > cards) if you are running in default window-dressing mode. > > If you try to go full screen, (at least on Linux) then the other windows > are locked out. It may behave better on windows, or maybe newer > versions of SDL behave better (???) Just reporting my experience on > linux, fullscreen, w/ 2 video cards (not a single multiheaded video > card) ... > > For me, this caused a big problem because I wanted to run an instructor > station on the 2nd head (but it was totally locked out with full screen > SDL.) > > Regards, > > 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 > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Oliver C. wrote: On Friday 28 January 2005 05:14, Curtis L. Olson wrote: I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( Curt. What happended about Manual Massing's new alternative terrain engine? http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html Does it support shaders and does it get now integrated into Flightgear? As far as i understood, it is using its own scene graph so we would be independent from the plib library and this allows us to use VBO, shaders and multitexturing without the need to wait for an update of the plib library. It's not that easy. The plib scene graph lib is woven throughout our code. 3d models of aircraft, 3d cockpits, all the animation code is hardwired into plib structures. We will look into Manual's new terrain engine, but there again, he may have a few small areas available to fly in, but it's not just a drop in replacement that gives us the whole world. From what I've seen it does a nice job of drawing quality terrain. But it's unclear how well that will scale to the entire world. Certainly the data sizes to represent the whole world for this engine will be extreme. Probably 100x what our current approach uses. This is some *very* difficult stuff and we need to move slowly and cautiously to avoid breaking everything. 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] Secondary display - game mode
Quoting "Curtis L. Olson" : > Drew wrote: > > >I'm not sure what SDL means, but it will run on the primary display > >without the secondary one going black, so I don't think what you said > >is true...at least in my case. > > > >I'm using the latest stable version of flightgear, which I compiled > >myself from the source using VisualC++. So I can make changes to the > >code if necessary. > > > > > > Drew, > > My experience is that SDL works fine on a multiheaded system (two video > cards) if you are running in default window-dressing mode. > > If you try to go full screen, (at least on Linux) then the other windows > are locked out. It may behave better on windows, or maybe newer > versions of SDL behave better (???) Just reporting my experience on > linux, fullscreen, w/ 2 video cards (not a single multiheaded video > card) ... > > For me, this caused a big problem because I wanted to run an instructor > station on the 2nd head (but it was totally locked out with full screen > SDL.) If Drew uses my project files, then GLUT is linked and used, not SDL. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
I have never tried to build Atlas before, but just tried with this release. I am working on a Mac and ./configure gives me the following errors: checking for pthread_exit in -lpthread... yes checking for glNewList in -lGLcore... no checking for glNewList in -lGL... yes checking for gluLookAt in -lGLU... yes checking for glutGetModifiers in -lglut... no checking for glutGameModeString in -lglut... no Unable to find the necessary OpenGL or GLUT libraries. See config.log for automated test details and results ... In order to build flightgear, a little while ago, it was necessary to make a few changes to the source code to get it to properly find GLUT stuff. But these changes are now all incorporated into FG. These locations are now all captured in simgear/compiler.h. In the time that I have been working with the code, no changes were required to the config stuff, only some of the paths in the source itself, now in compiler.h. The truth is that I have not done much with automake, so I am not really sure how to go about fixing this. But clearly something is different in how Atlas checks for GLUT versus how Simgear and FG do it, since they succeed just fine in finding and using that stuff. If you can point me in the right direction I can try to work with it some more. Atlas looks very useful. Thanks, -- Adam > From: David Luff <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions > Date: Fri, 28 Jan 2005 13:16:28 + > To: <[EMAIL PROTECTED]> > Cc: > Subject: [Flightgear-devel] Atlas release candidate > > Hi all, > > I've put a release candidate of Atlas-0.3 up at: > > http://www.nottingham.ac.uk/~eazdluf/Atlas-0.3.0-rc1.tar.gz > > If a few folk could take the time to download this and try it out that > would be great. > > Changes in the last year or so: > > * Now reads FG-0.9.8 airport and navaid formats > > * Atlas now displays ILS localisers > > * Map has an off-screen rendering option (--headless) to avoid image > corruption due to overlaid windows and possibly allow maps greater than > screen resolution depending on graphics hardware and drivers [X-Windows > with fairly modern GLX only at present] > > * Map supports multiple scenery paths via FG_SCENERY or --fg-scenery= (only > Map at present, not MapPS). > > * Atlas has --airport=ICAO startup option. > > * Bug fixes. > > Note that Atlas/Map is written by Per Liedman and others, not myself, but > Per is unable to maintain it at the moment. > > Cheers - Dave > > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses, which could damage your computer system: > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
Drew wrote: I'm not sure what SDL means, but it will run on the primary display without the secondary one going black, so I don't think what you said is true...at least in my case. I'm using the latest stable version of flightgear, which I compiled myself from the source using VisualC++. So I can make changes to the code if necessary. Drew, My experience is that SDL works fine on a multiheaded system (two video cards) if you are running in default window-dressing mode. If you try to go full screen, (at least on Linux) then the other windows are locked out. It may behave better on windows, or maybe newer versions of SDL behave better (???) Just reporting my experience on linux, fullscreen, w/ 2 video cards (not a single multiheaded video card) ... For me, this caused a big problem because I wanted to run an instructor station on the 2nd head (but it was totally locked out with full screen SDL.) Regards, 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] Atlas release candidate
On 28/01/2005 at 15:34 Roberto Inzerillo wrote: > >Do you think there will be some Win32 binary too? It would be very nice :-) > >I don't know if it's even possible (I didn't look into the code in order to >determine if libraries and the source itself is portable) but I really hope >so. > > A windows binary of the code a few weeks ago is here: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/atlas-win32-20050112.zip courtesy of Fred Bouvier. Hopefully he will produce a release binary as well. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 January 2005 05:14, Curtis L. Olson wrote: > > I'm told there is a way to do this with shaders, but plib/ssg doesn't > support shaders. :-( > > Curt. What happended about Manual Massing's new alternative terrain engine? http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html Does it support shaders and does it get now integrated into Flightgear? As far as i understood, it is using its own scene graph so we would be independent from the plib library and this allows us to use VBO, shaders and multitexturing without the need to wait for an update of the plib library. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
I'm not sure what SDL means, but it will run on the primary display without the secondary one going black, so I don't think what you said is true...at least in my case. I'm using the latest stable version of flightgear, which I compiled myself from the source using VisualC++. So I can make changes to the code if necessary. Drew On Thu, 27 Jan 2005 19:20:39 -0600, Curtis L. Olson <[EMAIL PROTECTED]> wrote: > Drew wrote: > > >I appreciate that, and if I were using Linux, I'd have already known > >exactly what to do. :) > > > >I should have been more clear...unfortunatly, for this particular > >application I need to use Windows XP Pro, and I currently have an ATA > >Mobility Radeon 9000 in the laptop I'm using. > > > >I'm trying to get the image to display on a television screen as the > >secondary display...like I said, I have it working fine in window > >mode, but not in game mode. > > > >Thanks again, > >Drew > > > > > >On Fri, 28 Jan 2005 00:39:49 +0100, Ivo <[EMAIL PROTECTED]> wrote: > > > > > >>On Thursday 27 January 2005 23:08, Drew wrote: > >> > >> > >>>Does anyone know the easiest way to run flight gear in game mode on a > >>>secondary display. > >>> > >>>It runs just fine if I drag the window over and maximize it on the > >>>secondary display, but I can't figure out how to make it work in game > >>>mode. > >>> > >>> > >>As I don't have Xinerama running here, it is just a guess, but I suppose > >>this should work: > >> > >>export DISPLAY=localhost:0.1 > >>fgfs > >> > >>If the window appears on the secondary display, then enabling game-mode > >>should run it fullscreen. > >> > >> > > If you are running a binary compiled with SDL, then I don't think SDL > supports that ... at least not on linux. That's one reason we need to > keep glut support around, you can't go full screen in SDL on a multi > headed system without blanking and locking out the other heads. > > Regards, > > 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 > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Alcatraz
Quoting Dave Martin: > On Friday 28 Jan 2005 16:01, Curtis L. Olson wrote: > > With help from Thomas Markowitz, I have posted a side by side comparison > > of the FlightGear Alcatraz model versus a real photo here: > > > > http://www.flightgear.org/Gallery/ > > > > Good work Frederic! > > > > Regards, > > > > Curt. > > It really cuts the mustard. > > Was the terrain at Alcatraz designed 'by hand' or is it the regular terrain > data? This is the smallest photo scenery we have ;-) It is a blender model that was made after a topo map and an aerial photo from terraserver-usa. The buildings are after google image search. I removed the flat land area that was in the scenery with fgsd. The real photo can be seen here : http://www.nps.gov/alcatraz/ -Fred BTW Curt, it is Alcatraz, not AlcRatraz (R emphazized) in the legend of the images in the Gallery. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Alcatraz
On Friday 28 Jan 2005 16:01, Curtis L. Olson wrote: > With help from Thomas Markowitz, I have posted a side by side comparison > of the FlightGear Alcatraz model versus a real photo here: > > http://www.flightgear.org/Gallery/ > > Good work Frederic! > > Regards, > > Curt. It really cuts the mustard. Was the terrain at Alcatraz designed 'by hand' or is it the regular terrain data? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Alcatraz
With help from Thomas Markowitz, I have posted a side by side comparison of the FlightGear Alcatraz model versus a real photo here: http://www.flightgear.org/Gallery/ Good work Frederic! Regards, 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] ..Groklawyers warns GPL developers against
Arnt Karlsen wrote: > ..true, the problem remains how Sun's new licensing and patenting > regime plays out, not how their good old benevolent ways did. Please have a look at the facts before spreading FUD, 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] ..Groklawyers warns GPL developers against
On Fri, 28 Jan 2005 07:12:33 + (UTC), Martin wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > On Thu, 27 Jan 2005 21:49:36 + (UTC), Martin wrote in message > > <[EMAIL PROTECTED]>: > > > > Arnt Karlsen wrote: > > > > > > > ..precisely, _just_ like Vidkun Lauritz Abraham Jonssn > > > > Quisling helped save _several _million_ Ukrainians from > > > > starvation deaths in the early 1920ies, Norway only lost about > > > > 20,000 in WWII and still shot him, > > > > > > I don't doubt, but these incidents will never prevent me from > > > employing Solaris wherever I feel it makes sense, > > > ..true, however, _does_ it make any sense from now on? > > Absolutely, when you look at the facts then you'll realize that > Solaris didn't change since yesterday, ..true, the problem remains how Sun's new licensing and patenting regime plays out, not how their good old benevolent ways did. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for dimmable panel lighting animation
Jim Wilson wrote: Jim Wilson said: This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make "lights" appear to dimm. This is an example of a configuration entry which should explain how it is used: Please hold off on applying this patch. I'm working on a better one. Ok. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for dimmable panel lighting animation
Jim Wilson said: > This patch adds support to the model animation system for modifying emissive > states on the fly so that it is possible to make "lights" appear to dimm. > This is an example of a configuration entry which should explain how it is > used: > Please hold off on applying this patch. I'm working on a better one. Thanks, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
> Hi all, > I've put a release candidate of Atlas-0.3 up at: > http://www.nottingham.ac.uk/~eazdluf/Atlas-0.3.0-rc1.tar.gz Do you think there will be some Win32 binary too? It would be very nice :-) I don't know if it's even possible (I didn't look into the code in order to determine if libraries and the source itself is portable) but I really hope so. Roberto -- GMX im TV ... Die Gedanken sind frei ... Schon gesehen? Jetzt Spot online ansehen: http://www.gmx.net/de/go/tv-spot ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Atlas release candidate
Hi all, I've put a release candidate of Atlas-0.3 up at: http://www.nottingham.ac.uk/~eazdluf/Atlas-0.3.0-rc1.tar.gz If a few folk could take the time to download this and try it out that would be great. Changes in the last year or so: * Now reads FG-0.9.8 airport and navaid formats * Atlas now displays ILS localisers * Map has an off-screen rendering option (--headless) to avoid image corruption due to overlaid windows and possibly allow maps greater than screen resolution depending on graphics hardware and drivers [X-Windows with fairly modern GLX only at present] * Map supports multiple scenery paths via FG_SCENERY or --fg-scenery= (only Map at present, not MapPS). * Atlas has --airport=ICAO startup option. * Bug fixes. Note that Atlas/Map is written by Per Liedman and others, not myself, but Per is unable to maintain it at the moment. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
- Original Message - From: "Erik Hofman" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Friday, January 28, 2005 1:34 AM Subject: Re: [Flightgear-devel] Runway lighting > Roman Grigoriev wrote: > > > Hi guys! > > I have too framerate drops when lights are switch on. on my FX5950 ultra and > > PIV3500 > > We don't need to have plib support of shaders. > > I use shaders for runway lights. I don't use triangles I use > > points(pointsprites). and in shader I use normals to calculate visibility of > > light (dot with view direction) > > So on 1 light now you have spend 3 points and on my approach I spend 1 > > point. > > so w/o shaders framerate drops from 70 to 30 with shaders from 70 to 65. > > so guys take advantage from you real good videocards. > > I have framework of shaders that can be easyly integrate in fgfs. > > In that approach you can use GLSL, ARB and NV shaders. > > Shaders are in txt file. > > Long time ago I propose to use shaders. maybe runway light is the first > > thing to try? > > If you need this you can simply to ask me ;-) > > Roman, could you post an URL to the changes you have made to > FlightGear/SimGear? I would like to take a look at it. Unfortunately the > last time I looked at your patches the code style didn't match that of > FlightGear very well and therefore the code was hard to read. > > But if we can integrate something like this in SimGear (preferably) then > it might be worth a shot. Ok I test my changes with flightgear cvs and send you. It took day or two. Bye Roman > > Erik > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Terragear-devel] Reducing airports polygon count
Erik Hofman wrote: > http://fgsd.sourceforge.net/images/LFPX-photo-scenery.png > > For more complex airports more polygons are being created to map the > threshold, runway numbers (two quads at every side), runway markings, etc. I think some confusion arises from the fact, that Dale probably talks about real _polygons_ in the meaning of the word. When people talk about polygons in FlightGear scenery they always mean _triangles_. As I understood Dales words his IG theoretically could handle a single polygon describing the whole runway - under the assumption that the terrain is totally flat, 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] Runway lighting
Roman Grigoriev wrote: Hi guys! I have too framerate drops when lights are switch on. on my FX5950 ultra and PIV3500 We don't need to have plib support of shaders. I use shaders for runway lights. I don't use triangles I use points(pointsprites). and in shader I use normals to calculate visibility of light (dot with view direction) So on 1 light now you have spend 3 points and on my approach I spend 1 point. so w/o shaders framerate drops from 70 to 30 with shaders from 70 to 65. so guys take advantage from you real good videocards. I have framework of shaders that can be easyly integrate in fgfs. In that approach you can use GLSL, ARB and NV shaders. Shaders are in txt file. Long time ago I propose to use shaders. maybe runway light is the first thing to try? If you need this you can simply to ask me ;-) Roman, could you post an URL to the changes you have made to FlightGear/SimGear? I would like to take a look at it. Unfortunately the last time I looked at your patches the code style didn't match that of FlightGear very well and therefore the code was hard to read. But if we can integrate something like this in SimGear (preferably) then it might be worth a shot. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Runway lighting
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman > Sent: Friday, January 28, 2005 3:58 AM > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Runway lighting > > > Ampere K. Hardraade wrote: > > How about not rendering ground textures at night? Has this been done yet? > > I don't think turning off texturing makes any difference on common > hardware (including my O2, it will give me 1fps more). The code to draw > untextured terrain has been removed some time ago. > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Runway lighting
Erik Hofman wrote: > > The code to draw > untextured terrain has been removed some time ago. Saddly :-( Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
Dave Martin wrote: Its a shame that (the) Sun is slowly burning away. I just hope that not too many more *nix based business are going to go the same way. (I'm still trying to buy a good SGI 02 but I'm having no luck) You could check this site every once in a while: http://forums.nekochan.net/viewforum.php?f=4&sid=c0a659a1a9aebc7cca7469ef7759547c Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
Ampere K. Hardraade wrote: How about not rendering ground textures at night? Has this been done yet? I don't think turning off texturing makes any difference on common hardware (including my O2, it will give me 1fps more). The code to draw untextured terrain has been removed some time ago. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
