Re: [Flightgear-devel] DDS usage in effects files
Mathias Fröhlich a écrit : ... But that means we could at the point where the warning happens compute the mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be used to do this I think (or something similar not requireing a context). This one is an imported version of the original glu function that is included in osg for running on an EGL stack which no longer provides GLU. That is take the image scale this to the 1st mipmap, take the 1.st mipmap and scale this to the 2. mipmap and so forth. This would have the advantage that the png's do not deviate from the dds files over time. gluScaleImage does the usual job of blurring the texture to compute the mipmaps. The advantage of pre computed mipmaps (inside .dds or not) is that we can use better algorithms (http://en.wikipedia.org/wiki/Bicubic_interpolation or http://en.wikipedia.org/wiki/Lanczos_resampling) to generate them. Perhaps gluScaleImage could be upgraded with some more algorithms ; the original code was trying to be fast but this is perhaps useless nowadays if the code runs in a separate thread. HJ. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Massive shared objects import webtool now active.
Olivier a écrit : Hi everyone, I'm happy to announce the production status of the massive shared objects positions import script. Please note: 1. You must only import new objects, not the whole STG file you're working on! 2. Don't add models not present in the FG scenemodels database, nor (yet) OBJECT_SIGN nor OBJECT_STATIC. 3. Don't add forest or other items linked to the landcover. Those items have to be generated based on the landcover, not on objects! The only trees accepted will be those located within airport boundaries, for example. 4. The data you're asking for import should be based for elevation on the terrain shipped with FlightGear/Terrasync, and not on a terrain you could have downloaded or compiled yourself. Else, your objects could appear floating or sunk in the terrain in the current FG scenery... 5. Finally, the import is limited to 100 lines per submission (let's think about the poor scenery maintainer(s)...) 6. The import is quite sensitive about the data in entry, which goes through quite a lot of checkings, including humans, before insertion. Finally, and because I receive many questions about it, the import script for 3D models is on its way, finished to approximately 90%. Be patient. Hope you enjoy it, Oliver Hi Olivier, point 4) is problematic ; I regenerated east of France to have 850 airports and I'm pretty sure that there is a difference of elevation at those airports (and perhaps elsewhere, I did not check). How could I send object elevations for the old scenery when I'm not even using it (for obvious reasons), I use the France regenerated scenery or my own one. HJ. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AI Aircrafts and ground level
Hi, AI aircraft models are often aircraft models that were re used so they are normally not at ground level as is ; some of them were pushed a bit in the up direction, some have a z offset in their xml animation file, and others even have an offset in the AI traffic files. Note that today AI models that have an offset in the AI traffic files can not be used of AI scenario for example. Since I'm actually working a bit on AI aircraft animations, I propose to not use the offset tag in the AI traffic files (ie doing as if that offset was null) and to update all the AI models (or their xml file) that need to be updated (that must be like 20 models that need to be updated, 18 are already correct as is). AC folder Model name ground level ? 717 717.ac yes 737 B737-300.ac no B737-300.ac no 747-400 747-AI.ac no 757 B757.ac no 757-200 yes 767 767.ac nearly 777 777-300.ac yes 777-200.ac yes 777.ac nearly A310 A310.ac yes A319 A319.ac yes A320 a320-fb.ac yes A321 A321.ac yes A322 a322.ac no A332 A330-200.ac no A333 A330-300.ac no A343 A340-300.ac no A345 A340-500.ac no A346 A340-600.ac no A380 A380.ac yes ATR42 atr42.ac no Bae146-200 bae146-200.ac yes beech-200 beech-200.ac yes Bombardier-Challenger chal604.ac no CRJ-200 crj200.ac no Dash8 dash8-400-remap.ac yes dash8-300-remap.ac yes DH7 dh7.ac no Embraer-Legacy legacy.ac yes ERJ145 ERJ-145.ac yes erj195 erj195.ac no Fokker-50 fokker50.ac no Fokker-70 fokker70.ac no Fokker-100 fokker100.ac no MD80 md-80.ac yes MD90 md-90.ac yes saab-340 Saab-340.ac yes Your thoughts ? HJ. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d file formats and "crease angles"
Vivian Meazza wrote: >Roberto > > > >>Sent: 04 November 2007 09:55 >> >>Hi, >> I've been modeling for fgfs a few objects around the world. >>I'm used to >>output everything as .AC files since it looks to me it's the >>most used >>format in FGFS but that has a few limitations that I'd like >>not having. >> >>The one I'm concerned now is the "crease angle" limitation. >>AC3D makes me set a crease angle for an entire object and >>does not let >>me choose to set different crease angles to each surface >>inside the same >>object. >> This does not make sense. A crease angle is used to compute the normals at the *shared* vertices of an object. It's because the normal is shared amoung adjacent faces that the object appears smooth (the normal vectors of the faces sharing this vertex is averaged). Setting random normals for adjacent faces will not make it appear smooth, this is called flat shading. >>... >> >> > >You are quite right AC3D has crease angle set on a per-object basis, and >AFAIK, there is no way round this. I have not found it a limitation - it is >a transition value between crease and smooth. Like you, if there isn't a >convenient value I break the object. There's no penalty for that - numbers >of objects and groups have no performance penalty. > >Vivian > > > Models are usually split because of the animations of parts, or because there is several textures used (or because it's easier for the modeler). But having lots of objects with different 'attributs/animations' has some serious impact on performance. The performance of a modern 3D card is inversely proportional to the number of opengl calls (objects in our case), the number of poly has no impact. Note that some object loader can 'optimize' some objects (with identical attributes) and merge them at load time. So like you said, in a favorable case we don't care about the number of objects ;) HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG: Blended Reflect-Effect on aircraft-skins
Heiko Schulz wrote: >Hi, > >I found a way to have a quite realistic looking >reflect-effect on aircraft skins. > >The trick is to use multitexture. It is in principale >the same technique like seen in MSFS without any hits >on fps. >Unfortunately I did not found yet a comfortable way to >controll it- so I modified the chrome-texture. >But I'm sure there is a way somewhere in OSG- maybe >someone can help. > >I did a small .tar.gz with a example file and a small >note. Copy the files to the A380 and you will see the >effect. > > >http://www.hoerbird.net/fgfs-screen-457.jpg >http://www.hoerbird.net/fgfs-screen-456.jpg >http://www.hoerbird.net/fgfs-screen-458.jpg > >http://www.hoerbird.net/osg-reflect-effect-example.tar.gz > >It is only a simple hack- so it can be improved >easliy. > >Greetings >HHS > > > If you want to try the shader path in osg you could try something like that : http://sites.estvideo.net/tipunch/flightgear/lab/paint.html It was coded for the plib branch and I have no idea on how to integrate that in osg (well it's not even completly integrated in the plib branch, since it was not ready for the pre1 and I thought the next release of fg would come soon, I did not continue to work on that). Another screen shot where the 'reflection' of sky and the progressive fresnel effect is more visible : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-paint2.png HJ. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Frederic Bouvier wrote: > > > >It appears that it is the replay subsystem that creates long pauses >periodically, and sometimes the ai-model subsystem too : >( my traces : ) >D : 12000 replay >D : 11000 replay >D : 17000 instrument20 >D : 18000 instrumentation >D : 12000 replay >D : 12000 replay >D : 14000 replay >D : 19000 replay >D : 16000 replay >D : 18000 replay >D : 11000 replay >D : 22000 input >D : 13000 replay >D : 17000 replay >D : 14000 replay >D : 22000 replay >D : 18000 replay >D : 18000 replay >D : 18000 Traffic Manager >D : 17000 instrument13 >D : 18000 instrumentation >D : 17000 replay >D : 23000 electrical0 >D : 32000 systems >D : 18000 replay >D : 11000 replay >D : 16000 replay >D : 11000 replay >D : 11000 replay >D : 252000 input >D : 11000 replay >D : 12000 electrical0 >D : 15000 systems >D : 11000 replay >D : 17000 ai_model >D : 11000 instrumentation >D : 11000 replay >D : 14000 replay >D : 18000 replay >D : 11000 replay >D : 12000 replay >D : 19000 replay >D : 15348000 replay >D : 16000 ai_model >D : 14000 replay >D : 11000 replay >D : 12000 replay >D : 14000 replay >D : 12000 replay >D : 15000 properties >D : 13000 replay > >Very long pauses are caused by breakpoints in the debugger > >regards, >-Fred > > > The replay subsystem is *very* slow, that's why there is an option to disable it. Anyway you have times from 12 to 18 ms in replay, I have times from 100 to 300 ms in the nasal code. Gc done: Tue May 01 11:50:37 2007 globals->allocCount=179842 dt=106.609360 Gc done: Tue May 01 11:50:47 2007 globals->allocCount=179842 dt=115.206542 Gc done: Tue May 01 11:50:56 2007 globals->allocCount=179842 dt=112.281589 Gc done: Tue May 01 11:51:06 2007 globals->allocCount=179842 dt=102.708584 Gc done: Tue May 01 11:51:16 2007 globals->allocCount=179842 dt=104.459645 Gc done: Tue May 01 11:51:26 2007 globals->allocCount=179842 dt=118.089031 Gc done: Tue May 01 11:51:36 2007 globals->allocCount=179842 dt=104.458248 -- Gc done: Tue May 01 12:41:50 2007 globals->allocCount=343605 dt=300.275594 Gc done: Tue May 01 12:42:11 2007 globals->allocCount=346632 dt=283.045471 Gc done: Tue May 01 12:42:32 2007 globals->allocCount=346632 dt=282.179160 Gc done: Tue May 01 12:42:53 2007 globals->allocCount=346632 dt=273.818600 Gc done: Tue May 01 12:43:14 2007 globals->allocCount=346632 dt=281.277928 -- On windoze XP, I'm affraid there is too many random factors in each report of the problem (mine included). HJ. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Re: FGFS 0.9.11 release candidate two]
Durk Talsma wrote: We probably need an objective way of investigating this problem. One obvious solution would be to add a tic / toc mechanism to FlightGear's subsystem manager. I'm writing this off the top of my head, but I believe that tic; and toc; are the matlab commands to query how much execution time has passed between the two commands. we are currently already feeding delta t into each subsystem, so we have some redundant timing information available. I don't know yet how easy it would be to implement a profiling like functionality into the current architecture, but I might have a few hours to investigate tomorrow. Cheers, Durk Since we you are investigating I don't want to influence you, but I don't think that there is a lot in the susbsystem code after you disable ai and the like. I've attached a profiles I took in July (snapshot of a few seconds of run, does not include start of fg). If you want to profiles parts of the code and have the results in real time you can try iProf (http://silverspaceship.com/src/iprof/) HJ. DevPartner - Performance Analysis Session Summary Started:25/07/2007 21:16:11 Ended: 25/07/2007 21:19:11 Executable: f:\dvlp\plibfg\FlightGear\source\projects\VC7.1\Release\fgfs.exe Command Args:--fg-root=F:\dvlp\osgfg\FlightGear\data Exit Code: 0 Processor Speed:2400 Mhz # of Processors:1 OS Version: Microsoft Windows XP # of Called Methods (with thread starts): 2 023 # of Calls: 20 764 154 Total Timing: 7273,7 Milliseconds TIP-Z9UE7PTNCMA - 2884 (fgfs) Number of Called Methods: 2 024 Percent of Time Spent on Machine: 100,0 Instrumented Source Images fgfs.exe Number of Called Methods: 2 024 Percent of Time Spent in Image: 100,0 props.cxx Number of Called Methods: 97 Percent of Time Spent in File: 27,2 fg_os.cxx Number of Called Methods: 20 Percent of Time Spent in File: 13,8 misc.c Number of Called Methods: 34 Percent of Time Spent in File: 8,4 code.c Number of Called Methods: 35 Percent of Time Spent in File: 7,6 renderer.cxx Number of Called Methods: 9 Percent of Time Spent in File: 6,3 hash.c Number of Called Methods: 13 Percent of Time Spent in File: 5,7 gc.c Number of Called Methods: 22 Percent of Time Spent in File: 4,2 sg_random.c Number of Called Methods: 6 Percent of Time Spent in File: 3,3 tileentry.cxx Number of Called Methods: 8 Percent of Time Spent in File: 2,5 string.c Number of Called Methods: 17 Percent of Time Spent in File: 1,7 leaf.cxx Number of Called Methods: 3 Percent of Time Spent in File: 1,2 placementtrans.cxx Number of Called Methods: 5 Percent of Time Spent in File: 1,1 sg_time.cxx Number of Called Methods: 12 Percent of Time Spent in File: 1,0 sg_binobj.cxx Number of Called Methods: 2 Percent of Time Spent in File: 1,0 subsystem_mgr.cxx Number of Called Methods: 28 Percent of Time Spent in File: 0,9 vector.c Number of Called Methods: 8 Percent of Time Spent in File: 0,8 util.cxx Number of Called Methods: 2 Percent of Time Spent in Fi
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Melchior FRANZ wrote: >* Heiko Schulz -- 9/22/2007 6:19 PM: > > >>Melchior always saying that it is not the issue with >>the setlistner- but I'm sure there is a problem with >>which causes this stutters. >> >> > >And I'm sure it's not. I had the same with the f16, >which uses almost *no* Nasal, and the YF-23, which uses >no Nasal at all(?). (Of course, there's always the global >Nasal stuff, but there was much less at that time.) > > > Can someone plays a bit with a profiler ? While a listener is nothing special, Nasal itself take a substancial part of the cpu time per frame (of course that depends on a few random parameter but I have between 20 & 35 % of the cpu used in the nasal sources). And some time ago I was refering to the garbage collector that causes mini stutters and the gc was running on a period like 1 gc every 20 seconds at fg start and after some time it was like 1 gc every 10 seconds, the time spent in the gc was increasing too. HJ. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Particle Systems
Vivian Meazza wrote: >John Wojnaroski > > > >>Behalf Of >>Sent: 01 September 2007 21:47 >>To: FlightGear developers discussions >>Subject: Re: [Flightgear-devel] Particle Systems >> >> >>I've yet to see a system that IMHO tops what Mark Harris did >>a few years >>ago part of his doctoral thesis. >> >>See http://www.lfstech.com/img/sfo_clouds.jpg. >> >>Someone made a decision a few years ago to replace rather >>than improve. >>Think we all lost a very promising >>implementation, but there might be an opportunity to recover >>what was lost. >> >>Stay tuned... >> >>John >> >> >> There are methods today to do real volumetric display with slices from a 3d volume, so yes there is method to draw clouds a lot better than those. The old implementation of the Harris code in fg was using hard coded cloud shape, hard coded cloud relative position between clouds, hard coded group of cloud around ksfo. The next implementation could do clouds everywhere on the planet, parametrable cloud shapes in an xml file (Harris was using a non editable binary format), parametrable cloud formation type. Wasn't that some kind of improvement ? What could have been improved then is some new texture for the cloud particles or new shapes or whatever, frankly anybody could enhance what I did. Hm wait, you did not realize that Harris clouds are *slow* and ppl on this list were using depreciated hardware... Using his method to render the clouds is very easy to integrate in our code. > >I'm with you on this one John, except I can't see how to integrate that >solution, or the particle solution with the weather radar. But perhaps some >real expert can ... > >Vivian > > > You don't have to integrate anything. Cloud visualization has nothing to do with the radar, the radar only uses the cloud position. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
Stewart Andreason wrote:
>I see that after a File.RESET, the global variables (at nodes) get
>reinitialized to the values they are set to in the nasal file, but the nasal
>(pseudo-global-to-the-one-file) variables do not.
>
>I would like to know how to reset the nasal variables.
>I have rounded them up in a function called start_up
>and tried adding start_up to the section in the main-set.xml, but it
>also is only run once.
>
>Is is there an easier way to check for when to call it without putting it in
>one of the main loops?
>
>if (reinit_vars.getValue()) {
> start_up();
>}
>
>Also, I find placing this at the top level in the nasal file isn't good enough.
>
>How is it that the global.node variables get reset, but my if statement does
>not get evaluated more than once? It seems any functions running after the
>Reset, must be already running with settimer hooks.
>
>Thanks,
>Stewart
>
>
Check
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Nasal_scripting_language.
You'll want to have a listener on the reset signal
setlistener("/sim/signals/reinit", func {
start_up();
});
HJ.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Push Back operations
Durk Talsma wrote: >Sounds like you're working on interesting stuff. >Using C++ most of this would be quite doable already. I'm not exactly sure how >this all could be tied in to the nasal system, but if you have a very >specific problem you're like to address, please let me know, and I'd be happy >to help you out with the C++ part, or trying to interface particular >functions with nasal. Anyway, here's the C++ explanation. >... > > > Thank you a lot for the very detailed explanations, I think that I have everything I need for now. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Push Back operations
Durk Talsma wrote: >Hi, > >For those among us not subscribed to the CVS log messages mailing list; I have >just committed a rather large patch that provides some support for AI >aircraft pushback operations at the beginning of the taxi stage. This code is >designed around the new editing features that have appeared in TaxiDraw >(CVS / NEW_GUI_CODE branch). >... > > I've started to code some nasal script to manage some airport facilities for the user aircraft (docking system, animated jetways, etc). While I'm allready reading the ground network xml file to get the parkings I think it's a bit overkill and counterproductive to do any coding for the taxi network (path finding) on my side , but I need this kind of info to lead the aircraft to a parking place or even code a pushback animation. Do you think it would be possible to : - reserve a parking place for a non AI aircraft - query a path from node a to node b - handle the user aircraft in your traffic jam code to reduce the risk of collision ? This could be very usefull for me. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Severe "Turbulence" (Weather Interpolation Problem?)
Hans Fugal wrote: >Semantically, am I right that for weather scenarios, METAR is the real >weather, Thunderstorm is thunderstorm-like weather (no relation to >real weather?), fair is easy flying (again, no relation to real >weather?), and none means no scenario (manual control?). That's what I >think they should mean but I'm not convinced that that is what they >mean (or anything else that would make sense). > > This is right, except that in the 'none' scenario the weather is still updated by the metar if metar is enabled. I can not remember if this is a bug or a feature. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] route-manager ID's
Syd&Sandy wrote: >again I have to agree , and to implement the MFD on-screen checklist this way >would be agonizing ... >I could be wrong , but I personally think a render to texture would be the >best route , if I could figure out how to do it .I dont care much for the txf >font , Ive tried generating several for better clarity , but haven't been very >successful. > > You should post a photo of what you are trying to do for the MFD, perhaps we can give you a few hints. But anyway we need a little 'animation' to draw text in 3D. We allready have the translate/rotate animation to set the text position, we 'just' need to call the plib/osg draw text function. This would finally allows to draw non static data on 3d instrument or even in the 3d view (point of interest, mp callsigns, etc). HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Landsat based scenery requests
AnMaster wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > >I'm wondering if it is possible to request landsat based scenery of some >specific area (like that was done for LinuxTag and EAA Oshkosh), if yes I >would like to request such scenery for the area around KSFO. > A build on request would be the perfect solution for the end user, we could finally edit those airports and see the result. Or see the result of whatever change we make to the scenary. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Landsat based scenery requests
AnMaster wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > >I'm wondering if it is possible to request landsat based scenery of some >specific area (like that was done for LinuxTag and EAA Oshkosh), if yes I >would like to request such scenery for the area around KSFO. That area looks >really bad (with a hill in the middle of the terminal for example. > > > Landsat imagery is used to determine the landclass if I understand well, this won't change the elevation of the terrain. This elevation is allways wrong where you have buildings, the radar that mesures the height can hit the terrain or the roof of a building. I don't know if there are tools to edit this kind of data. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Building multiple fgfs binaries from one source tree
Stefan Seifert wrote: >AnMaster wrote: > > >>We shouldn't: fg/SDL breaks on Swedish keyboards at least. For example "]" is >>on AltGr-9, that works with both GLUT and FreeGLUT but not with SDL. >> >> > >Interesting: I've been using fg/SDL for at least a year now and am using >a German keyboard where ] is on Alt Gr-9, too and it works. > >Nine > > flaps is AltGr-) and is broken with glut (as a few other keys on the version I use : glut32.dll 9 may 2005). HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 150 update
Melchior FRANZ wrote:
>I also removed the "userarchive" flags on the hobbs and yoke properties,
>and let those properties be written to the c150's own aircraft config
>instead. I decided to not wait for your reply, as the "userarchive"
>settings polluted the systems's autosave.xml file, which would have to
>be cleaned manually by every single user.
>
>
Thanks for the changes,
>There's a bug with the mixture: you redefine controls.mixtureAxis() to
>write to /controls/engines/engine/mixture-lever instead of to
>/controls/engines/engine/mixture, but you didn't also change
>controls.adjMixture(). This breaks the mixture handling for all people
>who have assigned adjMixture() on their joysticks. If the renaming
>is really necessary, then better let both controls definitions as they
>are, and just put that into the c150.main_loop():
>
> setprop("/controls/engines/engine/mixture-lever",
> getprop("/controls/engines/engine/mixture"));
>
>Just using the standardized property names is preferable, of course.
>
>m.
>
>
Ok I did not see the other function. I am using the mixture to alter the
engine rpm (low g, engine start in cold weather, perhaps magneto check)
and this is the only property that is used by the fdm that can make the
wanted effect (or perhaps the throttle but we have the same problem).
That's why I can set the fdm mixture independantly of the mixture lever
position and that's why the handler must set the mixtur-lever property
and not the mixture directly.
I'll make the change to overide the other function too.
HJ.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Asymetric flaps ?
Bill Galbraith wrote: > <> > Don't know if anyone noticed, but the flaps are already split left and > right. I did this for the asymetric flap deflection issue. I saw that ans it is a bit disturbing. If I understand well you take the output from datcom and assign half of those numbers to each flap. Except that we suddenly have negative flap angles in the datcom.xml (they are positive in datcom.out). For CLdf2L you have a table indexed with left-flap-pos-deg that goes from 0.0 to 40 (for example). For CLdf2R you have a table indexed with right-flap-pos-deg that goes from 0.0 to -40 (neg 40). For CdDf2L you have a table indexed with left-flap-pos-deg that goes from 0.0 to -40 (neg 40). For CdDf2R you have a table indexed with left-flap-pos-deg that goes from 0.0 to -40 (neg 40). CmDf2L/R use negative angles too. I'm not sure on how to interpret those tables now. Btw this is not with the last version of datcom+, I've not tried it yet. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 150 update
Jon S. Berndt wrote: >Nice looking 3D model. Did you use the JSBSim converter to convert the >model? Was it relatively painless? Do I even want to know? ;-) > >Jon > > > > > Thank, yes I used the converter at the begining, I don't remember exactly but I think I did a few tries because the files were not at the right place so there was allways something missing, but yes this was relatively painless. Then I've started a datcom model but I still have a few problems to solve so the fdm is a mix of the converter output and some numbers from datcom. HJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cessna 150 update
Hi, I've updated the little Cessna so it should be flyable again (the fdm was still in the jsbsim old format). A few parts were updated too. http://sites.estvideo.net/tipunch/flightgear/c150-026.jpg http://sites.estvideo.net/tipunch/flightgear/c150-027.jpg Harald. This is not a diff http://sites.estvideo.net/tipunch/flightgear/c150.zip (3 Mb) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Custom Scenery for EAA Oshkosh
Ralf Gerlich wrote: >This is currently a local project. I am manually fetching the respective >Landsat tiles (ETM+, 8 channels) and do manual training by marking some >representative areas of different types. The goal is - as I said - to >integrate this with OSGeo, who are also interested in the resulting >data, and to use such data for the whole world to replace the polygonal >features of VMAP0. > > > The thread is mainly about land use classification, but what about roads and rivers ? vmap0 is really inacurate and it's a pain to fly vfr (following road). Not only a lot of features are missing but most of those visible are off by a great distance. And then it's also difficult to add landmarks to the scenary because there is no accurate reference point to help positioning objects. Will we use osm in the future ? And since osm is far from being exhaustif how to make a choice of wich one between osm and vmap to use to generate a tile ? HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot bug fix
Hi,
There was an uninitiliazied member so the autopilot was never doing his
job (at least in a windoze debug build).
HJ.
Index: xmlauto.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Autopilot/xmlauto.cxx,v
retrieving revision 1.24
diff -u -r1.24 xmlauto.cxx
--- xmlauto.cxx 24 Jun 2006 00:52:20 - 1.24
+++ xmlauto.cxx 9 Jul 2007 16:47:06 -
@@ -55,7 +55,8 @@
edf_n_1( 0.0 ),
edf_n_2( 0.0 ),
u_n_1( 0.0 ),
-desiredTs( 0.0 )
+desiredTs( 0.0 ),
+elapsedTime( 0.0 )
{
int i;
for ( i = 0; i < node->nChildren(); ++i ) {
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Sebastian Bechtold wrote: > >Yes, that's true. This might really be something that makes the >implementation a bit more complicated. Currently, I have two >ideas to solve this problem: > >1.) >Apply the textures on tile-level. The tiles have a regular rectangular >shape, so you could map one texture on one tile, without any >overlapping. A problem with this could be the dimensions. You'd need >quite large textures to get an acceptable low value of square-meters per >pixel. I don't yet know enough about 3D programming to judge if this >is feasible or not (hardware-limited maximum texture size, OSG / FlightGear >performance with handling such huge textures and so on), but at least >we could try it. > >2.) >Use smaller textures (for example 2x2 or 4x4 per tile) and draw >overlapping redundant borders to their neighbor textures. Mhh...I have >problems to write a good explaination of this in english...I mean...near the >borders of each texture (for example a 100 Pixel wide "frame"), you draw >exactly the same pixels as you draw on the corresponding "frame" of the >neighbor >texture in each direction. You would then apply the textures so that they >"overlap" and decide with triangle in the "border area" is filled with >which >one of four adjacent textures. When the "frames" are wide enough to >cover every >irregular shape that could occur, it should be possible to handle the >problem this way. > >A clear disadvantage of this approach is, of course, the additional graphics >memory requirement, and it's perhaps a bit harder to implement. > >I don't know what's better or if there are other, better ways to solve this. >Feel free to help finding a solution! :) > > >Cheers, > >Sebastian > > The point 1) will give worse ground texture than today if we set the texture size at 4090^2. The point 2) is better except that this 100 pixel border is arbitrary. Sometimes it will be ok but i'm afraid there is some triangles that will go very far inside adjacent texture (some sea triangles inside the bay are very long for example). But if the the real problem is those anoying triangle why not simply delete them ? Frankly we don't care about the geometry in the btg file, we just need a height field, let just built this grid and voila (this is for the display, the btg is still used for agl computation, intersection, etc or not because finding a height in a grid is instant, no more sequential scan of a soup of triangles). HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Sebastian Bechtold wrote: >> Your thread title is misleading, >> >> > >Sorry, but I don't think so. The title describes my intentions pretty well. > > > >>what you really want to do is to add >>layers, so to add some geometry drapped around the terrain. >> >> >No, I don't I want to do that. I want to do what I've been >talking about in my posting. > > >Best regards, > >Sebastian > > > Ok, I was reading a bit fast and saw rounded curve and you'll never get that with textures. The texture mapping we are using today is done with the function in simgear/texcoord.cxx. I supposed you've read the explanation of how it's done in msfs on the fsinsider site, the problem I see here is that we do not have a regular mesh grid so we will have the boundary triangles that will span on several textures. In msfs they have a regular grid (it's just a height map) so the mapping is direct. HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Sebastian Bechtold wrote: >> >> >Hello Heiko, > >I don't want to throw away the material information which >defines things like the bumpines. As I've tried to explain, I would >like to do the whole thing as uninvasive as possible. >I'm pretty aware of the fact that as an absolute newbie here, >I'm not in a position that allows me to change or break existing >stuff. > >Thus, my plan is not to do so. > >All I want to do is implementing an alternative system for >how textures are applied to the terrain triangles. You won't >lose the ground properties (friction, bumpiness etc.) defined >by the materials with that, since they are defined independent >of the textures. Triangles with the material "road" will still >behave like roads, but my plan would, for example, make it possible >to render markings onto them, or draw softly rounded curves. >Both things are not possible with the current method (at least >not without throwing millions of additional triangles at the problem >and regenerate the terrain mesh to apply each and every change). > >My envisioned ideal solution would make it possible to toggle this >feature with a command line parameter or config file entry. If you >don't want it, just don't enable it, and you'll get exactly the same >thing as you get right now. I don't yet know enough about how >the program works to appreciate if this is possible (for me) or not, >but at the moment, I don't see a serious show stopper. I hope I made >this more clear now. > >With best regards, > >Sebastian > > Your thread title is misleading, what you really want to do is to add layers, so to add some geometry drapped around the terrain. I've started to generate geometry from airport nodes to generate taxiways some time ago but did not have time to work a lot on that recently. Once you have the geometry of whatever you want this should be renderable with an adequat polygon offset. HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] win32 FG Bugs in PLIB and OSG Plus former FG Versions!
Forums Virgin Net wrote:
>
> EDITED - Dr Watson Crash dump reports -
>
> Application exception occurred:
> App: C:\Program Files\FlightGear\binplib\FlightGear.exe (pid=948)
> When: 27/05/2007 @ 17:24:18.250
> Exception number: c094 (divide by zero)
>
In cloudfield.cxx :
int SGCloudField::get_CacheResolution(void) {
#if 0
return cacheResolution;
#endif
return 0;
}
delete the #if #endif
HJ.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] osgviewer version
Hi, Yesterday I made a build of the osg version of fg, last time I made one was like two month ago so I had to do a few experimentation to have a osg build that works with fg. When that was finaly working I realized that I had to add two defines for the osgviewer version of fg and tried a new build to see what it gives. Ok, apparently I'm the first to build that on a windows system. Here's the problems I can see : - fg_os_osgviewer.cxx does not build because the min & max macro are defined in windows.h and redefined as templates in some vec.h file, adding #undef min/max allowed to compile ; - the game starts in 800x600 for no reason ; - I can not click on the user interface (menu, dialogs) ; - changing the view with the mouse does not work as expected, the view direction is not controlable if not random ; - fginput::dokey says key value out of range. Then when I applied the last patch to fg_os_osgviwer.cxx I simply had compile errors because my osg version was not up to date. As I said on irc I'm not going to update osg each time I need to update fg. HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Mathias Fröhlich wrote: >Hi, > >Hi, > >On Saturday 26 May 2007, Nick Warne wrote: > > >>I decided to start a new clean thread here, so people can find what they >>need to build FG to perform. >> >>As we know, using the CMAKE command: >> >>cmake -i . >> >>produces a question/answer type script so you can build as a 'Release' and >>configure any optimisations to suit. >> >>Using: >> >>./configure CXXFLAGS= -O3 ... >> >>will build Simgear/FG with similar optimisations. >> >> >>Today I tested again OSG, and there are two options that made me wonder - >>so I turned ON to use a float matrix rather than double: >> >>//Set to ON to build OpenSceneGraph with float matrix instead of >>// double. >>OSG_USE_FLOAT_MATRIX:BOOL=ON >> >>//Set to ON to build OpenSceneGraph with float matrix instead of >>// double. >>OSG_USE_FLOAT_PLANE:BOOL=ON >> >> >That is bad idea. >That clamps the available precision of the transform matrices to floats which >is no longer enough. > >Are you on win32? > >Greetings > > Mathias > > > Are we talking about the matrices used for the culling and the rendering ? If that's the case then we don't need precision for culling and the gpu does nothing with doubles, they have allready some trouble to use floats efficiently. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] electrical system patch
Martin Spott wrote: >Hi Harald, > > > >I still don't understand why it should be required to initialize these >values to -0.01 instead of 0.0. If power switches are off, then 0.0 is >the correct value "by definition" (TM). If some conditional statement >doesn't handle this, then probably the conditional should be work >differently instead initializing some valued with, well, 'irritating' >values. > > The statment should be if ( volts > node->get_volts() || !node->is_initialized) but I don't find that simpler or easier to read. >Certainly, one year later someone writes a different routine and >expects the voltage to be 0.0 if the switches are off and would >be terribly annoyed if he had to deal with this workaround. > > But the whole point of this patch is to have *0.0* volts. We do not have 0.0 volts today, we have 24 volts. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures, random thoughts
Pigeon wrote: >Hi all, > > >One thing I'd really like to see, possibly for this upcoming 0.9.11 >release, is the ability to select to use Textures.high or not. By not >using Textures.high FG could perform much better on a lot of display >cards I've seen (rather old test, but still apply to current FG I think: >http://pigeond.net/flightgear/tests/fgfs-test-ati-20061015.html). > > Hmm, you should not say a lot of cards because in your test you are using an antediluvian gpu and I think that with even an fx5200 you could have your 40 fps with high resolution texture. >While, telling people to move away or rename the directory is rather >dumb. > > >How many people would agree we can have a command argument to turn >on/off the use of Textures.high? > > Since i'm not using a nix os I thing that a command line option without some way to click the option in a gui is dumb too. There is no way the user can know this option. > >I have a very brief look in the code and it should be pretty easy to >be selected at startup time. Probably one extra constructor argument to >SGMaterialLib and SGMaterial would do it. > > >The harder part might be making this switchable on the fly. Can't >say I know the code enough to say if there's a way to flush and reload >all the textures. And I don't know how useful this switchable feature >would be. > > Not sure it's really needed, but if that was possible we could change season texture on the fly too. > >On the other hand, is there any good textures management method? > >For example, rather than enabling/disabling Textures.high, is there >a way to pre-scaled down a texture before it is loaded/used? > > Glut has a function to rescale a texture but this can not be used with the plib architecture. Plib load the file and feed opengl with the data, there is no callback system to alter the texture between the two actions. This is something that could be implemented in the osg branch (and btw we should do this because using the default filterig to generate instrument texture is very bad). >Or, is there a way to for the user to set a memory limit for >textures? > > > No, and there is no absolut memory limit in the graphic card ; The driver is allredy handling the swapping of textures so there is no need to do this by hand. Harald. Btw the osg branch has texture compression so you shoud have better performance with it. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] electrical system patch
Martin Spott wrote:
>Why is setting to 0.0 not sufficient to reach the desired goal ?
>
> Martin.
>
>
This lines only initialize the internal values of the electrical system.
The properties are set in the propagate function :
// publish values to specified properties
for ( i = 0; i < node->get_num_props(); ++i ) {
fgSetFloat( node->get_prop(i).c_str(), node->get_volts() );
}
But this is only done if :
// if this node has found a stronger power source, update the
// value and propagate to all children
if ( volts > node->get_volts() ) {
node->set_volts( volts );
So with the power switches off we have volts == 0 and we never enter the
if statement and the properies stay with their old content.
Harald.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] electrical system patch
Hi,
this patch will propagate zero volt to the output properties
when...there is no current at all.
Atm if you switch all inputs off (alt & bat switches) you still have 24v
at the outputs.
Harald.
Index: electrical.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Systems/electrical.cxx,v
retrieving revision 1.35.2.1
diff -u -r1.35.2.1 electrical.cxx
--- electrical.cxx 11 May 2007 18:00:05 - 1.35.2.1
+++ electrical.cxx 19 May 2007 09:19:22 -
@@ -428,16 +428,16 @@
// zero out the voltage before we start, but don't clear the
// requested load values.
for ( i = 0; i < suppliers.size(); ++i ) {
-suppliers[i]->set_volts( 0.0 );
+suppliers[i]->set_volts( -0.01 );
}
for ( i = 0; i < buses.size(); ++i ) {
-buses[i]->set_volts( 0.0 );
+buses[i]->set_volts( -0.01 );
}
for ( i = 0; i < outputs.size(); ++i ) {
-outputs[i]->set_volts( 0.0 );
+outputs[i]->set_volts( -0.01 );
}
for ( i = 0; i < connectors.size(); ++i ) {
-connectors[i]->set_volts( 0.0 );
+connectors[i]->set_volts( -0.01 );
}
// for each "external" supplier, propagate the electrical current
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --enable-ai-models and --multiplay
Maik Justus wrote: >Hi, > >if you look into the forum or read the IRC and even the mailing list, >you get aware, that many new users are not able to start the multiplayer >option, due to a missing --enable-ai-models option. And probably much >more potential players fail at this point and don't ask and don't try to >use flightgear anymore. >Therefore I vote for: >- setting of enable-ai-models automaticalli, if a multiplayer option is >enabled in all the flightgear launchers >- activating of enable-ai-models in flightgear if a mutliplayer option >is given (and maybe generating a warning message, that -enable-ai-models >is added automatically). > >and to make the usage of multiplayer more easy: >- predefining of all multiplayer options in the launchers, that you can >enable the multiplayer option by one mouse click. > >What's your opinion? > >Maik > > We have AI without MP, so AI must be enabled by default. Also the nimitz demo must be enabled by default too. There is no reason to disable it (and those who don't want it know how to do it). Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osg material animaton
Tim Moore wrote: >You can't set the render bin, but you can set any other attribute or >mode in the StateSet. If that causes the StateSet to change its opacity, >well, that's a problem. > > > There is no reason to dynamicaly change the renderbin, if the object can be transparent then it will be in the transparent bin since the begining (the author just need to set an alpha < 1.0). On the other hand we have a lot of objects that are in the transparent bin for no reason. We need a pseudo animation to put them in another bin (after the opaque one and before the transparent one). Thoses objects are using a texture with an alpha *mask*. They are *not* transparent. They have nothing to do in the transparent bin because they are ruining the perf and at the end they will make the depth sort fail (exemple:radio mast texture, tree texture, some aircraft texture). Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch for osgViewer and statistics
gh.robin wrote: >Hello Tim, > >I spite of a very low fps with osg 1.9.4 (as i said before) i have built FG >with that patch, which works perfectly (but the cursor change, you are >working on it). > >How may we understand the values which are given >Event >Update >Cull >Draw >Gpu > >Are they percentage of use , or anything else ? > >The "Cull" is basically very high compared to the other values but when i fly >over the sea (without tiles as i said in an other topic). >What is exactly the meaning of the "Cull" value ? > >I get ThreadingModel : SingleThreaded , is it right ? > >Here a snapshot of the Stats http://perso.orange.fr/GRTux/OSG-Stat.jpg > >Regards > > > > The numbers is the time in miliseconds, Event is I think the time for the non osg code, update, cull and draw are the time for the osg calls ; update is for the animation code, Cull is for the culling objects not visible, Draw does the rendering sort and then the calls to opengl. Gpu is the time used by the gpu only. Event+update+cull+draw+a bit of gpu gives your total frame time. The cull time is enormous but this should be better soon. But your draw time is astronomous too. I can not comment on that with only a screen shot. What we need now is the number of drawelement calls, I'm sure Time will add this ;) Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-0.9.11-pre1 (source code) available for download and testing
Stuart Buchanan wrote: >Could I make a slighly impolite request? > >Thanks to Olaf's work I have a working OSG build system for windows, but >not plib, despite much work. I've heard that the flash2a model doesn't >work on plib, but I've been unable to fix this as I don't have a plib >executable. > >Could some kind soul create a windows plib binary for me please, or >alternatively take a look at the problem on my behalf? > >Otherwise, I think it will have to be pulled from the release, which would >be a shame. > >Thanks > >-Stuart > > Try that http://sites.estvideo.net/tipunch/flightgear/fgfs-1505-special-debug-71.zip but it's not 0.9.11 Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Vivian Meazza wrote: >Harald > > > >>Sent: 13 May 2007 18:19 >>To: FlightGear developers discussions >>Subject: Re: [Flightgear-devel] More ideas on dogfighting >> >> >>Ampere K. Hardraade wrote: >> >> >> >>> >>> >>If the server does the fdm 100 times per second and send the data 10 >>times per second it's like if the client was running the fdm >>at 10 hz. >>That's why I said it's not needed to run the fdm at more than 10 hz >>(those numbers are just examples). >> >> >> >>>Since the FDM takes so little CPU power, the amount clients >>> >>> >>that can be >> >> >>>served >>>should be dependent on the bandwidth. >>> >>> >>> > >I suppose that we run the fdm at 120Hz for a good reason: why could we >suddenly accept 10Hz? > >Vivian > > > That was in the situation where the MP server does the fdm computation for the client. The 10 hz comes from a ping of 100 ms between the client and the server. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Ampere K. Hardraade wrote: >On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote: > > >>Now if the server is doing the >>FDM computation it's obvious that there is no need to do that 120 times >>per second because the data can not be send at that rate. >>How many loops does the mp server need to do per second ? 10 ? 20 ? At >>that frequency you could handle 100 clients with no problems. >> >>Harald. >> >> > >As far as I know, the FDM frequency controls the fidelity of the simulation. >It has no relationship with the I/O frequency. > > If the server does the fdm 100 times per second and send the data 10 times per second it's like if the client was running the fdm at 10 hz. That's why I said it's not needed to run the fdm at more than 10 hz (those numbers are just examples). >Since the FDM takes so little CPU power, the amount clients that can be served >should be dependent on the bandwidth. > >Ampere > > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Martin Spott wrote: >Hi Jim, > >Jim Campbell wrote: > > > >>Some discussions have already taken place on JSBsim devel mailing list >>regards communication between "modules" of flightgear. >> >> > >Indeed, the idea of cutting FlightGear into modules is not a new one >and has been floating around way before this nice "new arcitecture" >paper came up that everybody takes as a reference. > >Using some sort of networked database is a nice start and definitely >honours the idea of portability - yet I don't see such thing that is >capable of handling data at a rate that meets the requirements of >FlightGear. OpenLDAP as well as MySQL are very bad at handling a high >rate of concurrent read/write requests - they miss the target by a huge >distance, they both are faaar to complex (even MySQL :-) for such a >task. > >Personally I think some thing like distributed shared memory might fill >the gap. I've been doing some literature research on this topic several >years ago, the idea looks pretty promising and different OpenSource >implementations already have been around by that time - but I would not >like to be the one to debug such a tricky beast :-) > >Cheers, > Martin. > > One should not forget that FG has allready some networking capacity. This alone has allready allowed ppl to split fdm and rendering on several machines. Perhaps there is something to reuse here. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Bill Galbraith wrote: > > > > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On >>Behalf Of Stefan Seifert >>Sent: Saturday, May 12, 2007 10:38 PM >>To: FlightGear developers discussions >>Subject: Re: [Flightgear-devel] More ideas on dogfighting >> >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA1 >> >>James Palmer wrote: >> >> >> >>>In your experience, Harald, what has been the approximate >>> >>> >>ratio of FDM >> >> >>>vs Graphics vs remainder code on CPU time? Has anyone done work on >>>clocking the various subroutines in FG to determine this? >>> >>> >>(Perhaps I >> >> >>>underestimate the CPU time required of the FDM?) >>> >>> >>You could simply run stand-alone JSBSim >>(http://www.jsbsim.org) to see, how much CPU a FDM needs. I'd >>guess that Yasim lies in the same range. >> >>Nine >> >> > > >I think that was investigated a few months ago. JSBSim FDM took only a >couple percent of the CPU, or course depending on your hardware and what you >were drawing. I don't think it's anything that you need to worry about. > >BIll > > > I don't have fresh number but the time of a standalone JSBSim takes has nothing to do with the time the FDM takes in FG. First it depends on how many times you run it per second (in FG the default is 120 Hz). Second in addition to the fdm itself we are computing some ground intersection. And since the world geometry is very badly organized in FG this can take some non negligeable time (but we should see a great improvment in the intersection code with the osg branch). Now if the server is doing the FDM computation it's obvious that there is no need to do that 120 times per second because the data can not be send at that rate. How many loops does the mp server need to do per second ? 10 ? 20 ? At that frequency you could handle 100 clients with no problems. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
James Palmer wrote:
> Server Coordination:
> Some discussion on how to coordinate AI-Ballistic and AI-missile (yet
> to be created) with players was had yesterday.
> Basic Problem: Jet A is travelling at mach 2 and he has a slow
> Internet connection (200ms latency). Jet B is approaching him from a
> direct right angle (i.e. Jet A will exactly cross Jet B's gun sight
> very shortly) When Jet A's pilot realizes that he is about to be
> toast, he makes a hard turn, but at mach 2 he will travel
> approximately 450 feet before his slow packet reaches the server.
> This is a very simplified example, but it gets the point across. I
> need to figure out the best way to minimize the effects of Jet A's
> latency and determine the best method of position coordination between
> players.
>
> Suggested Solution #1 - DFMP is server driven and server coordinated:
> The dogfighting MP (DFMP) should be server driven (thanks to Lethe for
> the insight into this direction) and server coordinated. Clients
> should send user input information to the server and let the server
> calculate where the player is on the earth and inform the player of
> it. The server would also be responsible for determining whether a
> collision has occured. This is the approach taken by many of todays
> MP Internet games.
Note that in those games there is no client side to compute position,
etc, and in mono player mode the server is run on the client computer.
Since it's allways the server that do the computations the games react
the same wether you are in mono or multi player.
> Changes for this approach include :
> 1-an overhaul of the MP protocol. Currently users send a UDP message
> on their position to the server which then updates the other players
> AI-Aircraft models (I think I understand this correctly,.. if not
> someone please chime in). Clients would now have to send user input
> information to the server. The server would have to model the FDM of
> the craft they are using, determine its new position and then update
> the client and other DFMP players on the clients new location. These
> calculations and updates would happen for every DFMP there is on the
> server.
> 2 - a change in the client side of MP protocol to send only user
> input, and to accept new positions from the server that is driving.
> 3 - the server would need additional collision detection ("hit-box"
> relative to the size of the craft flown)
You realize that you need to compute intersections with the terrain too
(for the fdm and other objects that you launch).
>
>
> Suggested Solution #2 - DFMP is client driven and server coordinated:
> The DFMP should be client driven and server coordinated. Clients
> would be responsible for calculating their own FDM and position on the
> earth. Each client would send its position information to the server,
> which would maintain a list of aircraft and AI positions. The server
> would only be responsible for passing position information to all
> players and determining whether a collision has occurred. To further
> reduce the effects of latency, vector extrapolation may be used to
> determine a player's position when no new information packet has arrived.
Extrapolation is done in the two scenario because knowing the real
position of things is a special case (your sims run at 50 hz and the
server send packet at 5 hz for example).
> Changes for this approach include :
> 1- Adding AI objects to the MP protocol so that gun and missile
> information can be transferred.
*Every* AI objects must be sent on the network ; aircrafts and missiles
are just one of them. On a mp server the world must be synced, a carrier
must be at the same position on all client. If I open a hangar door on
my client it must be opened on all client computer.
> 2 - the server would need additional collision detection ("hit-box"
> relative to the size of the craft flown)
If the server computes all collisions then you need the terrain too. Or
the server computes what he can and the clients compute the ground
collision and give confirmation of objects collisions between them.
>
> Cutting down the information needed for DFMP
> I've been trying to think of some methods to cut down the network
> traffic required, by allowing the client to do some of the heavy
> lifting. Here are some ideas I have.
> ...
> Problems with this approach: Since the protocol is UDP, if the BO
> initiation packet is lost, then either the server or Jet B may never
> know of the object. (depending on which packet is lost)
> Switching to TCP would solve this, but that opens up a can of worms
> I'd rather not deal with. (anyone want to help out on this?)
Jet B will see the object the next time the object position is updated
by the server so it should not be a real problem. And if we are in the
second scenario then the client A is updating the position so the server
will see the object soon enought.
>
> --
> Ja
Re: [Flightgear-devel] Radar improvement
Martin Spott wrote: >"Vivian Meazza" wrote: > > > >>I discussed the improved radar with Melchior, he is very reluctant to >>include it because it is plib only. >> >> > >Well, personally I'd agree with him on that one, > Martin. > > The next fg version is a version based on plib and will be the official version for at least one year. Do you think that it's not worth to add new things that will be used for a so long period ? Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] LANDING LIGHTS
Simulador wrote: >Hi Stewart, > >I am sorry for the delay, I posted this email 2 weeks ago and I thought >I had answered you. > >I am working on a Full Flight Simulator that was manufactured in 1976, >it is a Boeing 707-341. > >The HOST computer was a R2000, it was a 24 bit machine with 64 K words >of memory. We did replace the R2000 computer for a LINUX based PC with a >emulator. > >The Visual System is a NOVOVEW 2500, it was developed by Evans and >Sutherland, and the computer is a Texas Instrument TI980 computer ( 16 >bit x 16 K words). > >I was testing FLIGHT GEAR as a VISUAL SYSTEM replacement for this >simulator, but I should have control over the exterior AIRCRAFT LIGHTS. > >Is there any plans to develop this functionality to Flight Gear on a >short term? > >Please take a look at http://707simulator.multiply.com > >Regards, > >Carlos > >Stewart Andreason wrote: > > > I can not talk for the others but I won't work on that for the plib version (ie on a short term). The osg implementation is done in a few hours with multutexturing with a cube map and a two pass rendering. And then a preliminary work is to spatialize the scene graph so that the second render pass is only done around the spot light to minimize the hit on fps. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osg material animaton
Melchior FRANZ wrote: >* Tim Moore -- Tuesday 08 May 2007: > > >>I think it's reasonable to require that all the >>colors in a material animation be specified; modelers might disagree :) >> >> > >It's unacceptable. An typical emission animation looks now like this: > > > material > instrument-face > > controls/lighting/instruments-norm > 0.5 > 0.2 > 0.2 > > > >And you find it reasonable to extend that to 40 lines? This sounds like >letting the aircraft developer do what the code(r) is too lazy to do. >Then better drop the whole "material" animation, and just say "it can >no longer work". > >m. > > > We can surely subclass the osg::Material class and handle that a la plib with the 'dont_care' flag to apply only the needed change. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osg material animaton
Tim Moore wrote: > > >>To recap we have (or should have in the future) : >>- one drawable per model / part of model >>- one texture per texture loaded >>- one state per static / animation material >>- adding a 'model' will add a geode with a new state pointing to a >>cached texture and to a cached drawable >> >> >There's no reason not to share the geode too. >Also, you really want to share StateSets if possible, because OSG will >order all the drawables by StateSet to avoid state changes, but it >doesn't look inside StateSets to minimize state changes. > > Yes by states I was thinking of statesets. Anyway I looked again the geode and drawable definitions and now I'm confused, I thought the states were tied to the geodes but they are tied to the drawable. I really don't understand how we can have one drawable with several states. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osg material animaton
Mathias Fröhlich wrote: >Tim, > >On Saturday 05 May 2007, Tim Moore wrote: > > >>The attached patch fixes material animations (color in particular) in >>osg. I also notice a big frame rate increase with aircraft that use >>material animations. >> >> >Applied thanks! > >Comments to that: >This one will only work like expected for the current ac loader in current osg >svn. >Can you think of a scheme that does not rely on that assumptions? >May be we have to adjust the way material animations can be configured a >slight bit to remove these dependencies? > >There is also a second assumption in the animation system: The textures for >the liveries are expected not to be in the osg::Drawables. That is not always >true and is especially no longer true with the ac loader update in osg svn >since a few days. > >The problem that is fixed here, which is also in the past and current material >animation to some degree, is that render bin numbers in osg build >hierarchical render bins. That means we should only put render bin numbers at >drawables or on nodes that have well known leafs. >With that change the transparencies are handled way better with osg. > >Ok, back to the model stuff. >I want to share drawables across all loaded models since the drawables own >display lists and thus should only appear at one time in the GPU memory. Even >if the same model is loaded multiple times (think of AI traffic). The same >clearly holds for texture state attributes attached to several state sets. > >So my intention is to come up with a 'model scenegraph normalization scheme' >that fits all those needs: >Share GPU and memory intensive data structures. >Have a known structure how relevant states are distributed on different nodes >so that we can make some assumptions in the animations. >Ideas? > > Greetings > > Mathias > > To recap we have (or should have in the future) : - one drawable per model / part of model - one texture per texture loaded - one state per static / animation material - adding a 'model' will add a geode with a new state pointing to a cached texture and to a cached drawable - animation material can be shared by several geodes (by animation material I mean any animation that can alter the state, not the one we have atm). Is this correct ? Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] chrome shader for fg/osg
Vivian Meazza wrote: > > >I was looking at the Fresnel shader in plib recently - I couldn't seem to >make it do anything - is there a texture it needs somewhere? > >Vivian > > > Oh that's embarassing, when I look at the code the effect is clearly disabled, perhaps I forgot to send a patch one day ; I'll check that next week end. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] chrome shader for fg/osg
Heiko Schulz wrote: >Hi, > >Fine to see, that things come back to good! ;-) > >But I am a very little dissapointed that the chrome >shader isn't broken anymore: the broken shader made a >very good "glas shader". > >You can see ist her on a developement pic: >http://hoerbird.ho.funpic.de/bilder/flightgear/fgfs-screen-231.jpg >with faked "glas shader" and here >without:http://hoerbird.ho.funpic.de/bilder/flightgear/fgfs-screen-145.jpg. > >I hope to get something like a glas shader soon, >because "glas" doesen't look good in the moment in >FlightGear. > >Greetings >HHS >--- AJ MacLeod <[EMAIL PROTECTED]> >schrieb: > > Try the fresnel shader, it should give you exactly that effect (with plib). It should be easy to do for Tim for the osg branch. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] framerate hesitations...
Syd & Sandy wrote: >Hi all , >Not sure how to describe this , I get a barely visible hesitation in >framerates while flying, about once a second . Noticed it in the >Aerostar , so I suspected my Nasal electrical routine was causing it > but after changing the loop timing it didnt seem to match >Running with log-level = info , it appears to closely match the >refreshing timestamp message , but not entirely positive yet... >Just wondering if anyone else has noticed this ? >I tried a few other aircraft , and didnt notice it as much , so I'll >keep hunting . >Cheers, >Syd > > Bumping an old thread... I used the ufo above some water with nothing in range, only a 2d cloud layer to have a visual reference, zero speed, turning left on myself. The animation is supposed to be smooth and it is not. There is clearly a pause from time to time ; all that is easily disabled is off (ai, atc, random object, replay). log level = info does not give any clue because the only messages that appear is the timestamp refresh one and the scheduling of tiles and those messages are not synced with the pause. Note that the fps does not really vary at that point, still around 85 but the pause is clearly noticeable. After some time, it appears clearly that the frequency of the pause is lower, and the duration of the pause is higher, also the strange thing is that the pause overlaps above a few frame. At some point I had the pause every 40 seconds and the slowdown was lasting for like 5 seconds ; even if the fps was not allways droping a lot the pause was clearly noticeable. Well the fps is averaged so at the begining of the test I was losing like 5 fps and at the end 40 during the pause. But the fps is far from the truth and the sim is simply not usable (I was not out of memory so no swapping, even if the sim is clearly using more and more memory). I did not discover anything concrete ; while I was suspecting code runing on a timer I don't understant how the pause can overlap on a 5 second period. I disabled the nasal code runing on timer and there is no difference. The only thing that is synced with the end of the pause is the Nasal gc, and this one 'only' use 250 ms at that point of the test. To be continued Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Anisotropic Filtering for Runways
Olaf Flebbe wrote: >I did the materials approach because I didn't want to harm older graphic >cards too much. But since most of the posters like to have a global >control I see no point in applying it only to certain materials for now. > >Right now I am hacking the Rendering Options panel. > >Olaf > > > > In fgIdleFunction(), this line glTexEnvf( GL_TEXTURE_FILTER_CONTROL_EXT, GL_TEXTURE_LOD_BIAS_EXT, -0.5 ) ; should be disabled when we use anisotropic filtering (because it becomes useless and because in all cases it ruins the mipmaping of buildings walls). Also since the anisotropic filter parameter must be applied to each textures (and it's hard to do that if we don't have a list of existing textures), you can rememder the user that the option will only be applied on the next launch of FG. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Anisotropic Filtering for Runways
Olaf Flebbe wrote: > Hi, > > I had the chance to get a small lecture on OSG. I tried out > anisotropic filtering for improving the look of the runways. IMHO the > result is amazing. > > Compare yourself -- have a look the markings on the runway: > > http://www.oflebbe.de/oflebbe/FlightGear/withoutfilter.jpg > > http://www.oflebbe.de/oflebbe/FlightGear/with8filter.jpg > > Without any drop in framerate ... > Can we have a boolean in material.xml (true for runways) and the value in some property ? This way we can disable it or set the value for the filtering level on the command line. Because you can not hard code '8', this will give very different fps depending on the hardware. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] framerate hesitations...
Syd & Sandy wrote: >gh.robin wrote: > > >>Jeff is right, i noticed that problem a loong time ago, >> >>And never got any answer. >> >>I have solved it with running fgmap on a separate computer >> >>Regards. >> >> >> > >I get this with varying degrees from different aircraft , with nothing >else running , AI / Traffic and MP disabled , but its not consistant >enough to find the problem easily... >I also noticed long ago , but spend more time fixing than flying and >forgot about it I also noticed it affects both PLIB and OSG versions... >Cheers, >Syd > > > > > Disable autogen and check if it's the same. Use the ufo and check again. Go away from any airport and check again. Clean the nasal directory and check again ;) Harald. - 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] framerate hesitations...
Curtis Olson wrote: > > > It is possible to make threaded model loaders, but now you are faced > with the task of completely re-writing the OSG or PLIB model loaders > so they play nice in a threaded environment in the context of our > application. You have to make sure that all the opengl calls are > serialized in the correct order so they don't step on each other and > cause an application crash. > > Anything is possible, but some things are very hard. > > Curt. > osg loaders are supposed to be thread safe now because they are used in their multi thread page loader. Note that contrary to plib, the textures are not bound when loaded but only when rendered the first time. So in theory there should be no ogl calls inside a loader. We shoud be able to run a bigger part of our loader code in a sperate thread and with very few change to the existing code. Of course this won't solve the 100k poly model case. Harald. - 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] crash with route manager dialog
Melchior FRANZ wrote: >* Harald JOHNSEN -- Saturday 31 March 2007: > > >>I set KLAX in the next waypoint and keep the dialog open ; >>I can see garbage in the target, dist, and eta fields one image every >>two image and correct value the other image. >> >> > >Works here. No garbage, no crash. Starting with the ufo from ksfo, >with only waypoint setting klax. Flew to klax with open dialog. > > > > > >>Only plib is not up to date. >> >> > >I'm using plib from svn/head, and my fgfs is patched to fully use >it, bypassing the puList.cxx copy in the fgfs sources. (I'd like >to commit that, but first we'd have to make 1.8.5rc1 a dependency.) > >Anyone else seeing the problem? Maybe even on Linux -- with useful >backtrace? > >m. > > > I've traced the values in copy_to_pui, they are ok, and bad in the format callback. If I understand well the code, the live values are updated when the gui subsystem is called (NewGUI::update()). Those values are stored in char *pointer (before the format call back), the problem as I see it is that those pointer won't be valid if the data they point to is updated. And I thing that's what is happening. The subsystem manager calls NewGui::update and then calls FGRouteMgr::update. The set_string method does a delete followed by a new so it's possible that the pointers are not the same. As a quick hack I changed the declaration of the route mgr subsystem (int fg_init.cxx) to globals->add_subsystem( "route-manager", new FGRouteMgr, SGSubsystemMgr::INIT ); putting it in the same group as the gui and before it. This seems to work. Harald. - 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] crash with route manager dialog
Hi, I set KLAX in the next waypoint and keep the dialog open ; I can see garbage in the target, dist, and eta fields one image every two image and correct value the other image. This leads to a crash after some time in dialoc.cxx:format_callback() ; at that point there is garbage in obj->getLabel(). Only plib is not up to date. Harald. - 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] New Nasal in CVS
Harald JOHNSEN wrote: >mathlib.c >f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(29) : error C2065: >'__func__' : identificateur non déclaré >f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(29) : warning >C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux >d'indirection >f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(38) : warning >C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux >d'indirection >f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(47) : warning >C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux >d'indirection >f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(56) : warning >C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux >d'indirection >f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(65) : warning >C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux >d'indirection >f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(75) : warning >C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux >d'indirection >lib.c >f:\dvlp\osgfg\SimGear\source\simgear\nasal\lib.c(25) : error C2065: >'__func__' : identificateur non déclaré > >// Toss a runtime error for any NaN or Inf values produced. Note that >// this assumes an IEEE 754 format. >#define VALIDATE(r) (valid(r.num) ? (r) : die(c, __func__+2)) > >Harald. > > > I've added this to the two file where func is used (seen on the interweb) /* Try to get a reasonable __func__ substitute in place. */ #if defined(_MSC_VER) /* MSVC compilers before VC7 don't have __func__ at all; later ones call it * __FUNCTION__. */ #if _MSC_VER < 1300 #define __func__ "???" #else #define __func__ __FUNCTION__ #endif #endif compiles ok, but link fails Some functions defined in thread-posix.c (and used) are not defined in thread-win32.c I've forced the use of thread-posix, compile and link is ok now. Harald. - 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] New Nasal in CVS
Andy Ross wrote: >A big heads up. I just updated the Nasal interpreter to sync it with >Nasal CVS: > > > >This almost certainly broke something, somewhere. Please be on the >lookout for anything that looks like it might be an interpreter bug or >new behavior. Likewise, let me know if any platform builds broke -- >at the very least, MSVC project files are going to need to be updated >for the new files. > >Andy > > >- >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 > > > -- Début de la génération : Projet : SimGear, Configuration : Debug Win32 -- Compilation... thread-win32.c string.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture parse.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture misc.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture mathlib.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture lib.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture lex.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture iolib.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture hash.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture gc.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture codegen.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture code.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture bitslib.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\naref.h(19) : fatal error C1189: #error : Unrecognized CPU architecture Génération de code en cours... Compilation en cours... vector.cxx Génération de code en cours... Does not compile on VC 7.1 adding || defined(WIN32) worked, then mathlib.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(29) : error C2065: '__func__' : identificateur non déclaré f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(29) : warning C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux d'indirection f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(38) : warning C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux d'indirection f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(47) : warning C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux d'indirection f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(56) : warning C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux d'indirection f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(65) : warning C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux d'indirection f:\dvlp\osgfg\SimGear\source\simgear\nasal\mathlib.c(75) : warning C4047: 'fonction' : 'const char *' diffère de 'int' dans les niveaux d'indirection lib.c f:\dvlp\osgfg\SimGear\source\simgear\nasal\lib.c(25) : error C2065: '__func__' : identificateur non déclaré // Toss a runtime error for any NaN or Inf values produced. Note that // this assumes an IEEE 754 format. #define VALIDATE(r) (valid(r.num) ? (r) : die(c, __func__+2)) Harald. - 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] simulating camera output during flight
Domenico Leonello wrote: >Hi, > >I'm an italian PhD student and i'm developing algorithms that use stereo >camera images sensor fusion to control helicopter UAVs. > >I already have a flight simulator (made using Simulink and an home-made >C S-function to model the helicopter flight dynamics). > >I would like to use FG to have a nice graphic interface but mainly to >have a realistic sourrounding for my helicopter. >I'm sure that it's possible to impose to a FG helicopter model positions >and euler angles calculated with an external engine (like mine) but i'm >not sure if it is possible to use run-time the rendered images >originated from a "view point"! I have the need to handle the images >run-time to elaborate them with vision algorithms and to evaluate the >controller response that pilots the helicopter. I see in the manual that >it's possible to save a movies during the flight for post-process >purpuse but it's not useful for my target because it's not run-time. >Does anybody know if it possible to do something similar I need? > >I'm a newbie using FG so I ask you sorry if this is a dumb question! >Thank for helping. > >Domenico > > > >- >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 > > > Perhaps you can try the jpeg server, send a request and grab the image directly. Start fg with --jpg-httpd=port, then you should get a screenshot in your browser, since it's a simple request you could code the http get request in you application, not sure if it's fast enought for realtime. Harald. - 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] Building under MSVC8
Gene Buckle wrote: Harald, with SimGear I just added explicit paths. This is not working for the FlightGear project. For example, my tree goes: FlightGear->FlightGear->source->?? ->SimGear->source->simgear When I explictly add an include: /FlightGear/SimGear/source, all the #include calls still fail to find the include files. g. It should work, I use the same path as you for SG inside the FG project ; my include path is ..\..\..\.. ..\..\src ..\..\src\include F:\dvlp\osgfg\SimGear\source ..\..\..\pthreads-w32-2-7-0-release ..\..\src\FDM\JSBSim ..\..\..\..\OpenSceneGraph\include ..\..\..\..\OpenThreads\include ..\..\..\..\3rdParty\include F:\dvlp\osgfg>dir Le volume dans le lecteur F s'appelle APPLI Le numéro de série du volume est 9000-2718 Répertoire de F:\dvlp\osgfg 04/03/2007 13:56 . 04/03/2007 13:56 .. 03/03/2007 12:34 3rdparty 04/03/2007 13:58 183 bugs.txt 03/03/2007 14:34 FlightGear 03/03/2007 12:35 OpenSceneGraph 03/03/2007 12:35 OpenThreads 04/03/2007 13:06 plib 03/03/2007 12:35 Producer 03/03/2007 13:00 SimGear 1 fichier(s) 183 octets 9 Rép(s) 22 964 031 488 octets libres F:\dvlp\osgfg\SimGear\source>dir /ad Le volume dans le lecteur F s'appelle APPLI Le numéro de série du volume est 9000-2718 Répertoire de F:\dvlp\osgfg\SimGear\source 16/03/2007 18:58 . 16/03/2007 18:58 .. 16/03/2007 18:58 CVS 03/03/2007 13:00 projects 16/03/2007 18:58 simgear 0 fichier(s)0 octets 5 Rép(s) 22 964 031 488 octets libres Hope that helps. Harald. - 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] Building under MSVC8
Gene Buckle wrote: I'm not a windows user, but someone just reported success on the IRC this morning. Apparently, the VC8 project still references FlightGear \src\Instrumentation\annunciator.cxx and FlightGear\src\Instrumentation \annunciator.hxx which no longer exist. Ron, I haven't even gotten that far. :) It's still thrashing around trying to find header files in the simgear tree. :) I'll fiddle with it some more this weekend probably. g. Still using VC7 but now that you are talking about Simgear ; I found that the dir strcuture is not exactly what is it suposed to be (ie the one the project use and the one we can see on the picture on someone's page). Doing a checkout added a 'source' level in my SG and FG dir struct so I had to change the include path, I added '..' on nearly all path (anyway you can use absolute path if nothing else works) osgfg + 3rdparty + FlightGear ++ data ++ source <- one more level +++ src + OpenSceneGraph + OpenSceneThreads + plib + Producer + SimGear ++ source <- one more level +++ simgear +++ projects Hope that helps. Harald. - 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] no texture mipmaps ?
Hi, I've just built FG with with a fresh checkout and I have the impression that there is no mipmaping done for scenary objects. That was a quick fly with the ufo around ksfo so I could see that problem on buildings, bridges, etc. Or is there some osg env var to set ? Harald. - 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
