Re: [Flightgear-devel] Energy worm in hud
* Lee Elliott -- Saturday 29 July 2006 01:03: > I saw that the test for ilcanclaw was re-introduced in > hud_ladr.cxx and it seems to stop the energy worm from working No. It hasn't ever been changed there (Cockpit/hud_ladr.cxx). I only commented it out in the new HUD code in src/Instrumentation/HUD/HUD_ladder.cxx where it's still commented out. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Energy worm in hud
Probably one for Melchior... I saw that the test for ilcanclaw was re-introduced in hud_ladr.cxx and it seems to stop the energy worm from working. It works again if I remove the test. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
On Friday 28 July 2006 06:21, Robin van Steenbergen wrote: > I know that, since all the airports in the Netherlands are made that > way. But there's one pretty important thing that's not generated on the > ground chart: The buildings are all missing! > Most ground charts do have the buildings on them but they're not labeled > and they're pretty hard to auto-generate since they require modeling. Or > you have to represent them as boxes like FS2004 does, but that's not > exactly pretty. I'm using the ground chart to determine the correct > sizes of my buildings (using the runway as a reference) and their > placement. Buildings too... http://flamebunny.homelinux.net/svg2ac.php Ampere - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
On 7/27/06, Jon Stockill <[EMAIL PROTECTED]> wrote: > So forget converting anything from their 3d warehouse - if you want to > use a model you'll need to get it direct from the author. There is one thing FG could learn from Google Earth's 3D Warehouse:The GE Warehouse is linked to directly and prominently from the Google Earth main page, while the link to FGFSDB is hidden somewhere in the FG related websites list without any explanation of what it is about. Users can easily miss it and if they miss it they cannot contribute. So perhaps the FG main page should address user contributions, e.g. in the Google Earth "common questions" format, like "How can I put my house/school/home town into the FG terrain?" Simply make it obvious how to create models for FG so that casual users who may not have visited all related websites are not left out. Martin - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
* Frederic Bouvier -- Thursday 27 July 2006 08:30: > I agree with Mathias : doing raw ogl call outside the scenegraph requires lots > of costly state save and restore And as I said: the HUD doesn't do many state changes. > if you don't want to see your screen screwed. > OSG is extensible and already support far more OpenGL than SSG. Yes, but that's the whole point: we use SSG. And dumbing the HUD down to SSG niveau only to make it smart again with OSG is silly. I think about simple things like glLineWidth. To make that work with SSG one would probably have to write ssg nodes *and* then to implement the missing capabilities with callbacks, using raw code again. So we end up where we started, just with a lot of superfluous extra work. I'd prefer pragmatism to politics here. But then again: "show me the code". Maybe it's easy enough ... :-) m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
Selon Mathias Fröhlich : > > Hi, > > On Wednesday 26 July 2006 19:20, Melchior FRANZ wrote: > > We had talked about abstracting out the raw gl-commands into just > > one file, and then to use plib wrappers to plug the HUD into the > > scene graph. The plib wrappers could eventually get replaced by osg > > wrappers. > > > > The abstraction is still a goal, and so is plugging the HUD into > > the scene graph. But I think now that using plib/osg wrappers is > > a bad idea. This would prevent us from using some gl features for > > absolutely no good reason (e.g. line width, clipping, ...). And > > finally, ogl *is* a standard, while neither plib nor osg are. So > > why leaving the standard? Raw gl-code can still be plugged into > > the scene graph via callbacks, and the only thing that the wrappers > > would buy us is management of state changes for performance reasons. > > But the HUD code doesn't change that much, and this can be done > > manually, too. > > > > Why exactly would we want to limit ourselves? :-} > Because it is not a limitation but rather a gain. A *well* *done* and *well* > *supported* scenegraph will help you some much more than you probably can > imagine now. > In fact, a proper design - like a well done scenegraph provides - will enable > such features in a much less error prone and more efficient way. > Also a *supported* scenegraph that is developed further will make use of > improovements in OpenGL that an unsupported one like plib's ssg will never > see. ssg forces you to do many things yourselves in a probably less efficient > way with direct OpenGL calls, that can be done with a smarter implementation > without such direct OpenGL commands. > There is nothing in OpenGL you cannot do with osg. But there is nowerdays > nearly everything from current OpenGL features - even some basic ones like > clip planes - that is missing in ssg, so that you need to implement that > yourselves ... > Having that will be much more of a gain that a limitation ... > > So why should we limit ourselves in the long term with ssg? I agree with Mathias : doing raw ogl call outside the scenegraph requires lots of costly state save and restore if you don't want to see your screen screwed. OSG is extensible and already support far more OpenGL than SSG. I once proposed a compatible ssg extension : http://frbouvi.free.fr/plib/nsssg.html I was able to use it with flightgear without code change except to support the new features ( like multi texturing and environment mapping ). The code still exist but stalled after it was ignored by the plib team and further developments ( like shaders ) were lost in a disk crash. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
* Jeff McBride -- Friday 28 July 2006 15:46: > Actually, sometimes if you get it right (well, I did it once), you can > go a lot faster than that. Yes, you are right. I suggested 8000 ft only as sufficiently high to not rush into the ground immediately, at that high speed. But trying at 1000 ft one can easily accelerate to 3000 kt and more. Very dangerous! Don't try at home, kids! m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
> $ fgfs --aircraft=YF-23 --airport=knuq --disable-real-weather-fetch > > - full throttle > - climb to 8000 ft > - 90 degree bank > - pull stick fully back > amazingly: you don't bleed off speed, but *accelerate* > - at ~1630 kt (after that the speed decreases) 0 degree bank and > 90 degree pitch up > - climb to 163000 ft in no time > > m. :-) just tried this on a seneca in reality. Didn't work. Reality could be so disappointing... Torsten - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
Actually, sometimes if you get it right (well, I did it once), you can go a lot faster than that. I managed to get the speed to diverge rapidly up to 5 or 6 digits once and then FG crashed. I wasn't able to do it consistently though. -Jeff On 7/28/06, Melchior FRANZ <[EMAIL PROTECTED]> wrote: > $ fgfs --aircraft=YF-23 --airport=knuq --disable-real-weather-fetch > > - full throttle > - climb to 8000 ft > - 90 degree bank > - pull stick fully back > amazingly: you don't bleed off speed, but *accelerate* > - at ~1630 kt (after that the speed decreases) 0 degree bank and > 90 degree pitch up > - climb to 163000 ft in no time > > m. :-) > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YF-23/yasim: how to climb to 163000 ft
$ fgfs --aircraft=YF-23 --airport=knuq --disable-real-weather-fetch - full throttle - climb to 8000 ft - 90 degree bank - pull stick fully back amazingly: you don't bleed off speed, but *accelerate* - at ~1630 kt (after that the speed decreases) 0 degree bank and 90 degree pitch up - climb to 163000 ft in no time m. :-) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
Ampere K. Hardraade schreef: > On Wednesday 26 July 2006 12:53, Robin van Steenbergen wrote: > >> I'm working on an accurate >> model of Eindhoven Airport and you can actually put the ground chart of >> the airport on the 'floor' and model on top of that. >> > > We have the capability to generate an airport directly out of the ground > chart. > > Ampere > I know that, since all the airports in the Netherlands are made that way. But there's one pretty important thing that's not generated on the ground chart: The buildings are all missing! Most ground charts do have the buildings on them but they're not labeled and they're pretty hard to auto-generate since they require modeling. Or you have to represent them as boxes like FS2004 does, but that's not exactly pretty. I'm using the ground chart to determine the correct sizes of my buildings (using the runway as a reference) and their placement. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear MP authentication
--- Martin Spott wrote: > I know, this discussion is barely coupled to ongoing development, but > because I like to participate in creating admirable plans, I don't want > to miss it :-)) Yup, there's nothing like designing something there is little chance you will implement yourself ;). > "Buchanan, Stuart" wrote: > > > 2) Account holders have a key generated based on their call-sign (*). > This > > is transmitted with the MP position data. The MP server uses it to > > authenticate the user. MP server doesn't need to check against the > LDAP > > directory. > > I believe it is essential to verify a key against the directory because > otherwise you won't be able neither to check if the key really belongs > to the account holder nor to verify if it's still valid. > I think the validity of a key has to be verified against the directory > from time to time using a fixed interval. I think you _can_ check the ownership of a callsign without checking against the directory. The trick is to use public/private key encryption. When a user creates an account on the website they decide on a call-sign. The website checks the uniqueness of the callsign against it's own directory/whatever. Assuming it is unique, the callsign is then encrypted using the private key and the ciphertext is retained by the user. When the user joins a MP session, both the ciphertext and call-sign are passed to the MP server. The MP server decrypts the ciphertext using the public key and verifies that the cleartext matches the call-sign. Where this falls down slightly is in verifying that a call-sign is still valid. I'm not sure that is a requirement though. Do we want to be able to recycle call-signs that haven't been used for a period of time (a year)? To do so, we can simply remove the user from the directory, with means theie callsign can then be recycled. However, the original user can still join a MP session with their old callsign. -Stuart ___ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
Jason Cox schreef: > Hi all, > just wondering on weather some one has looked into "tapping > into" the > 3d models that are available for downlaod from google earth? > i think we maybeable to use these if we convert them as they are created > by users of the sketchup program. > any thoughts? > Jason > That should be possible. Google SketchUp models are .kmz files which are nothing more than ZIPped XML files with vertices, polygons, textures etc in plain text. I'm a very big fan of SketchUp and it's great for developing scenery, the only thing is that no-one has ever attempted to create a converter for Keyhole Markup Language (XML with a defined format) to a 'regular' model format like 3DS or Gmax. Should be possible though. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
FWIW, the current precipitation rendering code is raw-gl-based as well, not even done with proper branching via ssg; we just have a special call to its rendering from within the renderer. I am currently working on texturing-based precipitation which needs multitexturing, and naturally it can't be done fully above ssg w/o raw gl codes since multitexturing is not supported in ssg. My plan is to first achieve a sensible visual effect/performance, (at which point a demo patch will be posted over to the list with a call to you texture artists for better textures for rain, snow. and hail) then ssgify it properly to make sure the gl state is managed in a coordinated way between the precipitation code and the other ssg-based one (a milestone for another patch), and, finally, fix the culling issues (so that we no longer rain into underground etc.) Currently I am having some nasty visual artifacts which make the whole thing look worse than the GL_LINES based current code; I am getting 25-33% FPS drop here on various nvidia cards (33 on older ones, 25 on better ones). I might be able to improve the FPS drop though, as I have some GL optimization tricks unused yet. Nevertheless, since the FPS impact is no longer negligible (like it's in the lines-based code), it means that there will be a configurable rendering option to stay with the GL_LINES based old code for those who don't want the penalty, although I won't guarantee a runtime-switchable (i.e., you need to reload fgfs). For cards w/o the multitexturing capability, it's automatically going to be using the old precipitation code. Vassilii - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
