[Flightgear-devel] FMC
Would it work to have one node in the property tree that would contain the text on the CDU display ? The 3D cockpit could listen for changes to this node and when one happens, update the CDU display in the 3D cockpit... I like this idea, the text could be use for the FG cockpit or for some external CRT CDU. Except that the 3D cockpit can't handle text display atm. The 2D panel can. Using a dynamic - non library-based - approach, possibly utilizing Nasal for it, would probably be preferable if all the stuff is available within the Nasal scope, that way one could easily borrow fragments of code from other FMC implementations and add it to your own FMC. ... My first idea was to write everything in Nasal ;) But due to some limitations in FG I have decided to start with an external FMC. Once it start to work I'll see how to make a buildin version. We are talking of an FMC but of course I wanted to redo at least the ehsi display (for the eye candy). Now there is a few problems with 3D gauges : can't draw text, can't draw dynamic occurence of sprite/texture. Similar limitations with 2d gauges concerning the dynamic part. So I was thinking about draw to texture technique and some graphical api in Nasal to generate that kind of display... This would have delayed the ehsi too much. So, you'd mainly want to have access to all the relevant data, the first thing that comes to mind would be functions to interactively retrieve data from the navaids/airports file in order to deal with those value accordingly, I don't think that Nasal can already retrieve such data !? It's not difficult to add a few interfaces to acces this data. Even waypoints can allready be added just by touching the right property but the code in auto_gui.cxx is too restrictive about the type of wp one can insert. In order to really determine what data and functions to access it would be necessary, one would first need to look into a FMC manual and find out what data sources are being used to compute the stuff, OR what -flightgear based data- could ALTERNATIVELY be used for that purpose. FG has the needed databases for the routes (airports, runways, nav, airways). here, but actually there's still a bit more to it - which is probably easier to find if you really get your hand on a FMS (training) manual, actually that would be quite a sufficient source because you could design the whole FMS - page by page - after it. I am looking the web to find the information and I try to understand the different pages. Some are obvious, some not, I don't have a real manual. And of course I never used a real FMC. Another idea I just had: Why not put all the general algorithms needed in an average FMC into a library (possibly as part of SimGear). Things like performance calculations, (access to) route databases, input validation (eg: airport code exists?, does this airport have a runway xxR?),routing calculations,... This library could then be used/linked to build an FMC, either withing fgfs our as a standalone program. Sure, and the external version is allready using part of FG code, as is or modified. When we are more advanced in the project we will see where to put back all the adds. An approach like the one suggested by Jim would certainly have the potential to add many variations of FMCs simply because it would be mainly a thing of specifying the appeareance and logics using a XML file with some Nasal code. Right. Or... how about implementing it outside of flightgear at first and then hooking it in when the code is somewhat stable? Yes. Maybe Harald can provide some more details about what he want to take into consideration and if there are any things that weren't yet mentioned in that thread. Thanks for the feedback. Concerning the implementation of the fmc I will continue with the external version for now because I think it's the one that can be ready the first in time. As I said before I don't have all the knowledge to build it enterely by myself so I will need a lot of feedback at the beginning (the fonctions of the fmc but also the look and feel). The gui (with skins) and the ability to build new looks/functionalities with XML config and nasal code is a great idea. I talked a bit about the ehsi allready, I don't know how to enhance the one in FG without using opengl code. Harald. ps: I hope you can read me, english is not my first tongue. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FMC
We are talking of an FMC but of course I wanted to redo at least the ehsi display (for the eye candy). Erik mentioned some time ago that it isn't yet really possible to do simple animations using Nasal in FlightGear, at least that's what Andy indicated when he was asked about that, I think. I remember but I had the impression that they were afraid for the performance. This would have delayed the ehsi too much. is there really that much lag involved when doing such things using Nasal - i.e. NO smooth animations ? I was not clear. I was saying that to do the ehsi I would have to wait for the implementation of some new graphic code. Concerning smooth animations, I think it can be the same as current instruments. Now let me open a little parenthesis about a reflexion I had some times ago. We have a caneva to build 2d and 3d instruments and its doing the job fine for a wide variety of gauges. But even if can extend those fonctionalities there will always be some cases that can't be handled. Lets call them owner draw gauges. How to draw them ? With pure opengl code in C. This is the first bottleneck. It seems stupid the have to build Flightgear to use a new gauge when someone release a new panel or new plane. The other thing that disturb me is that this OD gauge should of course work on a 2d and on a 3d panel. Let me remind you : a 2D gauge is a stack of layers (textures), a 3d gauge is a 3D gemoetry object (textured). If we use only one texture for both the 2d and 3d gauge we have a texture that can be used for both instruments. So this is my suggestion to have compatible 2d/3d specials gauges, ie they both refer to the same texture, this texture is generated by some special code (drawing to texture/pbuffer is something standard for 3d cards). Now how do we draw in this texture ? In Nasal of course, with the appropriate graphic library. Not a pseudo opengl library because there is no more than perhaps 10 api to implement : draw a line, draw text, draw a texture, etc. I am prety sure we can pair this api to the existing draw code. What about the performance ? Imagine a simple gauge with a background and a needle. This could be drawn with 3 lines of Nasal code: DrawTexture(background, x,y), Rotate(angle), Drawtexture(nnedle, x,y) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FMC
Last mail was cut... What about the performance ? Imagine a simple gauge with a background and a needle. This could be drawn with 3 lines of Nasal code: DrawTexture(background, x,y), Rotate(angle), Drawtexture(nnedle, x,y) So it can't be slower than xml gauges. And more complex gauges ? This is were draw to texture is handy. There is no need to generate the texture every frame. Some instruments need to be refreshed every 1/10 of second, perhaps a radar could use a refresh of half a second, and a moving map a refresh every second (or less). Now the xml gauges wont refer to a texture loaded from a file but to this generated texture. Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FG Launcher and the airports
The launcher only lists airports that are present in your installed scenaries. I think your problem is in your scenary path on the first tab of the launcher (FG_SCENERY field). You shoulf have something like /FlightGear/data/SceneryTerrain. Then press refresh on the airport page. Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Bypass FG Physics and Draw
[EMAIL PROTECTED] wrote: Does this mean that we would have the ability to save and load flight data so as to reproduce, say, a taxi, take off, pattern and landing at KSFO or another airport automatically (i.e., as a demo or as a training exercise). Perhaps a short flight around the SF area also showing off the new scenery? Could we ship such flights around scenic areas (Mount Ranier, Crater Lake, the Grand Canyon) for new users in the base package or as downloadables off of flightgear.org? How big would such files be? How much data needs to be kept, how much can be calculated on the fly? Do weather conditions need to be saved also? Would flights around scenic areas be done better as flight plans with waypoints or tied into this new playback method somehow? Can this playback tool be used as a training method for new simulator pilots? If we are not saving a real recorded flight, perhaps we can use a similar method to extract either entire flights or the last XX number of seconds of a flight to save to disk for later replay? MS FlightSimulator has an extensive tutorial that involves pre-saved flights which the users can break into at certain points in the flights. How difficult would it be to add something similar to FG and where would one begin (if no one is already working on something like this). Thanks! Ima ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I think that the ability to play a flight recorded by an external source is different from the ability to save/load a flight from FG. In other words, I don't think we should save any state variable - ie parts of totality of the property tree. We have an initial state when FG is launched with a specific set of parameters. Now how do you fly ? You use your joystick, mouse, keyboard et al to interact with the simulator. So a recorded fligth could be defined as a list of user interactions paired with a time stamp, and to be more accurate a very limited set of properties could be added lets say every 10 or 20 seconds (position, heading, etc). The advantage would be : - short record file size - accurate property tree because the simultor would run exactly with the same imputs - easy to implement because it is not tied to the internals of the simulator (like fdm). Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
martin pardee wrote: folks: i''d like to offer my (bleated) thanks to curtis olson, john wojnaroski and manuel bessler for taking the time to respond to yet another newbie. i've received some good pointers from you all. it looks as if there are several approaches i could take to interfacing a stack of simulated radios to the FG sim. i guess i'm going to have to roll up my sleeves and dive into the code base. one additional approach has occurred to me though, and i wonder if you all can offer an opinion. it's been said that there are two approcahes to my problem: 1) write a module that will run once per frame and handle control inputs and display outputs on my hardware. I don't think it is possible to have a reliable data flow, and doing things every frame will slow the whole thing. 2) write a network client that is telnet based and send packets over the net. it occurrs to me that if FG supports telnet, that there must be a class somewhere that handles socket based communication. since sockets also make a fairly elegant for of IPC on a unix system, i was thinking that developing a class (or subclass) for this purpose might work out well with minimum impact to the existing code. Well, if you use the telnet protocol there is no impact on FG code and it can work today. could anyone commenton this idea please? in closing, i'd also like to ask if there is any sort of technical reference dosumentation that would allow a new coder to begin exploring the project. You should have a look at fgfsclient.cxx in the FG/script/exmaple subtree (on the cvs). The script/python subtree has also good examples of what can be done using the telnet protocol. The server side of the telnet protocol can be found in the src/Natwork/props.* files. Also FG must be lauched with --props=5501 to activate the server side. Now you juste have to find the properties that you need and the property browser is handy for that. thanks to all, and best regards, martin pardee ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:chase/cockpit view
Yu QingRou wrote:
I have another question regarding the view manager:
Is it possible in FlightGear, we can have two viewpoints at the same
time? I found in some other flight simulator, for the
panels/instruments, user sees with cockpit view, while at the same
time, for the scenery outside the cockpit, it uses chase view so user
can see the attitude of the aircraft.Or, we can say, the window of the
simulator is splited to two small windows, one for panels/instruments
using cockpit view while the other, using chase view.
By checking the codes, seems FlightGear doesn't support this. Any
ideas about how to realize this? Though this functionality may not
have too much value...:-(
The 2D panel allready uses a second viewpoints. I think you could try to
play with this function
in Cockpit/panel.cxx :
bool
fgPanelVisible ()
{
if(globals-get_current_panel() == 0)
return false;
if(globals-get_current_panel()-getVisibility() == 0)
return false;
//
if(...)
return true;
///
if(globals-get_viewmgr()-get_current() != 0)
return false;
if(globals-get_current_view()-getHeadingOffset_deg() *
SGD_DEGREES_TO_RADIANS != 0)
return false;
return true;
}
Perhaps you can add a property to trigger the 2D panel so its configurable.
Thanks Regards,
QingRou
[Flightgear-devel] Re: chase/cockpit view
Melchior FRANZ mfranz at aon.at Sun Aug 1 09:31:31 CDT 2004
Previous message: [Flightgear-devel] fgfs aborted with the dc3 Next
message: [Flightgear-devel] FlightGear v0.9.5 Messages sorted by: [
date ] [ thread ] [ subject ] [ author ]
* Sam -- Sunday 25 July 2004 18:33:
can anybody give me an advice how to implement new view
inflightgear: a combination of cockpit and chase view - so that the
plane would be looked at from behind (like in chase mode) but at the
same time viewport behaviour would be the same as in cockpit - i mean
precise rotation (with no delays like in chase mode, [...]
Just leave the at-model-*-damping settings in the view config away.
m.
_
MSN Messenger: http://messenger.msn.com/cn
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] How to compute Takeoff speeds
Ok there is a lot of table of speed vs weight vs flaps position everywhere. I want to compute them and not use any table. And it obvious that tables are the result of some computation. Do you think I can use something like that ? Vr = sqr( W / (0.5 * rho(0) * CL0 * S) ) CL0 is CL-0, rho is at airways level. I think I should add "Delta_Lift_due_to_flaps" to CL0, is this correct ? If any guru can help me ;) Something else. I have well advanced with the fmc, you can see a few screenshots here : http://www.chez.com/tipunch/flightgear/index.html Regards, Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] glGenList Bug
Frederic Bouvier wrote: Erik Hofman a écrit : Frederic Bouvier wrote: Perhaps a patch to simgear/flightgear only without touching plib would be better. The threading problem is a flightgear problem. Generally I would agree with you but this differed DList method is way easier than integrating it into FlightGear itself. Besides it doesn't change the functionality of plib itself but instead it adds a new method of using display lists. With makeDList really functionning : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-20041010.zip You should like it ;-) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d 747-100 on ground at SFO default runway, cycling thru different view (V key) view - 0.9.5 - 0.9.6 10/09 - Dlist 10/10 cockpit-33 fps-47 fps - 57 fps v - 24 fps - 39 fps - 50 fps v - 25 fps - 39 fps - 50 fps v - 27 fps - 42 fps - 53 fps v - 24 fps - 28 fps ? - 37 fps v - 22 fps - 32 fps - 40 fps cockpit again - 28 fps - 39 fps - 48 fps night cockpit view enhanced runway light on - 4 fps - 4 fps - 4 fps enhanced runway light off - 24 fps - 31 fps - 36 fps AMD 2100+ GeForce Ti4200 W98 (1024x768 32bits) Regards ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Frederic Bouvier wrote: Vivian Meazza wrote: Martin Spott wrote: Sent: 13 October 2004 09:42 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: Vivian Meazza wrote: I've just downloaded and installed fgfs-0.9.6-20041010 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/. It crashes, cause unknown. However, fgfs-0.9.6-20041009 works very well, using all the same settings, etc. To my impression there's already a 'release' package: ftp://ftp.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-win32.zip Would you mind to try that one ? That one works as well as fgfs-0.9.6-20041009. Frame rates of up to 75 on a Pentium 4 2.8 512Mb Ram and Nvidia FX5200. A very worthwhile effort by all concerned. It's good to read that the final release works :-) It should be a little better than fgfs-0.9.6-20041009 in building areas. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d the 'release' binary of fgfs does not launch, it calls MSVCR71D.DLL (not on my system). Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: crease for ac3d files and speedup
Melchior FRANZ wrote: * Curtis L. Olson -- Wednesday 13 October 2004 23:47: I haven't looked closely at the display list stuff. Are we being careful to free the display lists when we free the associated objects and remove them from the scene graph? Is this something that plib should automatically handle (but maybe isn't because we are the first to stress test it?) No, it doesn't look like plib accumulated DLists. I flew the Hunter again from KLAX to KSFO along the coast, then quite a while heading W, into the pacific. KLAX, right after taking off: 22k (i.e.: 22.000 DLists) coast: avg. ~18k (13K--22k, depending on the terrain; peaks at 30k) KSFO: 27k heading W, slowly falling to: 9k exiting from fgfs: 2960 The final 2960 DLists were not freed via glDeleteLists. But in any case: the DLists weren't the cause for excessive memory consumption. It could have been problems with KDE's artsdsp. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Those numbers (22k...9k) seam enormous to me. You say 13 to 22k depending on terrain... If I understand well we have one dlist per polygone ? Each terrain chunk (.btg) is loaded and stored in his ssg tree. A range and transform matrix is added at the top of this tree. Isn't it possible to have one Dlist for this whole tree ? Regards. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Back online
I had no connection for some time. I did not work on the fmc this last weeks, I wanted to change my mind so I played with some piece of code to try some possible enhancement to the graphical environment (sky, cloud, weather). I got nothing that really convice me, we will see that later. I have put the source code of the prototype fmc here : http://www.chez.com/tipunch/flightgear/fmc/fmc.html I would appreciate some comments. Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VATSIM/IVAO integration MCDU/FMC
Jeroen Hoppenbrouwers wrote: On Thu, Sep 30, 2004 at 02:54:21PM +0200, Boris Koenig wrote: Harald has even created some preview screenshots of his FMC project: http://www.chez.com/tipunch/flightgear Hmmm, do I recognize my own photo there? With the small damage to the MCDU casing near the left annunciators? :-) I have this photo up to 1280x1024 (bigger, actually) --- ask! Straight from the Lufthansa sim. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You are right. I had this image on my HD and could not remember from where it came. I am sorry. Now that you said from where it comes, its even more obvious that we can't keep it as we need gpl material. Harald. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Weather - Clouds
Hi, I did some research on 3D clouds for some time and finaly got something not too bad. I've started to add that to SimGear this week end, here are the first alpha screen shots : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-011.jpg http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-013.jpg I have alse some code nearly ready for rain, snow and lightnings. My next step will be the automatic generation of the cloud layers depending on the METAR data, I have allready found some plausible rules to generate the right kind of clouds based on altitude, wind, dew point, etc. Well, the idea is to have a visual environment almost realist and why not, not so far from real weather. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Weather - Clouds
Curtis L. Olson wrote: Hi Harald, Your screen shots look really nice. Are you using some sort of imposter technique? If you have something workable, please feel free to send early versions to Erik or I for inclusion in CVS. I'm sure there are plenty of others who'd love to play with these. We do have an existing 3d cloud demo in FG, but it was written with an entirely separate scene graph/coordinate system and never fully integrated into FlightGear. Best regards, Curt. The impostor code is not ready, I still need to call the new RenderTexture class. I must also look at the reposition code because atm the clouds are moving with the plane...I will try to send something next week end. Jon Stockill wrote: Nice :-) Are the additional effects just a whole screen effect, or are they tied to the cloud objects so that (for example) visibility is reduced below rainclouds. A lightning is tied to a cloud and could perhaps cast light around (even if I don't know how). I thought of whole screen effect for rain or snow because I am using the technique described in Niniane Wang paper - a double cone around the camera - to draw raindrops or falling snow. And its easy to reduce the whole scene visibility or light when its raining for example. But I was thinking of adding cloud shadows if the clouds themself don't kill the fps too much. John Wojnaroski wrote: Are you using the techniques and algorithms devleoped by Mark Harris that are currently in SimGear? You might want to read his dissertation posted on his web site. Mark has since gone on to greener pastures working for Nvidia. I don't think there are any snapshots on the website. Regards John W. No I am not doing like this. I read his papers (and a lot of others about clouds) but I don't totaly like the method. He tries to do some realist lighting of clouds and I agree they are nice but first I am not sure that this is fast enough and second I am wondering if this is usefull to do accurate lighting. Water and ice clouds don't look the same, clouds cast shadow on other clouds, etc, lot of things that are hard or time consuming. I am using some sort of metaballs that are randomly placed in box containers. The cloud is built with a set of positionned box that determine his general shape. For the lightning I first use the classical dot product of normal and light - on each vertex for a smooth shading - this will give a bit of volume and should light the side of the cloud facing the sun and darken the opposite side. This computed light is weightned by an anisotropic factor, and finaly an ambient term is added. Its not realistic but its not too bad too ;) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Erik Hofman wrote: Hi, I have added the new 3d clouds code from Harald Johnson to CVS. The code is not yet perfect (the movements to the viewer needs some tweaking) but the effects are really nice. I hope we can figure out the problems and eliminate them because the results are even better than I had expected! Another thing is that it seems to depend on glut functions which need to be resolved for SDL users also. A third problem is that it uses the RenderTexture class which hasn't been implemented for MacOS-X yet. Anyway, en ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ok let's see the different problems : - use of RenderTexture class on MacOs : I didn't know (and didn't look very hard either), I am wondering if its is not implemented in the cvs tree of SDL, should check that. - poping clouds when rotating view : I don't think I had this bug, will recheck that, perhaps it depends on the location. - FPS droping from 40 to 10 and can't disable clouds : try to set 0 in texture cache size to disable but I must admit that this code was a bit bugged, its allready corrected at home. Also there was another bug, a lot of computation were done even for impostors. Never push the visibility of 3d clouds behind 3 meters. Also try to set the texture cache to 1024k, that should give a lot of impostors. The default number of impostor is not right and that's why you have a degradation of fps. - fog bug : ok I think I have not re-enable fog Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Roy Vegard Ovesen wrote: On Sunday 24 April 2005 15:21, Paul Surgeon wrote: On my system the new 3D clouds only appear when I look directly at them. I have to move the pan cursor over them to see them. Same thing here, and there are red/white squares around the clouds that have not yet turned into 3D clouds. Red/white square was for debug only. If the rendering options don't do anything when you press ok perhaps you missed the flightgear patch in envirenment_mgr.cxx. About the display bug, nobody can see that at KSFO ? on ground : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-017.jpg in the air : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-018.jpg Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
Vivian Meazza wrote: Drew wrote Ah...that's alright, I'll just stick with what I have. I was told it was a few mouse clicks, and it's already taken more of my time that it's worth. All I'm really trying to do is draw a black rectangle. Thanks for your help. No problem, pity you can't make it work - it really is a boon during development. But you are right not to waste time on it. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I have another probleme with wincvs. In the list of files in the explorer nearly all files have an 'unknown' state. So i don't have the diff choice when I right click on them. I've tried an update with the command line but that does not chance anything. Its a fresh install of wincvs 2.x but I had the same with the 1.3. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Jon Stockill wrote: Yes, it's slightly odd seeing the clouds appear/disappear (even when stationary - just rotating the view seems to cause the problem). However, the overall effect is fantastic - is there any way to see the precipitation model yet? Great work Harald! Shame on me. I was not using an up to date flightgear cvs, now that I have updated it I see the desastrous effect. Clouds are not culled correctly. That explains the poping, but it had also an enormous impact on fps. In attachment is a quick hack. Harald. cvs diff -u -- cloudfield.cxx (in directory F:\dvlp\SG\source\simgear\scene\sky\) Index: cloudfield.cxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.cxx,v retrieving revision 1.4 diff -u -r1.4 cloudfield.cxx --- cloudfield.cxx 26 Apr 2005 09:08:58 - 1.4 +++ cloudfield.cxx 26 Apr 2005 18:28:46 - @@ -180,6 +180,7 @@ // correct the frustum with the right far plane ssgContext *context = ssgGetCurrentContext(); frustum = *context-getFrustum(); + frustum.setFOV(55.0,0); frustum.setNearFar(1.0, CloudVis); } ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
Vivian Meazza wrote: Harald JOHNSEN wrote: I have another probleme with wincvs. In the list of files in the explorer nearly all files have an 'unknown' state. So i don't have the diff choice when I right click on them. I've tried an update with the command line but that does not chance anything. Its a fresh install of wincvs 2.x but I had the same with the 1.3. Harald. I'm absolutely not a WinCVS guru. What I know about it has been learned mostly by trial and error (some of the former and lots of the latter). The documentation, shall we say, leaves a lot to be desired. So here goes. What are the extensions of the unknown status files? Many files in the source code are generated by the compiler, and are therefore not in the repository (sorry, BGOTO) extensions .a, .o .exe fall into this category. Files which you have generated and are not in the repository also have the status unknown. Some editors spew these like crazy; they are hidden in windows explorer, but not in WinCVS. Try selecting a directory (make sure it's not one in which you have modified files - that's not fatal, but recovering your work is a darned nuisance -, then Modify Update. On the update screen select 'create missing directories' and 'get the clean copy'. See what happens. Next, open some directory in windows explorer and delete the files which have status unknown (but are not .a .o. or .exe) See what happens - they should get the status missing. (If they don't they are probably not in the repository in the first place.) Then try the above again to restore them. Finally, if none of this addresses the problem, you can always delete the directories and start over. I've had to do that several times when my copy and the cvs copy just got too far out of line. The good thing about the later versions of WinCVS is that it pretty much works, but it's not all that intuitive and takes some figuring out. Hope none of this is teaching grandmother to suck eggs. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Thx for the help. Nothing worked so I did a checkout on an empty directory as you sugjested. If cvs creates the files all is ok. It does not work with files coming from a tarball or created by hand. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Frederic Bouvier wrote: Selon Melchior FRANZ: * Harald JOHNSEN -- Tuesday 26 April 2005 20:41: Clouds are not culled correctly. That explains the poping, but it had also an enormous impact on fps. In attachment is a quick hack. Ahh. That makes a big difference. Almost usable now. :-) Now, if you could fix the fog problem and fade clouds inout rather than popping them up abruptly, it would be quite cool already. I just compile them with MSVC without a single warning. And they work fine ( I missed the initial glitches ;-). I am really impressed. Erik did a few adaptations, I'm only using .net since a week or two and I have allready forgotten the headach I had with templates and MSVC ;) I know this is preliminary code, but is there a reason why 100% cloud density doesn't give us overcast rather than scatered/broken as it is now ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d The density is supposed to reduce the number of clouds on low to mid level computer, it won't change a broken layer into an overcast one. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Frederic Bouvier wrote: So the 3d code shouldn't exclude 2d clouds but fade into them. But if we want to model front one day, it is a thing to ponder now. Overcast layers are flat at the base but often show towers from the top, at altitude a 737 or an Airbus are supposed to fly. I wish we could one day see really big clouds in FG and not only small cumulus blobs. Is that towering cumulus or perhaps some cumulonimbus ? I agree cirrus can stay 2d. Yup. BTW: how are computed cloud shapes ? In the M. Harris code, they are modeled with a tool he never released and stuck to the same set of shape ( stored in a binary format file ). Is it a procedural function or something fixed ? I am dreaming loudly here but we could envision in a distant future that clouds could be reshaped at runtime by wind and current. So implementing a very simple procedural function rather than something fixed could be seen as the first step of something more ambitious later. In fact I was thinking about implicit surfaces ( see http://www.unchainedgeometry.com/jbloom/papers.html ) aka metaballs in blender to picture the sky at a rough level and refine individual clouds with impostors like M. Harris' or now Harald's code. /dreaming -Fred ideas provider ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I made 3 screenshot of my lab test program. First I give position and size of containers, those will give the general shape of the cloud : http://sites.estvideo.net/tipunch/flightgear/images/cldbuild1.jpg With that, and given some hardcoded rules (cu bottom are flat, stratus only use 1 metaball, etc), metaballs are generated : http://sites.estvideo.net/tipunch/flightgear/images/cldbuild2.jpg We have now a sort of volumetric shape that we render with simple quads for speed : http://sites.estvideo.net/tipunch/flightgear/images/cldbuild3.jpg The idea is to build the cloud with a very simple definition (position of boxes, size, content). This definition will be in an xml so everybody will be able to test new shapes. To reply at your question, yes it is fixed, but there is still the possibility to alter the shape by moving the metaballs or adding new. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC 7.1 Runtime Error
Ben Morrison wrote:
I have downloaded the following source code files: FlightGear 9.8,
SimGear 3.8, plib 1.8.4, and zlib 1.1.4. I was able to get this to
compile in Visual Studio 2003 but when I try to run flight gear with
the following command: fgfs fg-root=c:\\GS_PTT\\Flightgear\\data
airport=KSFO aircraft=A-10cl disable-sound and I get the
following runtime error almost immediately:
Debug assertion failed!
Program: fgfs.exe
File: isctype.c
Line: 68
Expression: (unsigned)(c+1) = 256
Has anyone ever encountered this error? Is it possible to set
breakpoints in Flightgear and debug it that way?
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
You can debug, no problem.
The assert is a known problem, it happens with a debug build under VS,
you have to change a view lines in simgear, patch attached.
Harald.
Index: strutils.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/strutils.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 strutils.cxx
--- strutils.cxx7 Sep 2002 02:58:19 - 1.1.1.1
+++ strutils.cxx26 Apr 2005 17:01:34 -
@@ -41,14 +41,14 @@
while (i len)
{
- while (i len isspace(str[i]))
+ while (i len isspace((unsigned char)str[i]))
{
++i;
}
j = i;
- while (i len !isspace(str[i]))
+ while (i len !isspace((unsigned char)str[i]))
{
++i;
}
@@ -57,7 +57,7 @@
{
result.push_back( str.substr(j, i-j) );
++countsplit;
- while (i len isspace(str[i]))
+ while (i len isspace((unsigned char)str[i]))
{
++i;
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC 7.1 Runtime Error
Ben Morrison wrote: Thanks, guys. This is my first time posting to the board and I am impressed with the response times. I am compiling in debug mode because I am going to be modifying flightgear later. Ok, Harald's solution fixed the runtime error but now flightgear just sits there and doesn't start. What could be causing this? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d It's not very clear. Check that you added the '--fg-root=x:\flightgear\data' parameter to the debugger, not finding the airports/runway data can lead FG to an infinite loop for example. Or just press break and look where he is in the code ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
Lee Elliott wrote: On Friday 06 May 2005 17:29, Ampere K. Hardraade wrote: On May 6, 2005 10:06 am, Karsten Krispin wrote: If you bank your plane the clouds will move in the opposite direction as you turn to - They move to the right or to the left depending whether you turn left or right. (And I'am not talking about the movements through the wind ;)). It is strange to discribe this - The easiest way would be you try it your self :) - You'll immediatly recognize what I mean. - Just do some hard and fast turns. Also it looks like if they get zoomed in or zoomed out... You are right there is a strange movement. It's perhaps the rotation axes of the clouds that are a bit off. I know what you mean. It seems you can never go inside the cloud. Perhaps visibility should be decreased to a few meters when one is inside the clouds? Ampere I think that you have that effect if you fly to the border of a cloud. The quads are rotated to face the camera and when the quads are very near on the left or the right the rotation is too big and the quad go out of sight. This will be corrected. Hmm... I've flown inside them pretty convincingly but I'm seeing a darkened region within the clouds, even when I'm outside them, between the horizon and what I presume to be the bottom of the sky-sphere. I can post some screen shots of inside the clouds or of the horizon problem if anyone wants. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Can you post screen shots of the darkened clouds problem ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
Lee Elliott wrote: On Saturday 07 May 2005 10:04, Harald JOHNSEN wrote: Lee Elliott wrote: On Friday 06 May 2005 17:29, Ampere K. Hardraade wrote: On May 6, 2005 10:06 am, Karsten Krispin wrote: If you bank your plane the clouds will move in the opposite direction as you turn to - They move to the right or to the left depending whether you turn left or right. (And I'am not talking about the movements through the wind ;)). It is strange to discribe this - The easiest way would be you try it your self :) - You'll immediatly recognize what I mean. - Just do some hard and fast turns. Also it looks like if they get zoomed in or zoomed out... You are right there is a strange movement. It's perhaps the rotation axes of the clouds that are a bit off. I know what you mean. It seems you can never go inside the cloud. Perhaps visibility should be decreased to a few meters when one is inside the clouds? Ampere I think that you have that effect if you fly to the border of a cloud. The quads are rotated to face the camera and when the quads are very near on the left or the right the rotation is too big and the quad go out of sight. This will be corrected. Hmm... I've flown inside them pretty convincingly but I'm seeing a darkened region within the clouds, even when I'm outside them, between the horizon and what I presume to be the bottom of the sky-sphere. I can post some screen shots of inside the clouds or of the horizon problem if anyone wants. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Can you post screen shots of the darkened clouds problem ? Harald. Hello Harald, there's a screen-grab (425k) at http://www.overthetop.freeserve.co.uk/fgfs-screen-009.jpg I've got the weather visibility set to 3m at this altitude. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I'm affraid I can't reproduce the problem, but I have allready changed a few things in the rendering order of clouds to correct the problem of scenario objects visible in front of clouds, I changed the transparency of clouds too, they now appear totaly transparent at the horizon. 3 screen shots, visibility set to 3, clouds visibility set at 3 different ranges : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-025.jpg http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-026.jpg http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-027.jpg another screen shot from another view : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-029.jpg Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
Manuel Massing wrote: Hi, I think that you have that effect if you fly to the border of a cloud. The quads are rotated to face the camera and when the quads are very near on the left or the right the rotation is too big and the quad go out of sight. This will be corrected. so are you using billboards rather than impostors? Is a single cloud represented by multiple billboard primitives or by a single quad? In the latter case, you could try to use impostors with fixed world-space orientation, which are invalidated (updated) above a certain viewing angle treshold and distance treshold (which depend on the extent of the cloud bounding box and impostor texture resolution, respectively). Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d A cloud is represented by multiple billboard primitives. Above a certain distance they are replaced by an impostor (one quad). When they are near I draw all their billboards, each having its viewing angle to face the camera. It's that angle that must be locked above a certain value. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
Erik Hofman wrote: Gerard ROBIN wrote: Hello, working with CVS MAY-08 --2 o clock-- FIRST When using -enable-real-weather-fetch, i get a non permanent presence of the clouds. once every disappear , once only one disappear, once every coming back. This, randomly during a very short period of time 3 ,4 second. Sometime its quiet. Flying during 10 min, over the se,a altitude 500. Looking at the content of the data coming from metar: elevation 907 coverage few thickness 65 When the coverage is few or broken the cloud layer disappears when inside the layer. This behavior is rather new but is useful for training purposes. It should not be necessary to do it this way when the 3d clouds are good enough to replace the 2d cloud layers. Yes, even with 3d clouds there was still the 2D code running for this effect. Also your version still have an hard coded 3d cloud layer (and the base of the two layers is not coherent). I will commit in a day or two a version that handle the metar and the cloud dialog a bit better. If i run again without real-weather everything is good. The clouds are nice and very fluid. SECOND The option --disable-clouds3 has no effect. We still continu loading on 3D clouds. That's because we now have two(!) pieces of code for generating 3d clouds, this option is only for the old cloud code. You should be able to disable them by adding the following: --prop:/sim/rendering/clouds3d-enable=false Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d They won't be enabled by default in my next release because I am now generating different type of layers and - ahem - it's far from perfect ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Model: AC130-H
Curtis L. Olson wrote: Ben Morrison wrote: Sorry, I am not being very clear. When I asked for a good example to start with, I meant which aircraft is the most complete. For example, which has sounds, panels, landing gear and flap animations, etc. For the 3d model I think I will try to convert a model made for Microsoft's Flight Simulator. I'm not sure there is any single aircraft that has fully exploited all the facilities FlightGear provides. Lee Elliott's aircraft seem to be especially nice in terms of the external 3d model and surface/gear animation. Some of his gear retraction/compression animations are simply outstanding and amazing. Other people have done some really great 3d cockpits ... the P51 was one of the first examples, there is also the spitfire and hunter. The standard C172 has a pretty complete electrical system modeled ... down to the individual buses and circuit breakers which are all fully functional in the sense that you can pop a circuit breaker and everything down stream will go dark. Some aircraft have really well tuned flight dynamics models such as the pa28-161. The 3d model is fine, but nothing too fancy, and the 3d cockpit is not yet finished (i.e. no radio stack.) The piper cub might be a nice example to start with. It's pretty simple all around, but has animated control surfaces, a 3d cockpit, and all the other basic components. It can be a *lot* of work to fully model all aspects of an aircraft, occasionally developers have teamed up to each work on their area of expertise and build a better aircraft than any of them could have done individually. Regards, Curt. I'd like to work on a plane too in my spare time (model, animation or panel). Do we know of some aircraft from cvs that need some work or is it better to start a new one ? What type of aircraft are people using or would like to use ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Web site problems?
Curtis L. Olson wrote: Ben Morrison wrote: This doesn't relate to this topic in anyway but the site looks like it is partially down (www.flightgear.org). The menu on the left is missing. Has anyone else noticed this? I am getting javascript errors and after viewing the source it looks like the function call MainMenu() is causing an error. The Japanese version is working. Lol, too bad I can't read Japanese. What browser are you using? What specific javascript error messages are you seeing? Curt. I had that on IE 6.x since yesterday I think (or perhaps the day before but not sure). error line 134 : object expected here is the source of the page (begins with a blank line) !-- Standard Header Begin -- html head titleFlightGear Flight Simulator/title link rel=stylesheet type=text/css href=/default.css script src=/templates.js defer/script /head body !-- Display the main logo -- scriptMainLogo();/script table id=global tbodytr td id=menu !-- SiteSearch Google -- scriptSiteSearchGoogle();/script !-- Display the main menu -- scriptMainMenu();/script /td td id=page !-- Standard Header End -- H1FlightGear is an open-source, multi-platform flight simulator./H1 DIV ALIGN=CENTER View the FlightGear web site in: [A HREF=http://www.flightgear.org/;English/A] [A HREF=http://www.fr.flightgear.org/;French/A] [A HREF=http://www.jp.flightgear.org/;Japanese/A] /DIV P DIV ID=topscreens ALIGN=center A HREF=images/crop-variety.jpgIMG CLASS=mainscreen WIDTH=100 HEIGHT=75 SRC=images/thumbnails/crop-variety-thumb.jpg ALT=A4 3D cockpit/A A HREF=images/SeaHawk.jpgIMG CLASS=mainscreen WIDTH=100 HEIGHT=75 SRC=images/thumbnails/SeaHawk-thumb.jpg ALT=SeaHawk over KSFO/A A HREF=images/flyer.jpgIMG CLASS=mainscreen WIDTH=100 HEIGHT=75 SRC=images/thumbnails/flyer-thumb.jpg ALT=1903 Wright Flyer/A A HREF=images/an225-departing-KSFO.jpgIMG CLASS=mainscreen WIDTH=100 HEIGHT=75 SRC=images/thumbnails/an225-departing-KSFO-thumb.jpg ALT=AN225 departing KSFO/A A HREF=images/cockpit.jpgIMG CLASS=mainscreen WIDTH=100 HEIGHT=75 SRC=images/thumbnails/cockpit-thumb.jpg ALT=C-172 3D cockpit/A A HREF=images/approach-lighting.jpgIMG WIDTH=100 CLASS=mainscreen HEIGHT=75 SRC=images/thumbnails/approach-lighting-thumb.jpg ALT=Approach Lighting/A /DIV TABLE TR TD VALIGN=TOP DIV ID=page H3Announcements/H3 UL LI A HREF=announce.html#taxidrawBMar 24/B - TaxiDraw-0.3.1 released./A LI A HREF=announce.html#aircraftBJan 25/B - New Boeing 314, Concorde v2.0, B-52F Update./A LI A HREF=announce.html#v0.9.8BJan 18/B - FlightGear v0.9.8 released./A LI A HREF=announce.html#plib-1.8.4BJan 15/B - Plib-v1.8.4 is released./A LI A HREF=announce.html#kimBDec 19, 2004/B - Kim Komando Cool Site of the Day./A LI A HREF=announce.html#interviewBNov 29, 2004/B - FlightGear Interview Posted./A LI A HREF=announce.html#frenchBNov 15, 2004/B - French Language Web Site./A LI A HREF=announce.html#japaneseBNov 1, 2004/B - Japanese Language Web Site./A LI A HREF=announce.html#ircBOct 15, 2004/B - FlightGear IRC Channel./A LI BA HREF=http://www.flightgear.org/oldnews.html; More news .../A/B /UL /TD TD VALIGN=TOP DIV ID=page H3Quick Links/H3 UL LI Download FlightGear for Windows Now: A HREF=ftp://obgyn.edu.pl/fgfs/Win32/fgsetup-0.9.8a.exe;[Mirror-1]/A A HREF=ftp://ftp.de.flightgear.org/pub/fgfs/Win32/fgsetup-0.9.8a.exe;[Mirror-2]/A A HREF=ftp://ftp.flightgear.org/pub/fgfs/Win32/fgsetup-0.9.8a.exe;[Mirror-3]/A LI A HREF=http://www.flightgear.org/Downloads/aircraft/; Download Aircraft./ABR LI A HREF=http://www.flightgear.org/Downloads/scenery.html; Download World Scenery./ABR LI A HREF=http://www.flightgear.org/Downloads/source.shtml; Download Source Code./ABR LI A HREF=http://cdrom.flightgear.org;Purchase a FlightGear CDROM or DVD set and support our project./ABR /UL H3Upcoming Events/H3 UL LI A HREF=events.html#matlab05BMay 24-25/B - MathWorks International Aerospace and Defense Conference 2005. Manhattan Beach Marriott, Manhattan Beach, CA./A /UL /DIV /TD /TR /TABLE H3IMG ALIGN=MIDDLE SRC=http://baron.flightgear.org/cgi-bin/wwwcount.cgi?df=curt_flightgear.datamp;dd=fatptamp;ft=3; ALT=counter/H3 !-- Standard Footer Begin -- /td td id=googleads valign=top !-- insert google add here if we decide to do that sort of thing -- script type=text/javascript!-- google_ad_client = pub-2485404446552133; google_ad_width = 120; google_ad_height = 120; google_ad_format = 120x90_0ads_al_s; google_ad_channel =; google_color_border = 2D5893; google_color_bg = 99AACC; google_color_link = 00; google_color_url = 99; google_color_text = 003366; //--/script script type=text/javascript
Re: [Flightgear-devel] City signs
Dave Culp wrote: I made a large (1000 meter) sign to place over the coordinates for Sembach and Enkenbach, Germany, because the scenery data for that area is not good enough for finding towns visually. http://home.comcast.net/~davidculp2/city_sign.jpg It would be possible to put these over lots of towns and have them switched on/off with a key binding. Is there any interest in that sort of thing being applied elsewhere, and on a large scale, amongst the developers? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d How did you made that ? Is it a scenari object inserted in the .stg or a run time generated poly from a text string ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Simgear props dialogs
The last commit on props.cxx and prios_io.cxx has a side effect on dialogs. They appear correctly the first time you invoke them, but on the second time they are drawn in the bottom left corner of the screen with a transparent background. A roll back on these 3 files corrected the problem. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
Lee Elliott wrote: On Sunday 15 May 2005 15:50, Curtis L. Olson wrote: Erik Hofman wrote: Curtis L. Olson wrote: Is there something special that needs to be done to activate the new 3d clouds? Before this commit I got them automatically, now I am just getting the original textured layer clouds. I don't see anything promising in preferences.xml ... ? MenuBar-View-Rendering-Enable 3d clouds This is done because the code isn't perfect yet. Hmmm, does this not work with 16bit visuals depth? Curt. I can't get the new 3d clouds to appear here either. They used to work ok (except for the problem I posted about) but enabling them in the rendering options dialogue didn't have any effect. Imediatly after starting FG, enabling the 3d clouds in the rendering dialog should allways display a layer of cumulus. This is the same hardcoded layer as in the previous version. If you change the weather in the 'weather scenario' dialog you should have : - with 'fair weather' = a layer of cumulus (3d) + a layer of cirrus (2d) - with 'thunderstorm' = a layer of cu/cb (3d) +a layer of ns (3d) - with 'metar' = this is not perfect (lets say buggy) because the real metar data is not fetched before the usual 15 minutes so the layers generated will just use the current data from the property tree. Also note that the layers can be a mix of 2d/3d and perhaps no 3d layers will be generated (because I desactivated the generation of stratus type layers, I was not very happy with their apparence). Now what do you see if you disable all clouds clayers but the first ? An empty sky or a 2d layer ? I also found that the rendering options dialogue became unusable if it was closed and then re-opened: it seemed to be centered on the bottom left of the screen and was transparent, except for the value/data boxes and the close button:( Checked everything in the property browser but couldn't see anything wrong. Log-level=warn didn't show anything. Yes this is the problem with dialogs/properties. The 2d clouds seemed fine. I also noted that, both with and without real-weather fetch, and with each of the scenarios I tried, I was still frequently getting the incorrect wind and visibility settings for the alt agl that I was flying at. Or even sitting on the runway, for that matter. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ok, I will check that. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
Erik Hofman wrote: Curtis L. Olson wrote: Lee Elliott wrote: I can't get the new 3d clouds to appear here either. They used to work ok (except for the problem I posted about) but enabling them in the rendering options dialogue didn't have any effect. It appears that the newest incantation of 3d clouds no longer works in 16 bit graphics modes. :-( For those who are currious: http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-screen-016.jpg Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I hope no one will have an heart attack, the thunder sound is surprising the first time ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
Chris Metzler wrote: On Sun, 15 May 2005 16:21:52 +0200 Melchior FRANZ wrote: This is extremely impressive. Very well done, not only the clouds (fading in in the distance!; brighter?), but also lightning and rain. (BTW: we could extract some more lightning info from metar IIRC, such as lightning frequency; I didn't do this before, because we had no use for it). It's been gorgeous stuff so far. Does it solve the two most noticeable bugs I've seen: - static 3d ground objects seen through the clouds with unlimited visibility distance? I thought it was corrected. If you launch fg with --enable-clouds3d the problem reappear, I can also see the problem Erick was talking and that I could not reproduce. The strange thing is that when I disable it in the property tree the visual bug persists as if some (opengl) state is altered. The bug is not visible when launched with --disable-clouds3d. I'll check that. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] splash screen distortion
Dave Culp wrote: During sim startup, about 2 or 3 seconds before the world appears, the splash image is distorted, most often stretched vertically, sometimes split in two vertically. It's been doing this for a long time, maybe a year or more, but I've been ignoring it until now. Anyone else getting this? Mandrake 10.1 nVidia MX440 with latest driver cvs plib, SimGear, FlightGear glut, openal Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d This is because of the 2D panel. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Drew wrote: Interesting...I have no use for navaid data. Is there an option to turn these off? And as far as airports go, I only care about the imagery. Any other info, I can do without. Hmmm, that would probably free up a lot of memory too, huh? I'll look into limiting the region of airports it loads. I find it odd that it takes 5 minutes for you...I'm by no means running it on a top-of-the-line gaming machine...a Centrino laptop 1600 MHz with 256 Megs of RAM and a Mobility Radeon 9000 graphics card. Edit apt.dat and runways.dat, just leave KSFO for example. Normaly you should leave a few others used in ai or atc (I don't remember) or disable this functionalities if you don't want an abort of FG. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Drew wrote: FlightGear takes nearly a minute to start up from my Windows build, and I'm just wondering if there's an easy way to shorten this if I'm not using all of flightgear's features. Is there one particular task that takes particularly long? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Another problem not related to pure performance is that the first retrieval of metar data can block FG for a long time (perhaps one minute) when the metar server is not accessible (or when there is any network problem). The code does a lot of (useless) retries. Perhaps its simpler not to update the metar on IO error and continue silently. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Questions about IO system
Steven Beeckman wrote: Hi Mike, there's an example in the scripts folder (or utils folder) of the sourcecode (I think) on how to interface in Java. I haven't used it yet due to lack of time :(. Greets, Steven Citeren Mike Kopack [EMAIL PROTECTED]: Hey gang, I'm trying to write some Java code to interface with FlightGear's IO system via sockets. I'm running on Windows (don't know if that matters or not.) Anyhow, I need to do two things: 1) Have one socket sending flight commands (like changing the rudder position, or turning on/off the autopilot, setting throttle, etc.) These can come in at any time. 2) Have another socket that my code listens for periodic updates in status information from FlightGear (position, attitude, engine temp, fuel flow rates, etc.) From what I see in the documentation, it shows that you can do this. I'm a bit confused by it though. To do task #1 above, do I just open a socket to Flightgear on the specified port, then send a XML doc with just the 1 command element I want to specify? To do task #2 above, as I understand it, I have to set up a XML file on the machine running FG that basically tells FG what data I want sent back over the socket. Does it come across the wire as an XML doc every x.x seconds (I see that there's a Hz setting when specifying the socket connection in FG), or does it come across as comma delimited or something like that? Any help with this is greatly appreciated. Thanks! --Mike Mike Kopack ISX Corporation 1800 Parkway Place Suite 900 Marietta, GA 30067 678-581-2025 [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You don't need XML, all you want to do is read and write the property tree. As Steven said, check FGFSConnection.java in the scripts subdir for access via props/telnet protocol. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Erik Hofman wrote: Harald JOHNSEN wrote: Another problem not related to pure performance is that the first retrieval of metar data can block FG for a long time (perhaps one minute) when the metar server is not accessible (or when there is any network problem). The code does a lot of (useless) retries. Perhaps its simpler not to update the metar on IO error and continue silently. Which version of FlightGear are you using? This has been fixed a long time ago. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I've just looked at the code. I see that the error count is incremented in the catch but I think I don't enter here, I am spamed with 'metar data too old' on the console. After some time I have a real socket error and I think that after that I enter the catch statement and the error counter is finaly incremented ! Strange that the increment is inside the #ifdef threads. So to be clear : 1) I have a lot of 'metar too old' message (no log file but its more than 50 per loop) 2) after some time I have a sigio (if I remember well, that does not happens everyday of course) 3) repeat 3 times Its with cvs version and that happens in the init code. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery size constraints
Alberico, James F wrote: Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 4 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them. What I think I've learned so far from debugging: 1.) The FGFS FGBinObj reads with no errors. 2.) The access violation occurs during leaf generation. 3.) The breakage occurs shortly after the texture coordinate index exceeds the max value of a short (32767) and goes negative. 4.) The symbols (e.g., tris_tc) that carry the read-in indices are of type int 5.) Examination of the TerraGear bin writes, and the FGFS reads reveal the indices are stored as short types. 6.) So, my conclusion is the scenery of the 1-arcsec tile is limited to 32767 nodes. (or maybe polygons?) And, TerraGear will truncate any index above that when writing to the binary file. I'm a newbie to TerraGear/FGFS details, so please correct me if I'm wrong about any of this. I would appreciate any comments on what mess might result from any attempt to store/read ints, rather than shorts, to expand the scenery resolution. From a performance standpoint, the capacity of the short type may far exceed anything practical at the present time. Comments on that aspect are welcome, too. Thanks!! Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I think that the only side effect will be that your new binary will be incompatible with current scenario files, perhaps that changing short to unsigned short could be enought. But I am wondering if you won't have problem when rendering, isn't there an hardware limite on the number of tris we can send to glDrawElements and glDrawArrays in the plib code ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiled terragear
wrote: Dear list members, I would like to show functions of flightgear and terragear to my boss. I have succeeded to compile flightgear, but not terragear. There is no problem with plib, metakit and openal, but I have add some constants (M_LN2, M_PI, M_E) for simgear and still got 16 errors with model.cxx. I have sent an e-mail to terragear-devel mailing list, but got nothing as answer. So I sent another mail to simgear mailing list, but I got a message to send my problem to flightgear mailing list. I have got flightgear-devel mailing list archives, but there are a lot of file to check for similar errors, and I do not have enough time. That is why, I would like to get windows compiled version of terragear. Best regards... Ayhan TEKGUL ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I can be a pain to compile some source with VS6. If Fred does not have the binaries you could try with the VC7 compiler freely available from the microsoft site. After installation you just change the path to executable, include and lib and you use it in VS6 like the old compiler. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: On Tuesday 24 May 2005 22:14, Martin Spott wrote: Wesley Alden Pegden wrote: glxgears gives me 700fps (as good as it's ever given me), [...] With a working OpenGL/DRI setup you typically get far more than 1000 fps with 'glxgears'. Please run 'glxinfo' or 'gl-info' - whatever you have on your machine - and have a closer look at the OpenGL 'vendor', Martin. I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting 1fps. Same with the heli chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - 20 fps, shift-6 1 fps, shift-3 20 fps. From 2 through to 8 are all 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - 20 fps. Try chase view and 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at 20 fps but then it dropped back down to 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives 3900 fps here. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I have also 1fps, but that's with enhanced runway lighting at night ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGFS final link fails: _imp__pthread symbols not found
Giles Robertson wrote: I've tried compiling fgfs from cvs on mingw again. There are various little changes which I'll roll up at some point (as in, when it's working ;). However, there's an odd problem I'm getting at final link: g++ -DPKGLIBDIR=\/point/share/FlightGear\ -g -O2 -D_REENTRANT -L/point/lib -o C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:232: undefined reference to `_imp__pthread_mutex_lock' ../../src/Scenery/libScenery.a(tilemgr.o)(.text+0xb9e):C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:238: undefined reference to `_imp__pthread_mutex_unlock' This continues for many screens (and for many other calls - it's not just mutex related). The error is the same whether or not I add -lpthread to the command. Investigating the pthread library, all the calls are present in the form _pthread (_pthread_mutex_lock, _pthread_mutex_unlock, _pthread_cond_destroy etc), but none with the _imp_ prefix. gcc 3.4.2 (mingw-special) with win32 thread model. Does anybody have any ideas about what is going wrong? Giles Robertson PS: Apologies for the html email. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I know nothing about mingw but perhaps you are using the wrong pthread.lib(.a) The msvc pthreadVC2.lib that I use have symbols begining with _imp, perhaps you should pick this one. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] msvc71 compiling
can kalkan wrote: while compiling fg i get these errors. i ignored libcmtd.lib, libcmt.lib and errors reduced to these ..additional libs are; sg.lib sl.lib ssg.lib pui.lib ssgaux.lib psl.lib puaux.lib pw.lib fnt.lib ul.lib net.lib sl.lib js.lib zlib.lib simgear.lib alut.lib openal32.lib pthreadvc.lib. please help obj : error LNK2019: unresolved external symbol ___argc referenced in function [EMAIL PROTECTED] bootstrap.obj : error LNK2019: unresolved external symbol ___argv referenced in function [EMAIL PROTECTED] libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol __malloc_dbg referenced in function __Getctype libcpmtd.lib(xdebug.obj) : error LNK2001: unresolved external symbol __malloc_dbg libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol __free_dbg referenced in function void __cdecl operator delete(void *,struct std::_DebugHeapTag_t const ,char *,int) ([EMAIL PROTECTED]@std@@[EMAIL PROTECTED]) .\Release/FlightGear.exe : fatal error LNK1120: 4 unresolved externals Discover Yahoo! Find restaurants, movies, travel more fun for the weekend. Check it out! http://us.rd.yahoo.com/evt=32658/*http://discover.yahoo.com/weekend.html ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You can't ignore libcmt or libcmtd. I suspected that you ignored them because you mixed debug and non debug libraries and then you add lot of errors. Rebuild everything in debug or in non debug (everything = plib + simgear + fg). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Animation Was: jsbsim airstream info
Josh Babcock wrote: Josh Babcock wrote: Jon Berndt wrote: It's alpha and beta. in radians: aero/alpha-rad aero/beta-rad in degrees: aero/alpha-deg aero/beta-deg Jon OK, I'm trying to find what the air velocity relative to the fuselage of a jsbsim plane is. I'm pretty sure the info is in /fdm/jsbsim/atmosphere, but I don't know which values are which. Ultimately this will be used to make a ribbon indicate the wind. If I'm cool, I will be able to make it flap faster as the speed increases. Any help? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d OK, got it working. On another note, are interpolation tables supposed to work everywhere factor tags do? They don't for spin animations, which would be handy for me right now. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hmm, it appears that these only show the aircraft's angles relative to it's own velocity vector. I also need to sum in the crosswind so that I get the angles relative to the air mass. I know I not getting this because when I land and switch the weather to thunderstorm the ribbon doesn't move. Anybody know where I can find the wind angles relative to the aircraft? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I don't think there is this in the property tree (and even in the code). The basic data is /environment/wind-from-heading-deg, and /environment/wind-speed-kt wich are absolute values. Check data/Models/Airport/windsock.xml. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] opengl texgen - projected textures
I am trying to project a texture on the scenario background. A priori everything is setup correctly and the code should work but at the end I only get a projection on the screen space. picture here : http://sites.estvideo.net/tipunch/flightgear/shadow/fgfs-screen-044.jpg It's the leftmost texture from the bottom of the screen that should be projected on the ground. I added a diagonal line to clearly see that there is no perspective on the screen projection. If someone is courageous enought the code is here : http://sites.estvideo.net/tipunch/flightgear/shadow/shadowmap.cxx = new file http://sites.estvideo.net/tipunch/flightgear/shadow/shadowmap.hxx = new file http://sites.estvideo.net/tipunch/flightgear/shadow/render.diff = patch for render.cpp use an external view. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opengl texgen - projected textures
Manuel Massing wrote: Hello Harald, I am trying to project a texture on the scenario background. A priori everything is setup correctly and the code should work but at the end I only get a projection on the screen space. picture here : hmm, don't have the time to delve deeper into your example, but you seem to be using the same projection matrix for light and camera, so the outcome is expected... keep in mind that OpenGL will multiply the texgen matrix with the inverse of the camera matrix at time of specification. So you have to make sure that modelview is set to the camera view at that point. If you use the light point of view, the texgen results in an identity transform + projection. If the light projection matrix matches the camera, fragment and texture coordinates will be identical (modulo bias), thus the screen plane alignment of your projection. Also, a possible caveat: depending on the storage layout of SGMatrix, you might need to feed OpenGL the transposed texgen matrix as plane vectors (and use the transposed bias matrix i have seen lying around :-)). bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You are right, it is indeed working with another light view matrix. Thx ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Main Airports Conflict with Graphic Card6600GT !!!
Gerard ROBIN wrote:
Le mercredi 08 juin 2005 03:08 +0200, Gerard ROBIN a crit :
Le mercredi 08 juin 2005 01:45 +0200, Gerard ROBIN a crit :
Le mardi 07 juin 2005 17:07 -0400, [EMAIL PROTECTED] a crit :
I also have an nvidia card, though an older one, and when I go from Enhanced
Runway Lights (as low as 3 fps) to no Enhanced Runway Lights, it jumps to 40
fps. Any connection?
As far as i understand the preference.xml content,
We do have that property
enhanced-lighting type=boolfalse/enhanced-lighting
AND
In the fg menu i did not indicate Enhanced Runway Lighting.
To conclude about that problem, and before i come back to my old NVIDIA 5200
Does anybody can tell me, how may i deactivate the runway landing
lights ?
thanks
IT IS UNUSUAL that i give the question and later on the answer :-)
I have solved it with a patch in renderer.cxx (hope temporary)
// draw runway lighting
if ( draw_otw ) {
//ssgCullAndDraw( globals-get_scenery()-get_vasi_lights_root() );
ssgCullAndDraw( globals-get_scenery()-get_rwy_lights_root() );
}
==
added comment on line 638
ssgCullAndDraw( globals-get_scenery()-get_vasi_lights_root() );
about, fps: the result is ok (70 fps)
about, Runway landing light it is deleted
about, Runway light still present not deleted.
May be an other Question:
Is it, a PLIB bug, a NVIDIA bug, a FG bug ???
about NVIDIA 6600 it is now able to process GL 2.0 so !!
So you have 'Enhanced Runway Lighting' even when its disabled in the
rendering dialog ?
The slowness is not rellay a bug, it just says that the card can't
render that in hardware.
Perhaps someone will find another way to draw those light...
Harald.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
Dave Culp wrote: This is a poll. Does anyone really want the FDM to allow flying under the terrain, or was that a misunderstanding by me? If nobody wants it then I think it should be disallowed. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d By flying under the terrain you means like flying in a tunnel under a montain ? I think it's improbable. And how would you manage landing on ground or water if one can fly under them ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: old 3d clouds code
Vivian Meazza wrote: Mathias Frhlich wrote On Mittwoch 15 Juni 2005 11:00, Vivian Meazza wrote: When browsing Mark Harris' web page I got the impression that he simulates the airflow. This one? http://www.markmark.net/clouds/ I can't find any reference in the site or the papers there to simulating airflow. It just renders clouds. http://www.markmark.net/cloudsim/index.html Look into that. I believed that this was integrated somehow. That looks phantastic and does things like that. Watch the video on the bottom of that page. Wonderful - just what we need! However, where's the code? I don't think it's what we have. The OpenGL stuff for download from Mark's site just renders cloud. This is Simulation of Cloud Dynamics on Graphics Hardware From his paper: 5. Hardware Implementation As mentioned before, we perform all of the numerical computation for our cloud simulator in the programmable, floating point fragment unit of a graphics processor. Hmmm. Have I got this one wrong? Mark's code (OpenGL) renders up to 51 fixed shape clouds. His lighting and shading is good. I like the way the aircraft penetrates cloud from an outside view. Harald's clouds are nicer, more varied, but perhaps not quite as well lit and shaded. The cloud penetration from an outside view could be improved (and I'm sure will be). Mark's code does not seem to be under active development, while Harald's is. I therefore support the retirement of Mark's OpenGL code. Of course, if we can go the Simulation of Cloud Dynamics on Graphics Hardware route, then wow! All bets are off. Anyone know how to program graphics hardware so that any/all cards would work? V. On Harris pages there is two different things. One is about cloud rendering - physical aspect of scattering of light and technical implementation using dynamic billboards, etc. The other is about simulating the formation of clouds (and simulating fluids in general). The 'Skywork' code available on his site and integrated in FG only handle the rendering, the simulation of formation of clouds is usually non real time anyway. It could be done realltime of course, it all depends of the degree of realism one wants. Other papers show how to do that with non physical rules and still have nice results. See Dobashi and Nishita paper : http://nis-lab.is.s.u-tokyo.ac.jp/~nis/abs_sig.html#sig00 About the current lighting of clouds : I admit that it is very simplistic but it has at least the advantage of being light for the cpu and the graphic card. Now it is possible to integrate the Harris lighting method with the existing code and have something perhaps not so far from his rendering. This is easy to do, I could make a prototype (err when I have a free moment). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Opengl rendering
I was thinking of using some pixel shader for one or two effects. This would be with the arbvp1 arbfp1 type shader. Of course I won't write them in assembler by would use Cg to produce the assembler source. The use or arb type program should limit the dependencies on standard opengl driver. But before starting anything like that I first want to know if : 1) people have program shader capable cards (ie FX5200+ or ati9500+) No need to code lot of things if only 5% of the user can see them. Normaly a good percentage should have correct cards (or will have in the next 6 month) but I feel that some still use olders cards. 2) you think it's a good idea to enhance a bit some visual aspect of Flightgear or you think that only simulation count and all the rest is useless eye candy ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re : Re: [Flightgear-devel] getting the best perfo with FG
BONNEVILLE David wrote: From the Quadro FX 3000 : * 60 Hz refresh * vertical synchro forced * no AntiAlias * no Anisotropic filtering * 1280*1024 * 32 bpp * visibility 5 meters --- Message d'origine --- De : Ampere K. Hardraade [EMAIL PROTECTED] : FlightGear developers discussions flightgear-devel@flightgear.org Sujet : Re: [Flightgear-devel] getting the best perfo with FG Date : ven 17 jun 2005 10:11:46 CEST On June 17, 2005 03:17 am, BONNEVILLE David wrote: Hi again people, problem solved ! :D I've just recompiled the latest cvs of plib, simgear and FlightGear, turned on the threads flags, and now I have a FG running up to 60 fps (i have forced the synchro with the vertical refresh). Cuold somebody explain me the way to tune FG options to get the best perfo ? visibility, threads, dynamic terrain loading ... Thanks David Well, 30 fps isn't that bad in my opinion, considering I only have 15 fps if I am lucky. What other options did you use beside vertical synchronization? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Your 60 Hz refresh seems too low, you should try 80-85, it will be more confortable for your eyes. But now that your fps is maxed you want to know how to lower it ? ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re : Re: Re : Re: [Flightgear-devel] getting the best perfo with FG
BONNEVILLE David wrote: I forced 60 Hz because I will use a projection system ;) Well for the moment, I don't think I need to lower my fps, but maybe, what would be nice is if I could force FG to run at a given fps which prevents me from little freezes... ;) David --- Message d'origine --- De : Harald JOHNSEN [EMAIL PROTECTED] : FlightGear developers discussions flightgear-devel@flightgear.org Sujet : Re: Re : Re: [Flightgear-devel] getting the best perfo with FG Date : ven 17 jun 2005 10:45:48 CEST BONNEVILLE David wrote: From the Quadro FX 3000 : * 60 Hz refresh * vertical synchro forced * no AntiAlias * no Anisotropic filtering * 1280*1024 * 32 bpp * visibility 5 meters --- Message d'origine --- De : Ampere K. Hardraade [EMAIL PROTECTED] : FlightGear developers discussions flightgear-devel@flightgear.org Sujet : Re: [Flightgear-devel] getting the best perfo with FG Date : ven 17 jun 2005 10:11:46 CEST On June 17, 2005 03:17 am, BONNEVILLE David wrote: Hi again people, problem solved ! :D I've just recompiled the latest cvs of plib, simgear and FlightGear, turned on the threads flags, and now I have a FG running up to 60 fps (i have forced the synchro with the vertical refresh). Cuold somebody explain me the way to tune FG options to get the best perfo ? visibility, threads, dynamic terrain loading ... Thanks David Well, 30 fps isn't that bad in my opinion, considering I only have 15 fps if I am lucky. What other options did you use beside vertical synchronization? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Your 60 Hz refresh seems too low, you should try 80-85, it will be more confortable for your eyes. But now that your fps is maxed you want to know how to lower it ? ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I see... There is something weird somewhere in the code, don't know if someone has allready investigated that or perhaps it is simply by design but those freeze are a real pain. The fps can drop by 50 or 90% for a few frames for no reason. Is it caused by the 360 scan done every 500 frames, or some side effect of the autogen or perhaps some other piece of code (atc, ai, fdm, etc) ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Shadows
I have started to add some volumetric shadows in Flightgear. It uses the standard stencil method to count shadow volume (let me know if you want an implementation without stencil, it can also be done with the alpha buffer). A few days ago I thought that it would be overkill for the processor or the graphic card to add this effect, but with a few optimisations the impact on frame rate - while still noticeable - is acceptable. I can render the Concorde with a debug build so all is not lost if your computer is not 10 years old. Some screenshots here : http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html Let me know what you think of that. nb: only the AC is casting shadows atm, I still need to verify how are handled other objects in the scene graph (tile objects, AI objects, etc). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: Finally, there is shadow in FlightGear. =) Couple of questions: Do the authors of the aircrafts have to specify the objects that can cast shadow, or is it all done automatically? It's automatic. All sub models of the aircraft (the ssg Vtx nodes) are preprocessed to extract the edges used by the shadow computation. On aircrafts that have multiple level of details, such as the MD-11, majority of the objects are made invisible. If these invisible objects cast shadow as well, it might produce huge overhead. Is your code intelligent enough to leave these invisible objects out of the calculations? This case is handled, I check the value of the ssgSelector in the object tree so select and range animations are correctly rendered. Unlike other aircrafts where everthing is put into a single mesh file, the A380 model is split into multiple files to allow meshes of different format to work together. Does shadow work on the A380? It should be ok if all your files are tied to the aircraft branch in the scene graph. Finally, what is the minimal graphic card requirment to be able to see shadow? It's hard to say, I just changed my graphic card but with the previous one - a Ti 4200 - I was not under the impression that I was fill rate limited. But the cpu has some impact too. There is a few computation needed to determine what to draw. The result of this computation is cached and updated when needed (when the sun moves or when an animation is doing a rotation for example). At the end it all depends on the model used, the Concord has like 30.000 polys, the c172p has less than 2000 polys. Dave Culp wrote: Does the canopy frame cast a shadow on the cockpit interior? Yes ;) Do transparent surfaces cast shadows? ( I don't mean to be annoying, just curious. This would add a whole new level of realism to 3D cockpits :) I didn't do anything special for transparent surface atm. So yes they cast shadows but I can't tell if this is a good or a bad thing. Martin Spott wrote: Do you need _any_ changes to the aircraft models (like Melchior did for the BO-105) or does it just work right out of the box with the existing models ? It's a bit early to reply that question. Perhaps we need to make the current model shadows conditioned by a property so that we have either the volumetric shadow or the one from the model. Anyway, this looks really great and I think your effort is definitely worth being added to FG, maybe switched off by default - for users like me :-) with a property to toggle it on demand Yes of course it will be optional ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: Forgive my annoyance, but here are a few more questions. =) First of all, I am seeing a potential problem when the sun is below the horizon (during dawn and dusk) and doesn't cast any shadow onto the ground. Does your code handle this special case at the moment? If so, how? Shadows must be disabled when the sun is below the horizon because of course there should not be shadows (or if we want shadows we could use the moon to replace the sun but this is not usefull atm since the night lighting is too dark, we could calculate the light casted by the moon depending on its phase but I am not sure it's worth it in a non military simulation) and also because drawing horizontal shadows for all scenery objects could kill the frame rate for fill rate limited cards. The sun-angle property is used to switch shadows on/off, it is also used to compute how much we need to 'darken' the background. Secondly, do objects with illumination (such as the flame from the f-16's exhaust) disrupt shadows? We have two problems here. First the flame will cast shadow because the geometry is like any other light occluder. Second the flame will be shadowed. The first case can perhaps be solved with some tag in the object to tell it not to cast shadow (a kind of 'noshadow' branch in the object tree). I don't see a simple solution for the second case, but perhaps it's not a real problem if the emissive light is hight enought, the shadow could be hardly visible. Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? I don't think it's possible. In modern games that do shadows the scene is rendered at least two times. In the first pass the scene is rendered with only ambient term. Then shadows are computed in the stencil. Then the second pass is done with all lightings (ambient term, lights contribution, specular term) with stencil test enabled to touch only non shadowed parts of the scene. This is the way to do correct illumination. In FG there is only one light and nearly no specular effect visible so the rendering is a bit different (in order not to render the scene two times). First the scene is rendered as usual with full lighting (ambient, light, specular), then shadows are computed in the stencil, then the stencil mask is blended on the screen to darken the shadowed parts. So to be clear for shadows I darken the pixels on screen, if we use the same technique for spotlight that mean we will lighten pixels, this will produce really bad result in totaly dark scene. And the same effect could be done with a cone, just using another blending equation. To have real lights in the dark the stencil should contain the spot volume, the scene should be rendered with normal night illumination outside the spot, then the scene should be rendered again with day light illumination inside the spot volume. I don't know if I am very clear... Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: msvc7.1 compiling problem
eagle monart wrote: thanks for info Fred , I used FG-ProjectFiles-msvc71.zip now i ve some link errors. I uploaded to : http://s22.yousendit.com/d.aspx?id=0FSJCS4G5NWHA0GOYE6BEZKZRM ( I wanted to see 3d clouds before next release :) ) You need to update your project files and add the new source files in simgear and flightgear projects. For the clouds and from my memory you'll need to add : environment/visual_enviro.cxx, scene/sky/bbcache.cxx, scene/sky/cloudfield.cxx, scene/sky/newcloud.cxx in simgear and environment/fgclouds.cxx in fg. But other files were added too in flightgear, you should check that all sources are included in the VC project. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: msvc7.1 compiling problem
eagle monart wrote: I have some visual problems in FG. I comPiled the latest source in msvc71 and i dont know these problems caused by msvc compiling first I wanted to talk about 3d clouds ... They are beatiful and also faster then I expected ...Its like flying in heaven)) but there is a huge gap between cloud felds. I played 3d cloud options in gui but these options only affect cloud details. I have wrong settings or some compile error in msvc ?? here are some screens http://www.geocities.com/fgscreens/fgfs-screen-006.jpg http://www.geocities.com/fgscreens/fgfs-screen-009.jpg Yes I should change that. What you see is indeed the first cloud demo and so the clouds here are hard coded, the problem is the like you have a 50 km2 cloud field but only 1/4th is filled with clouds. also when i change weather settings for example to thunderstorms 3d clouds gone missing... and after that nothing reenables 3d clouds ( i change settings of 3dclouds in gui also change weather , reset sim.) You are missing the cloudlayers.xml file in your data directory. You should also have a line like : environment config cloudlayers include=cloudlayers.xml/ /config /environment in your preferences.xml other problem is about strange rectangles in sim... I ve the same problem even in 0.9.8 release compile.. i can see these rectangles almost everywhere in clouds , on the sea and on the ground. here some screens http://www.geocities.com/fgscreens/fgfs-screen-011.jpg http://www.geocities.com/fgscreens/fgfs-screen-002.jpg http://www.geocities.com/fgscreens/fgfs-screen-005.jpg First time I see that, could it be a problem in the texture file ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Andy Ross wrote: * Stated exactly: the silhouette is a subset of triangle pairs sharing an edge where one triangle is front-facing with respect to the light source, and the other is back-facing may be on the silhouette. There is a pre process step where I look for the 2 triangles that share an edge. For rendering we only consider triangles facing the light. For each of its 3 egdes we check if the neighbour triangle is facing the light or not. The edge shared by 2 triangles facing the light is not a silouhette edge, if the neighbour triangle is not facing the light (or does not exist) then this edge is a silouhette. The problem is that detecting this silhouette (or at least an approximation) in a situation where the object and light source can have any orientation is a big mess, and I never found a good way to do it. Lots of really complicated code got me nowhere. The idea is to use a light in model space, not in world space. So if the object move it's like if the light was moving in the opposite direction. When I compute the silouhette for an object I climb the scene graph to find all the ssgtransform node and then I use the inserve matrix to rotate my light vector. The translation part of this matrix is nullified since the sun if far way I do as if the sun was moving with the object. The silhouette computation is only done when my sun vector change enought and I cache the list of silouhette edges so the cpu is not too stressed every frame while nothing changes. Basically, the whole experience convinced me that a shadow buffer approach, which is *much* simpler conceptually (just draw the thing into a texture from the point of view of the light source), was a better idea. Shadow buffers don't need the really complicated silhouette optimization work to make them run fast. It is true that shadow buffers don't work for self-shadowing objects (shadow of the vertical stabilizer on the wing, etc...), though. Andy I started a prototype before using hardware shadow maps. You are right it's a lot simpler, but it can't run on all hardware (and nvidia don't have the shadow ambient extension so shadows would be black...) and I think that shadows should be available to all users. And of course shadow maps a problem of pixelisation. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Short Reference Document error?
Jon Berndt wrote: I think you are making a disingenuous assumption, here, on what I am saying. It IS correct and clear for*European*users, yes. All that I did to the PDF document was to add a _note_ in the appropriate section in brackets that says: [U.S. keyboards use . instead of ,] Now I don't understand. Flightgear uses a key, its the same for all contries whatever keyboard you use. What changes is the position of this letter on the keyboard, not the key because we are not using the raw keyscan. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: Finally, is there a potential for this technique of generating shadow to be used on generating the effects of spot lights (eg. landing light, taxi light, logo light, etc.)? You are a genius, forget my previous reply. We can't lighten pixels from the framebuffer because of the low precision (8 bits) but we can of course darken them. Algo (works better at full night) : 1) render the scene and all non emissive geometry with a 'day' ambient term 2) render all lights (or emissive geometry) and update the stencil buffer ( stencil := 1) 3) render a quad on screen to darken everything where stencil == 0 with 1 3 the scenery goes dark/black as usual with 2 the scenery in light stay illuminated Its quasi free, simple, support a million (fake) spot light ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Main Airports Conflict withGraphic Card6600GT !!!
Gerard Robin wrote: Le mercredi 22 juin 2005 à 09:49 -0500, Alberico, James F a écrit : The hardware is able to do it, with the old driver 6229 it can. But the average performance is less, because that driver does not suit to these new GPU with GPL 2. May be a bug in the last NVIDIA driver. I could explain the problem if i was more accurate about GL and that light animation. -- Gerard For what it's worth, additional info on this thread: I saw the same bad performance on an Fx 3400 with new driver. I was not able to find any properties or run options to alleviate the problem (10 fps or less, when looking at an airfield -- running with enhanced lighting OFF). Gerard's fix (comment out the call to get_vasi_lights_root()) worked great. All is smooth now. Thanks, Gerard! Jim Thanks, And i worry than kind of solution. It is only a 10 lines code in Simgear which slow the world of NVidia, what a pity ! :=) change : glPolygonMode(GL_FRONT, GL_POINT); with glPolygonMode(GL_FRONT, GL_LINE); in render.cxx, its not perfect but you will be able to see lights without fps loss. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lights was: Shadows
Roman Grigoriev wrote: I would like to add support for them, just in the proper way. That's why it is still in my TODO box. It's just the time ... Here are a few things to consider: 1. Move the Shader class over to a new file (probably shader.cxx and shader.hxx) in SimGear/simgear/screen 2. Use the SimGear extension header files (you will probably need to extend them (see FlightGear/docs-mini/README.extensions) Erik I think that you are right Erik! But I propose a technique and you Erik - fgfs maitainer, so you can decide where to put this classes I second what Erik said, extract your code from render.cxx and put them in separates files. Then it will be easier to use your code for new effects, no need for me to reinvente the wheel :-) since you allready have exprerience with shaders. I think this shader method have advantages that shaders are in text files that can be changed by users without compiling all simgear and flightgear sources. Good thing. This framework add you functionality to optimize shaders to you current architecture (NV/ATI or other machines) so we have higher framerates. because you can specify shaders that can be loaded to NV only or ATI only and during fgfs startup we can detect archtecture and load proper shader. for example using NV shaders on NV hardware can get 20% boost to framerate. and detection of hardware is so easy you can only querry about NV_fragment_program extension - so you have NV hardware overwise -ATI or other videocard. Ok, but we must at least have a generic hardware independant shader (arb or glsl). But I don't know about SGI - does this architecture support shaders at all? So I think that if you add new classes to simgear people can start using them and mekes things better. Roman And of course shaders don't replace existing code (they can replace existing effect), they are allways optional. I'll have a deeper look at your code in a few days, I need to finish the shadow code atm. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Paul Kahler wrote: Oh does that sound like a bad hack. What happens to objects that have specular highlights? Would the illumination be as if the sun were shining rather than the spotlight? Lighting is important, but this doesn't seem like it's physically correct at all. OTOH, fake lighting is better than no lighting ;-) Paul You are right, this is totaly incorrect lighting. For correct lighting and correct specular we should use an Opengl light for each light source. The problem is that opengl is sill slow for spot lights, and there can be more than 100 light around an airport. Of course opengl can not handle more than 8 lights in hardware (and I am not sure that it is still realtime on lot of machines) so we would have to switch ogl lights depending on the position of objects or ground geometry... a bit overkill I think. Perhaps can we use a real ogl light for the aircraft landing light and fake light for the airport lights, and since the view is centered on the aircraft the hack could be good enought. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Lee Elliott wrote:
On Sunday 26 Jun 2005 23:03, Vivian Meazza wrote:
Frederic Bouvier
2 stranges things that I know are inherent to the shadow
volume technique
1. even when surfaces are smoothed, the shadows are hard and
apply to a whole quad when a fuselage shadows itself ( try
the A320, look at the airframe and press t to see what I
mean ).
Cool I didn't know about time warp ;) I'll see what I can do for that
problem.
What we see is the projected shadow that is received by the caster itself.
2. transparent surfaces ( the suspension chains of the
bridges, or the metallic structures ) produce filled
shadows.
There is no real solution for that because it's the surface that cast
shadow and not the texture.
Yes, I can see that. The markings on the Hunter are on
separate transparent object: these throw a shadow. It seems as
if I'm going to abandon that method if shadows are to be
usable with that model. Pity; it saves a huge amount of
artwork and texture.
Don't change your model for that. If it's not a problem to rename your
objects you can add
a 'noshadow' prefix to your markings, they won't caste shadow ('mydecal'
= 'noshadow.mydecal').
The edges of the shadows are a bit too
hard; a little penumbra would be good
ahem ;) so you have too much fps ? this can be done with a fragment shader.
Let wait the hardware to catch up a hit, and we could have
clouds and mountains casting shadows ;-)
We could use a simple ovale for clouds, it's just that the shadow would
be as dark as the other type
of shadows - perhaps too dark then but not sure.
Nice if aircraft could throw shadow on cloud.
I didn't enable writes in the depth buffer while rendering clouds,
that's why they don't catch shadows.
I can't remember if that gave a visual glitch or if it was just for
performance.
Altogether it's a nice enhancement.
V.
thanks ;)
Yep - I've used the same texturing technique on a few a/c as
well:( Then again, I've already stopped using it:) It did save
a lot of texture space though.
Re the 1st problem Fred referred to, it seems to happen when an
object puts itself in shadow. Shadows cast by other objects
seem to be ok. Generally, the old shading code did a good
enough job of shading each individual object in a model,
according to the sun pos, so I wonder if the new shadows might
work better if they were only applied to other objects, and let
the old code shade each individual object...
LeeE
I'll check that.
Harald.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regarding buildings (was Shadows)
Martin Spott wrote: Frederic Bouvier wrote: Quoting Martin Spott : Look by yourself : http://terraserver.microsoft.com/image.aspx?T=4S=12Z=10X=706Y=5191W=3 Oh, nice I think we urgently need a way to inject user-submitted landcover details into the process of scenery generation Curt, do you see a chance to accept geo-referenced shapefiles from users ? Martin. Since we are talking about scenary generation... Has no one wrote a converter from Taxidraw output to .btg ? Am I the only one frustrated because I can not (simply) edit a few airports and use the result imedialty ? From the terragear source I find it quite easy to do that, so if nothing exists I will write the converter. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Ampere K. Hardraade wrote: On June 29, 2005 09:24 am, Simon Hollier wrote: No 3D clouds on an r200(9200) with the latest ATI(8.14.13) driver : No suitable pixel format. Shadows work nicely though : Simon I don't see any evidence of a shadow with my graphic card (ATI 9200SE). May be my graphic card doesn't support it. I don't see any Enable Shadow option either. Ampere The options to enable shadows are in the rendering dialog. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Ampere K. Hardraade wrote: On June 30, 2005 12:46 pm, Harald JOHNSEN wrote: The options to enable shadows are in the rendering dialog. Harald. Strangely, the option is not there. Do I have to run ldconfig after I compiled and installed SimGear? Ampere You need to sync the data or at least data/preferences.xml and data/gui/dialogs/rendering.xml Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: About 3D Clouds
Jon Stockill wrote: Melchior FRANZ wrote: BTW: I just noticed that volumetric shadows work for me with Linux 2.6.11.7 + nVidia 6629, but not with Linux 2.6.12.2 and driver 7664. With the latter, the whole screen goes darker, and no other shadows are visible. But since the newer drivers lock the machine if RenderAccel is activated, switching back is a good idea anyway. I upgraded to 7664 a couple of days ago, fired the sim up, and the machine promptly overheated (it's been a bit warm here for the last couple of weeks) looks like the fan stopped on the graphics card, so that just died when asked to do anything. I swapped it for my old card (also nvidia) and noticed that runs with no shadows, but a darker screen as you describe - I put it down to the card being less capable, but I think I'll downgrade the driver and try again. Can you set /sim/rendering/multi-pass-clouds to true in property browser for a few frame then to false again and see if that change anything ? I forgot to initialize something... Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Andy Ross wrote: Frederic Bouvier wrote: The stencil test is always succeeding. Is there a possible interaction with the multi pass clouds. Or maybe there is no stencil buffer. Dumb question: are we sure we are asking for a stencil buffer? In both the glut and SDL implementations? Andy Apparently there is no stencil in 16 bpp mode. Can someone check if there is an alpha channel in 16bpp mode and how many bits in it ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Andy Ross wrote: Frederic Bouvier wrote: The stencil test is always succeeding. Is there a possible interaction with the multi pass clouds. Or maybe there is no stencil buffer. Dumb question: are we sure we are asking for a stencil buffer? In both the glut and SDL implementations? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] gui colors
Melchior FRANZ wrote: It would be nice if we could make the dialog colors user settable. I've abstracted the process of reading colors from the property tree out into a function in dialog.cxx: void getColor(const SGPropertyNode * prop, sgVec4 color); This reads a colorred.../redblue.../color structure from a property node and merges it into the color array. (props may be zero.) But should this rather go to fg_props.cxx!? So that colors for different purposes could be read by it, too, such as HUD color, or splash screen progress text color (not that this is an important feature)? Yes make the properties readable for the different rendering code. The plan is to read the dialog background/foreground color from preferences.xml (or gui/color.xml) and make it changeable at runtime, because the light blue dialogs are suboptimal for some cases (flying over reddish mars, night, otherwise dark sceneries). It can be quite unpleasant if you are flying in dark/night scenery, in a dark room, and then a big bright dialog pops up. So there will be one customizable color theme and 2 or 3 preset themes like on some TV (old school, mars theme, acid theme, etc) ? Before this would be possible, other problems would have to be solved, though: It turned out that (1) too many dialogs don't use FGDialog at all (e.g. property picker), and (2) our gui font doesn't look good in bright color dark background. :-/ m. Perhaps the font should be selectable too, but this will surely add a few problems in the layout of some dialogs. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Error compiling GPSsmooth
Richard Bytheway wrote: I am getting a compilation failure in GPSsmooth: (System is Cygwin on W2K, Athlon. FlightGear and SimGear source are CVS from this morning) Error is below: -8 [EMAIL PROTECTED] ~/FGFS/FlightGear/build/utils/GPSsmooth $ make if g++ -DHAVE_CONFIG_H -I. -I../../../source/utils/GPSsmooth -I../../src/In clude -I../../../source/src -I/usr/local/include -g -O2 -D_REENTRANT -MT gps.o -MD -MP -MF .deps/gps.Tpo -c -o gps.o ../../../source/utils/GPSsmoo th/gps.cxx; \ then mv -f .deps/gps.Tpo .deps/gps.Po; else rm -f .deps/gps.Tpo; exit 1; fi In file included from ../../../source/utils/GPSsmooth/gps.hxx:2, from ../../../source/utils/GPSsmooth/gps.cxx:7: ../../src/Include/config.h:194:1: warning: WIN32 redefined In file included from /usr/include/w32api/windows.h:48, from /usr/include/plib/ul.h:113, from /usr/include/plib/sg.h:29, from /usr/local/include/simgear/constants.h:44, from ../../../source/utils/GPSsmooth/gps.cxx:3: /usr/include/w32api/windef.h:29:1: warning: this is the location of the pre vious definition if g++ -DHAVE_CONFIG_H -I. -I../../../source/utils/GPSsmooth -I../../src/In clude -I../../../source/src -I/usr/local/include -g -O2 -D_REENTRANT -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o ../../../source/utils/GPSs mooth/main.cxx; \ then mv -f .deps/main.Tpo .deps/main.Po; else rm -f .deps/main.Tpo; e xit 1; fi g++ -g -O2 -D_REENTRANT -L/usr/local/lib -o GPSsmooth.exe gps.o main.o - lsgtiming -lsgmisc -lplibnet -lz /usr/local/lib/libsgtiming.a(timestamp.o)(.text+0xd): In function `_ZN11SGT imeStamp5stampEv': /home/richard.bytheway/FGFS/Simgear/build/simgear/timing/../../../source/si mgear/timing/timestamp.cxx:74: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make: *** [GPSsmooth.exe] Error 1 -8 It appears to be in the link to the SimGear timing routines. I have checked that there is only one version of SimGear installed (OK), and double checked that I have the latest SimGear from CVS (OK), and now I am lost. Any offers? Richard timeGetTime is defined in WinMM.lib Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: I just wonder about the fact that every alpha objects make the shadow, which is behind, disappeared (Vivian did notice it). Every AC3D users can notice that problem = the object hierarchy must be built in order to make the alpha objects (canopy, propeller disk ...) at the end of the hierarchy. If it is not, AC3D 3D-view don't show the objects which are behind these alpha objects. May be that could be an explanation and help to solve that ugly effect. Is it any hierarchy in FG view processing ? if yes, may be the shadow must be put on the top of the hierarchy Transparent objects are a pain to deal with. In a perfect world all semi-transparent objects should be draw *after* all opaque objects, they should be *sorted* by depth and drawn back to front - or if not sorted they must be draw with depth writes *disabled* (this is for true transparent surfaces, not surfaces that use an alpha mask to build their shape). The shadow post-process should be done between the drawing of opaque objects and the drawing of transparent objects because we don't want that a totaly transparent triangle stops the light (and atm it *is* stoping the light because it has changed the zbuffer). As you said modelers usually sort their model graph to handle that problem but the shadow code need the whole scene because it uses the screen zbuffer. I don't see a clear solution to this problem. BTW: i have renamed every alpha objects noshadow.. You can now use the noshadow animation in your models and reference all the parts that should not cast shadow. Examle for radio-medium.xml : animation typenoshadow/type object-nameWires.1/object-name object-nameWires.2/object-name /animation Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: Le dimanche 10 juillet 2005 à 19:42 +0200, Frederic Bouvier a écrit : I noticed another artefact : http://frbouvi.free.fr/flightsim/moving-shadow.gif ( animated gif ) When moving toward the blue building, the shadow on the nearest building face is moving and it seems dependant on the viewer's position. -Fred I introduced a polygon offset in my last patch (to reduce some flickering), perhaps the value is too high. If you are above 50m the effect is less visible (since we switch the near/far clip planes when above/under 50m). I can reduce the offset a bit. Yes i did noticed it. And i do not get shadow from the usual objects which are randomly situated on the scenery = farmhouse, house, apartment. Yes it's on my todo list. The object noshadow definition (name or animation) does not keep off that object getting the shadow from an other object. will it be any way to make it: noshadow means == not receiving shadow, in addition to the existing not transmitting shadow No that is not possible. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: Le mardi 12 juillet 2005 à 07:45 +0200, Mathias Fröhlich a écrit : /animation Yes. As I last looked into the shadow code, there was some heuristic based on object names which made some surfaces 'noshadow' ones. That heuristic gives me false positives with the F-18. I would vote for dropping that heuristic completely and apply the noshadow where apprioriate. Greetings Mathias Do you mean that using noshadow.myobjectname or animationtypenoshadow are the same and the consequence is noshadow.myobjectname is not useful ? noshadow.myobjectname or animationtypenoshadow are really the same. But I think Mathias is talking about the fact that some object parts were silently not casting shadows based on their name. Before the noshadow animation exist I was checking for names like 'disk' for example so a 'propeller.disk' was not casting shadows. But in the current cvs only the 'noshadow' name and the noshadow animation are used. Sorry for the confusion, I realize that I did not talk about this hidden 'feature'. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery files triangles
While looking at the scene graph I saw that the .btg files are generating a lot of leafs. This is not new, but perhaps it is becoming worse each time the source data resolution used to build the tile becomes finer. I have added a few traces in simgear's sgBinObjLoad functions, an example : sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/942058.btg) get_wgs84_nodes.size=1543 get_tris_v.size=0 get_strips_v.size=0 get_fans_v.size=928 leafMap.size=12 local_terrain-getNumKids()=928 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/942043.btg) get_wgs84_nodes.size=1671 get_tris_v.size=0 get_strips_v.size=0 get_fans_v.size=1045 leafMap.size=14 local_terrain-getNumKids()=1045 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/KNUQ.btg) get_wgs84_nodes.size=3500 get_tris_v.size=43 get_strips_v.size=3 get_fans_v.size=0 leafMap.size=33 local_terrain-getNumKids()=46 sgBinObjLoad (F:/FlightGear/data/Scenery/Terrain/w130n30/w123n37/KPAO.btg) get_wgs84_nodes.size=685 get_tris_v.size=11 get_strips_v.size=3 get_fans_v.size=0 leafMap.size=10 local_terrain-getNumKids()=14 We can see that : - tile objects use only fans - airport objects use strips and regular tris - for an equal number of triangles a tile object uses 50 times more leafs than an airport object ; - the number of leafs from a tile has nothing to do with the number of materials ( leafMap ) When the leafs are inserted in the scene graph they are sorted by materials, so my concern is not about OpenGl material switching but rather on the number of calls needed to draw a few triangles. The use of display list has divided the number of calls to opengl, that's why there was a substancial gain. If we do one call per material we can divide this number of calls by 50 for tile objects. And yes I know strips or fans are supposed to be faster than triangles, but no this is not true in the current situation (1000 calls to draw a 10 triangle strips/fans can't be faster than 10 call to draw 1000 regular triangles). Is there a reason why we are using fans and not strips for tile objects ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
Erik Hofman wrote: Harald JOHNSEN wrote: Is there a reason why we are using fans and not strips for tile objects ? http://baron.flightgear.org/pipermail/terragear-devel/2005-June/001219.html Erik lol ok, I didn't saw that ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: Yes i have seen it. (my question was rather to get some answer about the next noshadow updates depending on Harald to do list). That property should be like select and any others property. I never thought of it as a dynamic selector, maybe I am wrong. Is it any technical reasons which keep off to do it? I think it can be done, we could have a condition for dynamic selection in addition to the current static form. If yes, that will reduce the advantage of that noshadow property. Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: [...]As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. Displaying an animated aircraft won't be easy. Animation code in xml file is refering properties from the FG property tree (ie the user property tree) so we need a way to change some properties during the rendering of a MP aircraft. Perhaps can we do this with a temporary aliasing in the tree so that some branches point to the MP aircraft ? To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. Good idea, with that we can handle all special cases. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. There is also some data/properties that can be guessed depending on the current 'action'. We can do a good guess of the different surface position for some standard manoeuvres. We can draw a smooth gear up/down animation without knowing the real value of /gear/gear[0]/position-norm for example, and if we were using this value it would be impossible to have a smooth animation because of the latency of the network. Of course in a client server configuration there is also optimisation to be done based on distance. No need to send any other data then position.velocity if the other MP aircraft is just a point on screen or on the radar, and no need to send any data at all if it is 1000 miles away. In the future we could also consider to have one server handling all AI objects for the clients to have a coherent environment. Imagine that you are training landing on the Nimitz with your friends but the ship is at a different position on each client. This would be very weird. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Vivian Meazza wrote: Multiplayer models are already animated - gear goes up/down correctly. The problem is that all models are controlled by the receiving player, not the transmitting one. Shouldn't be too hard to fix. Is this the right approach? Could we include e.g. the gear up command in a message, and let the rx system sort it out? That's almost what happens now. Smooth transitions already happen, but, as I said, under the control of the rx player. Yes, so we can say they are not animated atm. receiver property tree using the c172p model root0\ |-position/* |-surface/* |-other properties 'player' 1 property subtree in receiver memory using a Concorde model root1\ |-position1/* |-surface1/* |-eof 'player' 2 property subtree in receiver memory using the ufo model root2\ |-position2/* |-surface2/* |-eof So on the receiver side the c172p.xml, concorde.xml and ufo.xml animation code point to the root0 property tree so all animations will reflect the receiver plane animations. An apparent simple hack is to change the root while rendering other 'player' models but this will break because the root1 root2 don't contain all the necessary properties to render a model. That's why I was thinking of doing this while renderering a model : root0\ |-position/ = point to /root1/position1 |-surface/ = point to /root1/position1 |-other properties So the receiver should manage a subset of the property tree for each transmitters. Concerning animation command I won't pretend that it is the way to do it in FG, but this is done like that in all MP games. Sending keyframe animation sequence is a waste of bandwith and worse of all it gives ugly results. This can work on a local network with a 50 ms ping but not on the internet with a 250ms ping. But this is only an optimization and has no impact on the design of the mp code. Very good idea, and weather. I don't suppose clouds would be easy? Vivian Cloud movement is based on wind direction and speed so it should be the same at all time if the initial situation is the same. To construct the initial situation I think it's enought to send the cloud layer information and the delta time during the connection to the server. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: I just noticed that when one is inside an object, or the shadow volume of an object, then the shadow casted by that object is not visible. Here is an example: http://www.students.yorku.ca/~ampere/fgfs-screen-010.jpg Ampere It is because the viewer is inside a shadow volume, this breaks the so called zpass rendering. The solution to that is to use the zfail rendering for the concerned shadow volume. It's easy. What is not is to detect this situation in some efficient way and since the zfail rendering is a lot slower than the zpass we don't want to render too many volumes with zfail. It's on my todo list. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. I am not sure I understand this example, or perhaps I presume that what is visible should cast shadows ;p Anyway the condition is available now. The old form without condition still exists. I have also made a few changes for tranparent objects. In the rendering dialog there is a new option near the aircraft checkbox. When enabled the rendering of the aricraft transparent parts is done *after* the shadowing code. In other words the transparent parts won't hide shadows as it should be. This is how things should be and this option should be enabled by default. But. We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder wrote: 1) out of reach [...] So the question is: How can I easily calculate the distance and how many nautical miles are out of reach (thinking of e.g. radar systems) ? I think the range should be user configurable. For VFR we have a nearly hard coded limit of 10 NM from the metar, and at that range I don't think one can really see another aircraft. If your plane has some TCAS instrumentation then you will need perhaps 20 to 40 nm. If you are a traffic controler you want more than that. 2) chat messages [...] protocoll supports chat-messages and the ATC-module has functions to queue and display them on screen. So it should'nt be too hard to combine them and enable chat-messages. Somebody willing to give it a try? As Pigeon said, make that a separate window, because the ATC line is allready nearly impossible to read ;) It should not be hard to code but the atc code is not good for that (anyway it does not queue messages). 3) artificial life at airports The server gives a lot of opportunities. One of the first things which came to my mind was artificial traffic at airports. It should be fairly easy to write clients in any (network capable) language which do simulate a client. This can be simply a helicopter standing near a hangar or even a plane flying around an airport. This would disburden fgfs itself (since it does not need to create AI traffic itself) and allow an arbitrary number of artificial clients, each serving it's own airport (or whatever area), bringing life to many areas of the world without manipulating fgfs itself. The idea is interesting, but at the same time FG allready include the infrastructure to spawn entities and animate them, and when we will add new animations like trains, forest fire or gates I would like to have them even in the standalon version of FG. If you want to 'inject' new entities via the server you could just launch a copy of FG without rendering near your server and choose an ai scenarii to load. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Dave Perry wrote: This bug showed up about 10 days ago with an update from cvs. Any ideas what is broken? Regards, Dave Perry I have started to investigate that problem but not found anything atm. I can reproduce the bug in the same situation as you. FG is *not* freezed. All (?) is working correctly except the screen is not refreshed for some strange reason. The main loop is executed, the render code is executed, you can do a clean exit with escape + enter. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
smoke was Re: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet
Vivian Meazza wrote: Dave Culp ... snip ... The present system makes smoke/contrails by releasing AI objects rapidly. There are three problems with it now: 1) Orienting the objects properly. Only applies for long (i.e. cylindrical, rectangular) models. 2) Matching the release rate to the airplane's speed. 3) Making a smoke model that merges well with the others. I've heard (on this list) that this may be a plib limitation. It may require the use of a different visual model, like billboards or particle fields. On the other hand, maybe a whole new tactic is needed. I think Harald is working on this as an offshoot of his 3d clouds. I'm quite sure we can't do better with the AI ballistic approach as it stands. Vivian Not really working on it atm becaue I need to advance on the shader code and in the meantime I did some profiling on FG, but yes I was thinking of adding a 'smoke' animation that can be parametrable and with plausible physics. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Start up questions
Craig Martin wrote: Jim, when I open a dos window, and type fgfs, then hit enter, this is what I get; Base package check failed...Found version [none] at :\FlightGear Please updrage to version: 0.9.8 Hit a key to continue. I think the flightgear directory has to be at the root levelI'll try it. But if it is something else, please let me know. H...remembering DOS, I think there is a PATH command I could use also... Please advise. Thanks in advance, Craig Add the --fg-root param in your command line, for example : fgfs --fg-root=\FlightGear\data Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Andy Ross wrote: Gerard Robin wrote: Being Nvidia and X installed , i continu to search a good answer : After many experimentations, I did not notice any change between 24bpp and 32 bpp. There is no difference between 24 and 32 bpp on NVidia hardware. Both of them give you a 32 bit 8:8:8:8 RGBA front and backbuffer, a 32 bit Z depth and (now) an 8 bit stencil buffer, for a grand total of 104 real bits per pixel. You can inspect the list of OpenGL visuals available using the glxinfo command line tool if you like. The real choice underneath the (glut or SDL) abstraction layer is much more complicated than a single number. The reason that this suddenly breaks with the new drivers is that the new drivers have a new feature: they can now support 16 bit color buffers even when the desktop is at 32bpp. But these 16 bit modes do *not* support 8 bit stencil, which is required for the shadow implementation. So it used to by that when FlightGear asked for a 16bpp stencil framebuffer on a 32bpp desktop, it got a 32 bit mode anyway. But now, the driver can actually fulfill the request, so it provides a mode that won't work with shadows. FlightGear asks for a default color depth of 16bpp, but it also asks for stencil; this is essentially a bug. These are not compatible requests on any modern GPUs, which only support 8 bit stencil in true color modes. Andy And I'll add that we don't ask for a stencil buffer when in 16 bits mode, perhaps we should omit this restriction. Then the driver would have a chance to make the right choice. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3DClouds versus 2DClouds
Gerard Robin wrote: Everybody agree with 3DClouds, it is beautiful. I think so. But, is any way to make the result realistic regarding the weather (fictif or metar it is the same problem). You will find here an exemple which makes unusable 3DClouds if we want the good reality. http://ghours.club.fr/2Dclouds-versus-3Dclouds.jpg You are right there is a bug here. The cloud layers don't update themselfs when the parameters are changed in the dialog. The change is applied only when reselecting the metar choice in the weather scenario dialog. I'll check that. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cygwin/Terragear/nurbs problem
Erik Hofman wrote: Buchanan, Stuart wrote: SimGear installed OK (I think), so I don't know whether I'm missing from timezone libraries or what. Any idea? /home/Stuart/SimGear/simgear/timing/timestamp.cxx:74: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status Are you running Windows? I think you need to link an extra library for Windows, but I'm not using it myself so I hope someone else can answer this question. Erik you need winmm.lib Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nojoy for simgear on amd64
Mathias Fröhlich wrote: On Donnerstag 11 August 2005 10:20, Erik Hofman wrote: Andy Ross wrote: There is a similar spot in FlightGear where something wants to use a pointer as an integer ID. I haven't checked these in as this is not really a good solution -- the ID needs to be guaranteed-unique. I just noticed there is even an id_t in sys/types.h on IRIX, is this common? I don't think so. The only type I know that is guaranteed to be capable of storing the whole pointer is a void*. But void* is menat to be not that pure address number in the properties, it is meant to store some arbitrary property, which is ok so far. But I believe that for our problem, it would be sufficient if we just convert that address to a string and take this string as an id. That saied how about something like stringstream s; s this; and then take s.str() as that id? Greetings Mathias Using strings add too much overhead for a general solution, void * could be better except that those pointers can not really be compared (if you want to use your id in a map you must have a operator that does not exist here). But those ID are not pointers, they are just random numbers so 'id = ++static_counter' is sufficient. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] crashes in GL
Jon Stockill wrote: Due to the death of the machine I was doing all my flightgear work on I'm currently trying to set up another machine so I can still build packages, but I've run into a bit of a problem. While my old packages work ok on this machine (it's not gonna win any awards for framerates, but it proves it works) the current cvs code segfaults on startup like this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18753)] 0x401861b2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 (gdb) bt #0 0x401861b2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 #1 0x401863f3 in glXCreateGLXPbufferSGIX () from /usr/X11R6/lib/libGL.so.1 #2 0x0846a17a in RenderTexture::Initialize (this=0x891d220, width=1, height=1075494657, shareObjects=false, copyContext=false) at RenderTexture.cpp:508 You are not supposed to have this width and height, in the bbcache.cxx code there is rt-Initialize(256, 256, true); Perhaps you can set a break point on the call in bbcache and then follow the execution step by step to check what happens. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Pulsing splash screen at startup (on Cygwin)
Richard Bytheway wrote: ... The correction should be in cvs soon, or you can change in SG/timestamp.cxx line 119: #if defined( WIN32 ) with #if defined( WIN32 ) !defined(__CYGWIN__) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML.cxx
Richard Harke wrote: I don't have the original post in front of me but if I remember rightly, just a couple of values from the object are needed for the throw. Why not copy them to local vars, do the XML_ParserFree and then the throw using the local vars? Richard Now that you talk about that, this is not a jsbsim problem only, there is the same sequence in easyxml, and that explain why there is nearly allways a crash when an xml file is malformed. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfaults with real weather fetch
AJ MacLeod wrote: On Thursday 15 September 2005 18:12, Lee Elliott wrote: since updating from cvs yesterday I now seem to get segfaults whenever I try to use real-weather-fetch. This has been happening with yasim A/C since some of Harald's changes a few weeks ago. Using a JSBSim a/c you will find (if this is the same bug) that FG runs, but visibility is set to 0 - selecting Metar from the appropriate dialogue box will set things correctly. Harald knows where the problem lies, I think, and has reproduced it on his own setup. Or have you found another bug? I must confess I've not updated from CVS for about a week now... AJ It's not forgotten, I'll send a patch in a day or two. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Determining range?
Dave Culp wrote: ... how do I get the distance from my current Lat/Long to another Lat/Long? There's a function in SimGear that does this. See SimGear/simgear/math/sg_geodesy.cxx for a function called int geo_inverse_wgs_84() This may be overkill for your application. Dave Don't forget to check the reference : http://williams.best.vwh.net/avform.htm (Aviation Formulary ) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Oliver Schroeder wrote: Am Tuesday 04 October 2005 09:26 schrieb George Patterson: I was not aware that it is possible to switch to another clients cockpit. However, if this really depends on properties which get not transmitted over the network yet, we should disable this in the upcoming release. Sending properties over the net is more complicated than sending some values. I will address this in a seperate thread in the next days. Some 3d models have conditional displays based on the view number. In internal view their often don't draw most of the external model to be fps friendly. A simple solution for that problem is to set the view number to 'external' when drawing MP planes. But this is not enought, 3d models should have LOD and handle correctly the fact that they can be used as MP/AI aircraft (some animation rules could be different then for the user aircraft). I'm not sure what we gain if you (fgfs respectively) can ping the server. If you only want to debug the transmitted data you can simply connect 2 clients directly, without a server in the middle. Note that you can only connect 2 clients directly, not more. If you only want to know if the server recognises your (or any other) connection, you can simply telnet to the server and see the list of it's clients. The telnet port is commonly CONNECT-PORT +1. You will spend a lot of your time replying to question on irc or lists when suddenly more and more people start to use the mp feature. Or you could give the user some feedback on what's happening. Is the host reachable, is the server launched, how many users are connected ? What the hell do you want me to do in a console ? Give the user the tool he needs or you'll spend you time doing the hot line. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways
Martin Spott wrote: ... It is no problem at all to convert a PDF into any other vector format but I've found it very difficult to define charcteristics that automagically can tell between runways, taxiways and other objects that happen to be part of the chart. You always have to spend significant manual effort to separate the data we need. On the other hand it might be worthwhile to spend this effort once we have a means to reliably convert airport layouts back and forth between vector layout and X-Plane format. Cheers, Martin. Except that the X-Plane format is just a bad hack todays and has reach its limitation. This file format does not handle taxiways or curves, or ground traffic or docking systems or usual airport buildings. It's just a soup of rectangles (except of course the runways and frequency informations). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways
Martin Spott wrote: Erik Hofman wrote: To my opinion the X-Plane format isn't qualified for accurate runway and taxiway layout. This is Harald's opinion as well as mine ! _But_: Our opinion on this format actually does not change it. Right ? And as long as FG sticks to rely on this X-Plane data it makes little sense to generate airports in a different format - as long as we are unable to convert back and forth. For example it would be a nice feature to automagically create outlines and a centerline from X-Plane data and create a set of overrides from FAA/SIA/whoever data. I can see two kind of airports in the Robin database : - those with detailed taxiways and apron : they have no more any taxiway description because the mass of little pseudo-apron used to make details and curves have replaced the one or two default taxiways ; - those without detaild taxiways; they have one or two taxiways paralel to the runways. So I have the feeling that we can not extract any meaningfull information from the runways data from this database, the side effect is that there is no need to convert from one format to another hypothetical format. Probably we are going to merge this data into a single set of airport descriptions in vector format for FlightGear. What are we going to do if something is being changed in Robin's database ? Are we going to maintain a parallel database ? Regards, Martin. We have 20.000+ airports in Robin base, we want to change 50 or 500 of them. I think we should keep Robin's database and use it as we use it today, and use a new database for the few airports we want to upgrade with a new format. Durk Taslma is using a network to describe the ground traffic pattern, we are no more talking about polygons. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
