Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.26, 1.27 fg_fx.hxx, 1.17, 1.18

James Turner wrote: > Ah, what I was really hoping to do, was to break the dependency on the > FGViewer, and globals->get_aircraft_model(), by getting the equivalent > position and orientation from the property tree. I haven't checked how > straightforward that is, but having the sound code

Re: [Flightgear-devel] Sound positioning and orientation

James Turner wrote: > On 21 Aug 2008, at 13:33, Erik Hofman wrote: > >> I knew it! :) >> Ok, I' l take a look at that, good idea. > > One of the things on my medium-term list is to carry on the subsystem- > ification work. To reach the ultimate goal (mainlo

Re: [Flightgear-devel] osgDB ac3d reader: detected surface with less than 3 vertices!

gerard robin wrote: > > Hello, > > Does anybody, here, knows, how to know, which .ac model/object gives the > following warning message, during FG loading ? > osgDB ac3d reader: detected surface with less than 3 vertices! > Which model/object name is involved? > > It is rather easy when the

Re: [Flightgear-devel] Sound positioning and orientation

James Turner wrote: > On 21 Aug 2008, at 13:25, Erik Hofman wrote: > >> I'm working on proper Listener positioning for sound playback in >> FlightGear and encountered a difference between the coordinate system >> described in README.xmlsound (which describes a

[Flightgear-devel] Sound positioning and orientation

Hi, I'm working on proper Listener positioning for sound playback in FlightGear and encountered a difference between the coordinate system described in README.xmlsound (which describes a right handed system that doesn't exists, it describes a left handed system instead) and the actual coordin

Re: [Flightgear-devel] Blackout/Redout

gerard robin wrote: > I mainly wonder if the basic calculation for the g-load is right. I have > copied from the F16 (by Eric) the "g load corrected" which is > > > accelerations/n-pilot-z-norm > -fcs/n-pilot-z-correction > It si both right and wrong. I reality when standing on a runway the

Re: [Flightgear-devel] Textranslate Step and Scroll

Erik Hofman wrote: > If I understand this correctly I think FlightGear already provides a way > to do that. I've recently attached a 2d-panel text animation to a 3d > model to display all sorts of text information in an Data Entry Display > (DED). > > See FlightGear/d

Re: [Flightgear-devel] Textranslate Step and Scroll

John Denker wrote: > 5) Using textranslate to implement the frequency digits on a digital radio is > still a > kludge. The xml required to do this is long-winded, to say the least. The > patches > presented here do not remove the pressure for a nicer api. Some sort of > sprintf and > subs

[Flightgear-devel] F-16 upgraded to 'production' status

Hi, I have been busy updating the F-16 flight computer lately which turned out the have quite some problems. After extensive (and many, many hours of) work I'm pleased to announce it is finished now. I know others have been using this FDM to model other aircraft, so I've added a bit of documen

Re: [Flightgear-devel] f16 speedbrakes

Ok, tested it again. The only way I could reproduce your scenario is not to have the throttle near idle. As I did state earlier, the speeedbrakes of the F-16 are quite small and as it turns out the engine can easily produce enough thrust to overcome the increased drag. Erik --

Re: [Flightgear-devel] f16 speedbrakes

Alex Romosan wrote: > hmm, i don't know how the real f-16 behaves but i still find the > current behaviour a bit strange. level flight, ~350 knots extend the > brakes the aircraft pitches up slightly and really starts to climb (no > effect on the speed at all). push the nose down (quite a lot) to b

Re: [Flightgear-devel] f16 speedbrakes

Ok, I think I have most of it figured out. I might even consider upgrading the status to 'production' the way it is now. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest

[Flightgear-devel] black out behavior

Hi, Ever since I switched to the CVS version of FlightGear I wondered whether the black-out behavior really is that realistic . Although I never experienced it I couldn't imagine this would happen in real life, at least not with an anti-g suit. In an excerpt from a nasa document describing a si

Re: [Flightgear-devel] FGFS is at SigGraph

Tim Moore wrote: > They are using the new feature that allows a generic protocol > playback file to be played back in an infinite loop. > > Nice going! > I think I've heard this announced a few weeks back .. ;-) Indeed, nice going. Both for ATI and for the FlightGear contributors. Erik

Re: [Flightgear-devel] f16 speedbrakes

Alex Romosan wrote: > i think there is still something wrong with the speedbrakes but i am > not sure how to quantify this. basically i think they provide way too > much lift (which makes me suspect there is a sign problem somewhere). > the effect is more pronounced at slower speeds (250 - 300 kn

Re: [Flightgear-devel] F-16

Jon S. Berndt wrote: > Erik worked on the F-16 quite a bit this past couple of weeks (with some > good comments supplied to help narrow down the problem) and it appears to be > flying well, now. I know this model has given some strange behavior in the > past. Hopefully, that's behind us. Actually

Re: [Flightgear-devel] Screen shots

Jon S. Berndt wrote: > I'm looking for a few high quality (fairly large) screen shots of JSBSim > aircraft models in FlightGear. Can anyone point me to some? I want to use > them as background illustrations in the JSBSim manual now being drafted. > I've put a few screenshots of the F-16 over he

Re: [Flightgear-devel] Cockpit displays (rendering, modelling)

James Turner wrote: > Yeah, I've also (just) been looking at the state of the art in SVG -> > GL rendering. I was hoping to find something reasonably compact, but > there's various dead links and so on. This might be exactly what you need: http://fabrice.bellard.free.fr/TinyGL/ Erik -

Re: [Flightgear-devel] A patch to prevent multiple loading AIModels on reset

Tatsuhiro Nishioka wrote: > So here is my suggestion. > First, we use my patch as a temporal fix just to prevent the fps drop. > Second, we investigate a reasonable means of loading and unloading AIModels > on reset (and remove my patch). > > Any opinions? Sounds good to me. Erik

Re: [Flightgear-devel] A patch to prevent multiple loading AIModels on reset

Tatsuhiro Nishioka wrote: > Hi forks, > > I've encountered a weird fps drop in resetting on Nimitz (with > --carrier=Nimitz). > It happens since AIBase loads AIModels on every reset, which should not. > > The same problem happened on 0.9.11-pre2 and I made a patch to fix it, but > the patch was

Re: [Flightgear-devel] f16 speedbrakes

Alex Romosan wrote: > Erik Hofman writes: > >> Looking at the code it looks like setting speed-break-pos-norm should be >> the same as setting speed-break-pos-rad so the patch shouldn't have any >> effect. > > look at aero/coefficient/CDDsb or fcs/mag-s

Re: [Flightgear-devel] f16 speedbrakes

Alex Romosan wrote: > Erik Hofman writes: > >> Looking at the code it looks like setting speed-break-pos-norm should be >> the same as setting speed-break-pos-rad so the patch shouldn't have any >> effect. > > look at aero/coefficient/CDDsb or fcs/mag-s

Re: [Flightgear-devel] f16 speedbrakes

Alex Romosan wrote: > i noticed that on the f16 the speedbrakes have no effect at all and i > managed to track it down to the fact that the various coefficients use > fcs/mag-speedbrake-pos-rad on input which never gets set anywhere (so > it is always 0). > > digging through the cvs logs i found t

Re: [Flightgear-devel] using std::

Tim Moore wrote: > To add my two cents: > I mostly favor putting "using" declarations at the top of source files > instead > of using namespace qualifiers in the code. On the other hand, I would > probably > use the namespace qualifer explicitly if the symbol in question is somewhat > obscure,

Re: [Flightgear-devel] using std::

James Turner wrote: > I think this is a good example of why 'using std::xxx' is potentially > problematic in headers (especially public library headers, i.e > Simgear), but fine in sources. So if I'm doing future cleanups, that's > the approach I'd take - remove 'using' from headers, and add

Re: [Flightgear-devel] using std::

Melchior FRANZ wrote: > * Erik Hofman -- Wednesday 30 July 2008: >> To continue this discussion a bit (please add your comments) James an I >> had a short discussion about using std::string (for example) everywhere >> in the file or using " using std::string;" at t

[Flightgear-devel] using std::

To continue this discussion a bit (please add your comments) James an I had a short discussion about using std::string (for example) everywhere in the file or using " using std::string;" at the beginning. James pointed out that the suing std:: statement in header files might not be a good idea

Re: [Flightgear-devel] Header restructuring

Melchior FRANZ wrote: > Just for the record: the old HUD will also be removed very soon, > probably within the next two weeks. I only have to check what > needs to get ported first. (The f16 is one such candidate. :-) > > Yeah I know it uses the "old" HUD, but I didn't even know there was a

[Flightgear-devel] Header restructuring (was: windows.h)

I've now committed two patches provided by James Turner that does a lot of header and declaration cleanups; * SG_USING_STD is now replaced by: using std:: * SG_GL_H is replaced by * SG_GLU_H is replaces by * All STL_* includes are replaced by their proper names As far as I can tell I didn

Re: [Flightgear-devel] BalloonSim and MagicCarpet

Durk Talsma wrote: > Is it possible you still have the library there from an older build? > That could well be.. good thinking. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the c

Re: [Flightgear-devel] BalloonSim and MagicCarpet

Durk Talsma wrote: > I did just remove a reference to FDM/Balloon/ in Main/Makefile.am, which > looks > like a genuine leftover from the old situation... > > Thats ok, somehow this didn't show up in my build..(?) Erik -

Re: [Flightgear-devel] BalloonSim and MagicCarpet

Durk Talsma wrote: > Just for your information, I just reverted FDM/SP/Makefile.am back to it's > original shape. I'd been a bit too quick in deciding these two FDMs had been > removed altogether, but now I see they are back. :-) > > Melchior pointed out to me I had forgotten to add these fi

[Flightgear-devel] BalloonSim and MagicCarpet

Hi, I was about to move the BalloonSim and MagicCarpet fdm's to the Special Purpose directory but since JSBSim now supports balloons: Are these fdm's still used for anything? I know MagicCarpet was used for scenery browsing but I think is has been replaced by the UFO hasn't it? Erik ---

Re: [Flightgear-devel] Legacy #ifdefs

James Turner wrote: > Patch to remove macintosh and MWERKS from Simgear. > > Tested on Mac only - I'd verify Linux compilation normally but > currently travelling. Tested for Linux and committed. > > Note, screen/colours.h contains some code relating to gamma which > looks very, very unlikely

Re: [Flightgear-devel] Legacy #ifdefs

James Turner wrote: > The key question is, are all of the above #defines safe to be killed? > And are there any others I've missed? There's occasional references to > Borland and IRIX compilers (i.e ancient versions of gcc, like pre > 3.x!) in some #defines which I guess could also be cleaned

Re: [Flightgear-devel] 2d panel question

The README.xmlpanel file shows what I already seemed to remember: Regarding Window Geometry: - For the sake of simplicity the FGFS window is always considered to be 1024x768 so all x/y values for instrument placement should relative to these dimensions. Since FG uses

Re: [Flightgear-devel] FlightGear OSG

Detlef Faber wrote: > This is most likely sorting order. I usually fix this by putting the > transparent parts in a seperate xml file and load it at the very end of > my model.xml file. This works with plib too. > > Avoid transparent parts in textures. Weird things can happen. Ok, thanks for th

Re: [Flightgear-devel] FlightGear OSG

AJ MacLeod wrote: > The F-16 looks good here - the only transparency problem I can find is with > the star and bars markings (bottom right of f16.rgb) and that could easily be > worked round by removing the transparency in that part of the texture. > > It sounds like you're seeing something much

Re: [Flightgear-devel] FlightGear OSG

Vivian Meazza wrote: > 3d clouds have not been ported to osg. At the current rate of progress - > sometime in the next decade :-). That's a pity. > Rain/snow should work nicely: has your osg version got all the plugins > included, and are they in the path? As far as I can tell everything is ins

[Flightgear-devel] FlightGear OSG

Hi, Now that I've installed the CVS version of FlightGear I noticed a few things; * I don't have 3d clouds and shrub/tree cover anymore. Is this based on shaders these days? * Rain/Snow is rendered like dots on my system (not like the screenshots I've seen) and doesn't originate at the pr

Re: [Flightgear-devel] generic protocol?

Curtis Olson wrote: > Is it possible to leverage the --generic protocol to automatically > replay a flight from a data file created originally with the --generic > protocol? If so, does anyone have an xml config file setup to capture > all the important variables? I once created a quick hack

Re: [Flightgear-devel] [SECURITY] Nasal: io.open() restricted

Melchior FRANZ wrote: > * Erik Hofman -- Monday 16 June 2008: >> (What are the reasons to write to a file anyway?) > > Writing non- XML files, like they are used in the > traffic manager and for flight plans. Maybe making sure the file ends with .xml could also

Re: [Flightgear-devel] [SECURITY] Nasal: io.open() restricted

Melchior FRANZ wrote: > It's funny that nobody cared a year long, and now that the danger > is supposed to be banned, people get scared and nervous. :-} I don't, I just though I could help here. Erik - Check out the new Sou

Re: [Flightgear-devel] [SECURITY] Nasal: io.open() restricted

Melchior FRANZ wrote: > * Sven Almgren -- Monday 16 June 2008: >> like --io-read=/myDir --io-read=/tmp --io-write=/etc/passwd ? > One could, of course, use this instead: > --prop:io-read=/myDir --prop:io-read[1]=/tmp ... I don't consider any command line option a security thread since writing

Re: [Flightgear-devel] [SECURITY] Nasal: io.open() restricted

Melchior FRANZ wrote: > It's well known that Nasal has an io module with wrappers around > fopen(), fclose(), etc. An aircraft that you install, or even > scenery objects with embedded Nasal could in the past use this > to delete the contents of your whole home directory, or to append > commands to

Re: [Flightgear-devel] Sound problem stops FG start

LeeE wrote: > That _is_ strange re getting it with the UFO. What happens if you > remove the mkvii instrument entirely? > > Can you play the sample separately - through xmms, or whatever media > player you use? Can you play _any_ sound samples at all? Is it > just with FG that you get this

Re: [Flightgear-devel] Walking around

Detlef Faber wrote: > Hi everybody, > > I've just committed a "Walk View" to the jeep, so a virtual passenger > can get out of the car and walk around in the scenery. > > The View follows the terrain height and the movements gets blocked by > steep slopes and scenery models (sadly not by random s

Re: [Flightgear-devel] Shader based random trees and improved random objects

Curtis Olson wrote: > This will be a challenge for us as we move forward with development of > the OSG tree. How much old hardware should we support, and how far back > should we go? I've been thinking about this too and for me it's actually quite simple. FlightGear 1.0/PLIB is fantastic for

Re: [Flightgear-devel] FlightGear hangs on startup (Was: Random Objects OSG patch)

Tim Moore wrote: > If you are going to enable random objects, I recommend using OSG 2.3 or > later. Otherwise, > set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Installing OSG 2.3.1 did indeed do the trick but it's still slower at startup than I was used to. I think I'll d

[Flightgear-devel] FlightGear hangs on startup (Was: Random Objects OSG patch)

Tim Moore wrote: > I've checked this work in, with a change to use an independent quad tree > builder class. > Thanks very much for the contribution; it's good to have another OSG hacker > in the > house. With the latest version of FlightGear I got it to hang while loading the scenery objects

Re: [Flightgear-devel] Realistic water for FG tutorial!

Pavel T wrote: > Hello Developers, > > I've found a realistic water tutorial for openGL snd maybe you could use > this for FG? Link: > http://www.gametutorials.com/Articles/RealisticWater.htm > > > Let me know if you can use this for

Re: [Flightgear-devel] Random Objects OSG patch

Christian Mayer wrote: > This might be a case where the great BOOST Project might help us: > > http://www.boost.org/libs/random/index.html One thing to keep in mind when using random generators is that it would be realy nice (if not required) to generate the same output on all supported platfo

Re: [Flightgear-devel] Aircraft downloads page update

Fabian Grodek wrote: > The download page contains other aircrafts with no 3D models: > 1. F-15 (NOT F-15C) > 2. Marchetti > 3. X-24B > 4. Shuttle > Their FDM are present. > I particularly like to have the FDM of these aircraft available, but, at > least for the JSBSim models (X24B and Shuttle), th

Re: [Flightgear-devel] Colombian Air Force virtual T-37 for FSX

Grupo de Investigación VOLTA wrote: > Dear Sir: > > We are very interested in develop the T-37 for FSX in the way that you > said. Please contact us whit the persons who could help us (if is > different to you), this to establish the specifications, develop time, > cost and mode of payment. > > O

[Flightgear-devel] Colombian Air Force virtual T-37

Hi, I received the following request from a university group: > VOLTA is a research group of Militar Nueva Granada University, in this > moment we are development a project for Colombian Air Force. In reference > with a e-mail send by JHON JAIRO PALOMINO LOSADA (it was send in > 25-oct-2007), We

Re: [Flightgear-devel] Deleting globals

Durk Talsma wrote: > hi, > > While trying to hunt down some memory leaks reported by valgrind, I noticed > that many variables in FGGlobals (which are mainly pointers to many of the > big data structures and subsystem classes) are not deleted upon program exit. > > In most cases adding explic

[Flightgear-devel] Google Earth FlightSimulator

Hi, It looks like google provides a simple flight simulator with googlemaps: http://marco-za.blogspot.com/2007/08/google-earth-flight-simulator.html Looking at the screenshots it does remind me of an early version of FlightGear (which might or might not be true), but most of the key strokes matc

Re: [Flightgear-devel] namespace simgear

Tim Moore wrote: > Hello, > I'm about to check in a header file in SimGear that is contained in namespace > simgear. > Are there any objections, or reasons why we shouldn't introduce this > namespace? Backwards compatibility is the main reason not to use namespaces. For new classes there shoul

Re: [Flightgear-devel] no doppler sound with actual build

Maik Justus wrote: > That would be the best. But how to know, that 1.2 would work? It looks If version 1.2 still contains this bug it will be noticed rather quickly and changing the test would be easy. > like, if the OpenAL Doppler effect bugs are a never ending story. And > they do not work

Re: [Flightgear-devel] no doppler sound with actual build

Melchior FRANZ wrote: > So it's now also clear that we have to fix FlightGear's broken > sound ourselves for 0.9.11 (fg/plib branch). If it can be done > in a way that doesn't break the current framework and makes clear > which parts are the workaround (by using #ifdefs and comments, > as is the c

Re: [Flightgear-devel] no doppler sound with actual build

Maik Justus wrote: > Yes, no problem to wait for an answer on the OpenAL-devel list. I read > through the archive and found a long thread in september 2005, where > they fixed some Doppler bugs. Probably it was our bug. Don't know, when > this will go into a release. Do we really want to depend

Re: [Flightgear-devel] no doppler sound with actual build

Maik Justus wrote: > If you have any argument against the patch, please let us know. As the original author of the FlightGear sound class and the one who put the directional code in FlightGear I'm opposed to this patch. Let's just wait what the OpenAL developers have to say before we continue

Re: [Flightgear-devel] patch: don't warn if a sound is clipped, was Re: For the - Author of Concorde - Continued (Email in Unicode format)

Maik Justus wrote: > Hi, > the enclosed patch would do the thing (but maybe SG_DEBUG would be > better, it's really only a debug message, the user need not to be warned > about this). Indeed and that's what the warning is for; the author should fix the sound configuration file. Erik -

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/FDM/JSBSim/initialization

Martin Spott wrote: > Hi Erik, > > Erik Hofman wrote: >> Update of /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/initialization >> In directory baron:/tmp/cvs-serv26522/initialization >> >> Modified Files: >> Tag: PRE_OSG_PLIB_20061029 >>

Re: [Flightgear-devel] An-2 v0.2 ready!

Syd & Sandy wrote: > Hello all, > I have used aggressive compression for splash screens in past, and > always crashes Flightgear on my system. Doesnt seem to be a problem for > model textures , though. Ah, yes, now that you mention it: The rbg loader for the splash screen is a different than t

Re: [Flightgear-devel] [RFC] T38 changes

Hi Csaba Halász wrote: > After these modifications I didn't notice any change in the behavior > of the plane, but the visual experience is a lot nicer. > I ask for your comments (especially the original authors' or the > maintainers'), as I am a newbie in this field and also without > documentat

Re: [Flightgear-devel] An2 problems

Jon S. Berndt wrote: >> Hi Jon, >> >> Yeah, this was kind of what we were talking about :-) >> > > Oops. OK, are there problems with any other propeller aircraft? It shouldn't be, I testes a lot of aircraft before committing the code. Could be the AN-2 slipped my attention though. Erik -

Re: [Flightgear-devel] CVS: data/Aircraft/bell206/Models bell206

gh.robin wrote: > Seriously i do not want to start an other topic on the advantage to take main > decisions in a democratic way.. There's nothing democratic in copyright law. > > My call to pauljs75 was a joke, it was the continued of a stupid remark Hmm, okay but please remember that

Re: [Flightgear-devel] CVS: data/Aircraft/bell206/Models bell206

gh.robin wrote: > Hello pauljs75 > Welcome to the By_Melchior_Franz_Nomination Unreliable_Authors Club A bit unfair isn't it, I assume you're paying the penalties when copyright infringement is detected en we get sued by someone or some company? If not I would expect you to be a bit more poli

Re: [Flightgear-devel] gear compression +- wow

Jon S. Berndt wrote: >> John Denker wrote: >> I can't test this right now, but I suspect that this line in FGLGear.cpp >> is the culprit: >> >> WOW = lastWOW = true; // should the value be initialized to true? >> >> I recommend changing this to: >> >> WOW = lastWOW = false; >> >> I suspect that

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/f15c f15c-set.xml, NONE, 1.1 f15c-sound.xml, NONE, 1.1 f15c-splash.rgb, NONE, 1.1 f15c.xml, NONE, 1.1 thumbnail.jpg, NONE, 1.1

Curtis L. Olson wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/f15c > In directory baron:/tmp/cvs-serv16727 > > Added Files: > f15c.xml > Log Message: > Fabrice Kauffmann: > > Here is the initial revision of the F-15c: > > http://fkauffmann.ifrance.com/archives/ > > I still

Re: [Flightgear-devel] JSBSim version in cvs HEAD

Torsten Dreyer wrote: > is there a specific reason, why there is the new version of JSBSim only in > PRE_OSG_PLIB_20061029 and not in HEAD? Yes, it gives me a core dump in that branch. Erik - Take Surveys. Earn Cash. Influe

Re: [Flightgear-devel] Tiger F-5E in work

Hi Christion, You are aware that the T-38 (which is avaibale already) is basically the F-5 Tiger aircraft (the T38 is near the bottom): http://www.flightgear.org/Downloads/aircraft/index.shtml Looking at what you've done so far I think combining your 3d panel and the T-38 exterior 3d model and

Re: [Flightgear-devel] F-16 textures

Martin Spott wrote: > "Paul Cardinaels" wrote: >> Just a little progress report >> >> http://users.skynet.be/Pensacola/up.jpg > > Uuuuh, well done !! > You know, our reference for an F-16 model ist the one of the CSP, > http://csp.sf.net/ ;-) Not really, mine is modeled after the real aircraft a

Re: [Flightgear-devel] Could not find plugin

Ralf Gerlich wrote: > Normally the AC3D-reader is enabled. Did you include the > /lib/osgPlugins-directory in your LD_LIBRARY_PATH? Eh, no. Aha! Thanks for the hint. Erik - Take Surveys. Earn Cash. Influence the Future of

Re: [Flightgear-devel] Could not find plugin

Martin Spott wrote: > Hi Erik, > > Erik Hofman wrote: > >> Do I need anything in particular for the CVS version of OSG to enable it >> to recognize AC3D files? > > Which 'distribution' of OSG did you use ? The one presented here should > work: >

[Flightgear-devel] Could not find plugin

Hi, After not having done anything related to FlightGear for much too long I decided to give the OSG code a try. I managed to get past the nasty APIENRTY build problem but now I am unable to load any of the aircraft: Warning: Could not find plugin to read objects from file "/opt/share/Flight

Re: [Flightgear-devel] OSG and multicore processor

Curtis Olson wrote: > On 11/7/06, *Ampere K. Hardraade* <[EMAIL PROTECTED] > > wrote: > > Shouldn't there be three? Or is FlightGear not getting inputs from > the user when it hangs? > > Well by my count: 1. main thread, 2. scenery paging thread, 3. weather >

[Flightgear-devel] OSG performance/object loader (Was: OSG Issues)

Olaf Flebbe wrote: > Thanks for this huge testing effort! Mathias gave me a prerelease of a > new AC3D loader. That fixed all the aircrafts which SEGFAULTED before, > but not the OV10-CDF. Which reminds me, plib did an excellent job at improving rendering performance of 3d models using Andy's

Re: [Flightgear-devel] XML Property synonym mechanism?

leee wrote: > On Tuesday 07 November 2006 08:57, Erik Hofman wrote: >> This can be done using aliases: >> >> >> >> >> >> >> > > That's interesting - is it possib

Re: [Flightgear-devel] XML Property synonym mechanism?

Rémi Lafage wrote: > Thus I would like to specify the > /instrumentation/attitude-indicator/indicated-roll-deg property > to be a synonym of the /orientation/roll-deg property. This can be done using aliases: Erik -

Re: [Flightgear-devel] OSG Performance on WIndows

Vivian Meazza wrote: > Let’s hope that you’re correct. Right now we have _/fewer/_ features, > and a _/lower/_ frame rate. I hope that adding back the features we used > to have won’t further reduce the frame rate, let alone adding new ones. One area which will give quite a performance boost wil

Re: [Flightgear-devel] Tower Simulator

Peter Gervais wrote: > The issues as i see it is being able to simulate not one but many > aircraft as seen from the tower. Tower sims also support various ground > based vehicle such as fueling trucks , service vehicles etc ... Our multiplayer code was developed just for this purpose at first.

Re: [Flightgear-devel] reviews etc.

Melchior FRANZ wrote: > English: > http://www.freesoftwaremagazine.com/articles/flightgear I particularly like this one and it's worth mentioning on the frontpage IMHO. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight

Re: [Flightgear-devel] Is the serial port communication working by dir = bi?

Thiago Holanda wrote: > Hello all, > > I want to receive and send data by JUST ONE serial. To be honest I have no idea if this has ever been tested, so it might not be implemented or that code may contain some bugs. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente htt

Re: [Flightgear-devel] 3D model for the F-15

flying.toaster wrote: > If there is no 3D model for the F-15 in the works I can contribute this one > http://sfp1.site.voila.fr/images/f15b.png > > I plan to make it in NASA livery > http://www1.dfrc.nasa.gov/Gallery/Photo/F-15B/Medium/EC96-43815-2.jpg > > I've started similar work on the F-18

[Flightgear-devel] IL-76

Hi, If anybody has any desire to model the IL-76, here is a large collection of pictures taken of the aircraft while visiting my local airport: http://jwg.student.utwente.nl/ehtw/vda06/ra7644501.htm http://jwg.student.utwente.nl/ehtw/vda06/ra7644502.htm Erik -- http://www.ehtw.info (Dutch)

Re: [Flightgear-devel] Pilatus PC-7 panel patch

Martin Spott wrote: > "Buchanan, Stuart" wrote: > >> Here's a patch for the PC-7 to add a panel to the 3-D cockpit. In fact, >> the panel is the same as the 2D one, so the only real affect is to attach >> the 2D panel to the firewall so it doesn't disappear when you move the >> viewpoint. > > I

Re: [Flightgear-devel] ocean rendering regression

Mark wrote: > Another thing I noticed is that the drawn highlights cover almost the > entire tile. > This might be OK for some materials, but for water there should be a > rather sharp highlight. > Maybe this was changed and now is causing the trouble? No, this has been that way since the begi

Re: [Flightgear-devel] ocean rendering regression

Mark wrote: > At the first glance it it seems to have to do with the materials rather > than the sun. > How do they both interact exactly? > > Anyway, I looked into my code and tried some changes that could affect > this. However there wasn't any impact. > So, to say the truth, I'm a bit cluele

Re: [Flightgear-devel] OT: Blueprint for Disaster: Enschede 13 mei 2000

Jim Wilson wrote: > Wow. I have seen a couple of fireworks barge explosions...one fairly big. > But I have never heard of anything even remotely close to that. It is > somewhat surprising that so many were so close to get hurt, but then again I > can see something like that could attract cur

Re: [Flightgear-devel] OT: Blueprint for Disaster: The Crash at Eschede

Josh Babcock wrote: > Erik Hofman wrote: >> Hi, >> >> Most of you probably still remember that I had to evacuate my home in >> May 2000 because of a fireworks depot exploding near the center of my >> City (about 300 meters from my home). > > Now I ho

Re: [Flightgear-devel] OT: Blueprint for Disaster: Enschede 13 mei 2000

Erik Hofman wrote: > Hi, > > Most of you probably still remember that I had to evacuate my home in > May 2000 because of a fireworks depot exploding near the center of my > City (about 300 meters from my home). Oops, wrong title in the subject, it should be: Blueprint for Disast

[Flightgear-devel] OT: Blueprint for Disaster: The Crash at Eschede

Hi, Most of you probably still remember that I had to evacuate my home in May 2000 because of a fireworks depot exploding near the center of my City (about 300 meters from my home). Discovery Channel has made a reconstruction of the event in an episode of Blueprint for Disaster which will be

Re: [Flightgear-devel] HUD updates

Arnt Karlsen wrote: > ..I can do these, _after_ AirVenture, is 2 weeks from now.won't even think > about > ..you Erik maintain the ACMS fdm? Well both are a bit difficult to maintain since they relay on special setups or input files. The ACMS version for example needs the output file of a com

Re: [Flightgear-devel] Compiling SimGear 0.3.10 on OS X

James Turner wrote: > I'm confused by this; both myself and another OS-X developer have > submitted patches to address this, and at least one set was committed > (not mine, because I had the resolve the conflict when I updated > SimGear). Is this a difference between CVS and 0.3.10 perhaps? Tha

Re: [Flightgear-devel] Compiling SimGear 0.3.10 on OS X

Beat Rupp wrote: > In the CVS log I saw that Alexander Powell made those changes in order > to support Mac OS X ;-) What is the "right way"TM to fix this? I'm not sure, according to Alexander it should work (although is hasn't been able to test it in FlightGear itself) but others have reported

Re: [Flightgear-devel] HUD updates

Mathias Fröhlich wrote: > BTW: is sombody out there maintaining the SP_FDM? I'm not sure about the ADA FDM but I would not want to see the ACMS FDM yanked since it has been (and can be) used to playback the information stored on the Flight Data Recorder (black box). Erik -- http://www.ehtw.

Re: [Flightgear-devel] MIL-STD-1878B -- "Aircraft Display Symbology"

Melchior FRANZ wrote: > * Erik Hofman -- Monday 03 July 2006 13:45: >> What you could do right now is committing the new HUD code [...] > > ... but I should probably do that anyway, just so we have concrete > code to discuss, and maye even to work on. It should just be noted Ag

Re: [Flightgear-devel] MIL-STD-1878B -- "Aircraft Display Symbology"

Melchior FRANZ wrote: > BTW: the reason for this is that the F16 altitude tape uses this > setting: > > >/position/altitude-ft >0.001 >100 >-100 > >1 >0.1 > > > That is, as opposed to before, the tape doesn't see the real > altitude at all anymore

<    5   6   7   8   9   10   11   12   >