Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: Lee Elliott [EMAIL PROTECTED] said: Changing the model would stop that working of course, as the geometry would've changed, but it's a quick and simple way of getting a 'lite' (er) version of a model, at least with regard to texture space requirements. Using the "reduce" function in ac3d and deleting a few objects I was able to reduce the 747 model almost 80% without remapping textures at all. Note that you have to experiment with reducing different parts of the model different percentages (the ctrl+z comes in handy for this kind of experimenting :-)). The result is a little rough up close, but from a couple hundred meters viewing distance it looks pretty much the same. Screen shot: http://www.spiderbark.com/fgfs/747reduced.png Best, Jim That model looks great! Although we had even more primitive model for greater distances (no textures, some aircrafts had even common this model, because of the similar shape) in Falcon. If you ask me, we shouldn't use textures greater than 128*128 when viewing aircraft farther than 1 mile. Can you please tell me the comparison between the number of vertices/polygons/textures before and after optimization? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Innis Cunningham [EMAIL PROTECTED] said: Hi Jim Are you working on a low poly version of the 747 for scenery work. Just a demonstration. If you saw the screenshot, that shows how far I got with about 3 minutes work. It could be better. I was working on it yesterday.Regrouping the fuse to use one texture and removing the wing and gear textures to reduce the load. You can do that if you have time. Might be just as good to reduce the texture to 128x128 or 64x64. I was planing to just apply a material to the wings, gear and horz stabilizer.Grey(silver) for the wings and stab and black for the wheels. I In a largely textured scene with the lighting the way it is in flightgear, you will get unsatisfactory results with material colors. Things tend to look white (or too bright) when directly into the light source. And black or too dark on the other side. have mapped the Southwest texture to the fuse and reduced it to 256x256 it is a bit grainey up close but ok from a hundred meters plus. You know, I'm not sure if we have to worry about using private carrier liveries from a copyright perspective. AFAIK Southwest is the first one...in fact I didn't notice the static model was Southwest until just now (duh!). Does anyone know about this? What we need to be able to do to put a few static A/C around is to be able to use the one model with multiple textures, as it is now you have to create a separate model for each different airline.This is going to lead to rather large scenery files. Eventually, yes. As I am rather new to AC3D I was wondering if you could answer a couple of questions. 1 How do you set the scale for the model.I have had a look in the docs and the program but can't find how to do it. Not sure what you are asking. There's a scale button on the left side of the screen. One unit in AC3D is one meter in FlightGear. 2 How do you know what direction the model is facing.When I go to place the A/C in the scenery it does not seem to face in the same direction as what the flight model is facing.Eg: yesterday I placed a model using the heading of the flight model but the static model ended up facing in a different direction by about 60 to 90 deg ???. In AC3D you should see the left side of the aircraft in the XY Front view. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson writes You know, I'm not sure if we have to worry about using private carrier liveries from a copyright perspective. AFAIK Southwest is the first one...in fact I didn't notice the static model was Southwest until just now (duh!). Does anyone know about this? If it is a problem then there are millions of people at MSFS who have a problem.As far as I am aware the airlines can't be bothered sueing all the people involved.I do undestand that American Airlines tried some time back but for what ever reason gave up on it.Maybe someone here may have more info. I think it is because of this reason that MS used generic airline names when they released FS2K2.Just to get around this copyright problem.Then if Joe Bogs wants to paint his A/C in United's colors then so be it. Anyway if you have a look the 747 is painted in Pakistan Airlines colors and the A320 in Air France colors.So southwest is not the first. Not sure what you are asking. There's a scale button on the left side of the screen. One unit in AC3D is one meter in FlightGear. In some graphics programs you need to set the scale for feet or meters is AC3D set so one unit=1 metre always ??. In AC3D you should see the left side of the aircraft in the XY Front view. Yes I have got that but the A/C does not face the direction I expect Best, Jim Cheers Innis _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=174referral=Hotmail_taglines_plainURL=http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Innis Cunningham [EMAIL PROTECTED] said: Anyway if you have a look the 747 is painted in Pakistan Airlines colors and the A320 in Air France colors.So southwest is not the first. I was going to say that those aren't private carriers, but a couple years back it seems there was a news article about Air France planning to go semi-private. Still Southwest is the first private non-national livery and I think that might make a difference...don't know. In some graphics programs you need to set the scale for feet or meters is AC3D set so one unit=1 metre always ??. It doesn't matter. There is never any mention of distances other than generic units in AC3D. In FlightGear, units are in meters. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson writes: I was going to say that those aren't private carriers, but a couple years back it seems there was a news article about Air France planning to go semi-private. Still Southwest is the first private non-national livery and I think that might make a difference...don't know. You're thinking about something that's very specific to the U.S. As far as I understand, the U.S. government is not allowed to copyright (and, perhaps, trademark?) any IP -- that's why people are allowed to copy and distribute the FAA database and the Instrument Approach Procedure plates for free, and why we can get such excellent free geodata for the U.S. when building FlightGear scenery. In the rest of the world, government and government-owned organizations have no such restriction, so Transport Canada (for example) could quite readily sue you for violating their copyright or trademark, as could Air France or anyone else. In fact, the British Crown asserts a perpetual copyright over the Book of Common Prayer, dating back many centuries. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: Innis Cunningham [EMAIL PROTECTED] said: Anyway if you have a look the 747 is painted in Pakistan Airlines colors and the A320 in Air France colors.So southwest is not the first. I was going to say that those aren't private carriers, but a couple years back it seems there was a news article about Air France planning to go semi-private. Still Southwest is the first private non-national livery and I think that might make a difference...don't know. Air France is a semi-private company where the French State hold 54.4% of the shares. But it is quoted at Euronext stock exchange. There are rumours stating that the government want to sell some of their share but they wait a market in better shape. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
David Megginson [EMAIL PROTECTED] said: You're thinking about something that's very specific to the U.S. As far as I understand, the U.S. government is not allowed to copyright (and, perhaps, trademark?) any IP -- that's why people are allowed to copy and distribute the FAA database and the Instrument Approach Procedure plates for free, and why we can get such excellent free geodata for the U.S. when building FlightGear scenery. In the rest of the world, government and government-owned organizations have no such restriction, so Transport Canada (for example) could quite readily sue you for violating their copyright or trademark, as could Air France or anyone else. That was something I wondered about, but at the same time, it seems unlikely that a government would bring suit...even if it could. I mean it's not like they are going to extradite one of us. Probably all the suits ever filed by governments in foriegn courts can be counted on one hand, if that many. So, should we do anything differently with our models? In fact, the British Crown asserts a perpetual copyright over the Book of Common Prayer, dating back many centuries. Hah! ...and all because Henry VIII's first wife didn't bear any male children. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson writes: So, should we do anything differently with our models? For now, no: if we ever get a cease-and-desist letter, we can discuss it it then. Trademark violation is a complicated thing anyway -- I don't think that Campbell's soup could have successfully sued Andy Warhol even if they had wanted to, and we also are creating a kind of pop art (interactive, no less). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
David Megginson wrote: Jim Wilson writes: So, should we do anything differently with our models? For now, no: if we ever get a cease-and-desist letter, we can discuss it it then. Trademark violation is a complicated thing anyway -- I don't think that Campbell's soup could have successfully sued Andy Warhol even if they had wanted to, and we also are creating a kind of pop art (interactive, no less). I think that if we are respectful in the use of the marks ( right font, right colors ) and we do it in context, there will be no problem. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
As I said earlier MSFS has been painting A/C in world airline(private and government)colors for years.And I would think if you are going to sue someone it might as well be someone with money and good old uncle Bill G would the one to try and get money out of. The whole area of copyright can become blured.Take for instance the photo's at Airliners.net.I doubt that many of the people who took the shots have the airlines permission to use there images to make money.But more and more people over there are asking for payment to use the images.So as David says till someone complains I think we should persue our HOBBY. Cheers Innis Frederic Bouvier writes David Megginson wrote: Jim Wilson writes: So, should we do anything differently with our models? For now, no: if we ever get a cease-and-desist letter, we can discuss it it then. Trademark violation is a complicated thing anyway -- I don't think that Campbell's soup could have successfully sued Andy Warhol even if they had wanted to, and we also are creating a kind of pop art (interactive, no less). I think that if we are respectful in the use of the marks ( right font, right colors ) and we do it in context, there will be no problem. -Fred _ ninemsn Extra Storage comes with McAfee Virus Scanning - to keep your Hotmail account and PC safe. Click here http://join.msn.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
On Wed, 30 Jul 2003 12:33:17 +0200, Frederic Bouvier [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Jim Wilson wrote: Innis Cunningham [EMAIL PROTECTED] said: Anyway if you have a look the 747 is painted in Pakistan Airlines colors and the A320 in Air France colors.So southwest is not the first. I was going to say that those aren't private carriers, but a couple years back it seems there was a news article about Air France planning to go semi-private. Still Southwest is the first private ..you mean Southwestern? The low price air line? I've got this _wild_ idea, they, RyanAir and possibly Norwegian(.no), in good anti-monopolist spirit, might enjoy giving _us_, exclusive sim rights. ;-) Imagine the press response _potential_. ;-) non-national livery and I think that might make a difference...don't know. Air France is a semi-private company where the French State hold 54.4% of the shares. But it is quoted at Euronext stock exchange. There are rumours stating that the government want to sell some of their share but they wait a market in better shape. ..that could take a while; any hot dog stand needs _substance_ to support its owners profitably, and back-tracking the last pre-Enron stock market hike, I'd _run_ 'till I see a drop to the hot dog stand kinda sanity. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec wrote: But we can use a combination of both, right? If you will look at an aircraft at range of 15 feets, you see nothing. At 100k feets, you see a dot. At 7, you would see a triangle. At 5, you would see a rough shape. At 25000, the next one and at 1 a complete model without inner instruments. At 10 feet, you would see the inner instruments as well. I think LOD selector is very usable because instruments like radar, weapon control, radio controls etc. can really eat up lots of CPU for calculating and GPU for rendering it. So, when we implement all this some day, this might save lots of FPS then. We can assign a simple texture for e.g. radar behind the real calculated radar display to fill the whole between 100 and 1 feet. Don't have too high expectations about this. LOD calculations are already the limiting factor for FlightGear and this wil only help if there are dozens of aircraft flying around. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec writes: My suspicions were not correct. I benchmarked the framerate again yesterday and had 7 FPS in 24bpp mode and 9 FPS in 16bpp mode. I'm pretty sure the 16bpp mode worked faster in all views and positions in comparison to 24 bpp. Yes, that has been my experience as well. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec writes: In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway? The problem with any cockpit view (vs. external view) is the amount of texture management going on for all the gauges and displays. With the 2D panel, we were (at least originally) drawing a smaller screen area only above the panel, so that probably helped a bit. The San Francisco area is also slow because of all the complex terrain. Reducing the default visibility can help an awful lot (try --visibility=5000, for example). What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... We use the same 3D model for both, but most models add an LOD node so that the interior is drawn only when the view is very, very close to the plane. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
On Monday 28 July 2003 14:24, Jim Wilson wrote: ...aircraft already have xml that does this by selecting out the cockpit and maybe gear when they are viewed from a certain distance. In that case the That idea hadn't ocurred to me at all, and I hadn't spotted it in any of the other a/c either. Ta for mentioning it. I'm certainly going to look at Selecting out the u/c, wheel wells and other related internal surfaces when the gear's up:) cockpit would be removed as well as other interior geometry. I think the first option is probably the most effective. This is maybe a little different than some other approaches, but my guess is we'll find that we'll need separate models for other aircraft (AI and multiplayer) that are simplified with much less geometry and smaller textures. Best, Jim I've found that reducing the texture size on .ac format models seems to be easy - My texture 'masters' are generally 3200x2400 and I then scale them down for actual use and I've found that once I've done the model mapping with a texture that's been scaled down to 512x512, I can then replace the texture with one that's scaled to 1024x1024 or even 256x256 without having to re-map anything. This has proved handy as my current vid card can't cope with textures larger than 512x512 in AC3D so I do the texture mapping at that resolution and then replace the 512x512 texture file with one scaled to 1024x1024 for FG. Changing the model would stop that working of course, as the geometry would've changed, but it's a quick and simple way of getting a 'lite' (er) version of a model, at least with regard to texture space requirements. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Lee Elliott [EMAIL PROTECTED] said: Changing the model would stop that working of course, as the geometry would've changed, but it's a quick and simple way of getting a 'lite' (er) version of a model, at least with regard to texture space requirements. Using the reduce function in ac3d and deleting a few objects I was able to reduce the 747 model almost 80% without remapping textures at all. Note that you have to experiment with reducing different parts of the model different percentages (the ctrl+z comes in handy for this kind of experimenting :-)). The result is a little rough up close, but from a couple hundred meters viewing distance it looks pretty much the same. Screen shot: http://www.spiderbark.com/fgfs/747reduced.png Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
On Wednesday 30 July 2003 00:35, Jim Wilson wrote: Lee Elliott [EMAIL PROTECTED] said: Changing the model would stop that working of course, as the geometry would've changed, but it's a quick and simple way of getting a 'lite' (er) version of a model, at least with regard to texture space requirements. Using the reduce function in ac3d and deleting a few objects I was able to reduce the 747 model almost 80% without remapping textures at all. Note that you have to experiment with reducing different parts of the model different percentages (the ctrl+z comes in handy for this kind of experimenting :-)). The result is a little rough up close, but from a couple hundred meters viewing distance it looks pretty much the same. Screen shot: http://www.spiderbark.com/fgfs/747reduced.png Best, Jim That looks like a jolly good way of getting the low res models we need for massive multiplayer and scenery a/c. Ta for the info. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Hi Jim Are you working on a low poly version of the 747 for scenery work. I was working on it yesterday.Regrouping the fuse to use one texture and removing the wing and gear textures to reduce the load. I was planing to just apply a material to the wings, gear and horz stabilizer.Grey(silver) for the wings and stab and black for the wheels. I have mapped the Southwest texture to the fuse and reduced it to 256x256 it is a bit grainey up close but ok from a hundred meters plus. I am going to have a look at removing all the individual control surfaces and the 3D cockpit to see how it looks. What we need to be able to do to put a few static A/C around is to be able to use the one model with multiple textures, as it is now you have to create a separate model for each different airline.This is going to lead to rather large scenery files.Even now the default file for SFO is getting quite complicated with .ac files and the textures that go with them.Is there some way using xml or C to have the 3D scenery in there own file and get called by the .stg file instead of having them all in the scenery file as they are now. As I am rather new to AC3D I was wondering if you could answer a couple of questions. 1 How do you set the scale for the model.I have had a look in the docs and the program but can't find how to do it. 2 How do you know what direction the model is facing.When I go to place the A/C in the scenery it does not seem to face in the same direction as what the flight model is facing.Eg: yesterday I placed a model using the heading of the flight model but the static model ended up facing in a different direction by about 60 to 90 deg ???. Thanks in advance for any suggestions. Is anyone doing static A/C scenery for the default area airports as I was planning on populating some of the airports with static A/C. Cheers Innis Jim Wilson writes Using the reduce function in ac3d and deleting a few objects I was able to reduce the 747 model almost 80% without remapping textures at all. Note that you have to experiment with reducing different parts of the model different percentages (the ctrl+z comes in handy for this kind of experimenting :-)). The result is a little rough up close, but from a couple hundred meters viewing distance it looks pretty much the same. Screen shot: http://www.spiderbark.com/fgfs/747reduced.png Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Hotmail is now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/signup.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
5) Around the default KFSO, the framerate is way slower than in e.g. Slovenia. Is there any way to fix that (I know there are way more objects, but still I think it should be faster than 6 FPS when looking to the city or airfield) Is that fps in cockpit view or chase view? I get that sort of fps in chase view at KSFO too, but if in chase view there's also the a/c texture overhead as well. KSFO is pretty heavy especially if you've still got the high res textures. In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway? What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: Matevz Jekovec [EMAIL PROTECTED] said: 1) In mode 24 bpp, FlightGear ran faster than in 16 bpp (I also switched the Xfree depth to 24 and 16 then). Is there any known explanation (I haven't made benchmark, but judging by the eye I thought it was faster) for this. I think it's the textures fault as they are in 32 bit palette maybe? (including alpha channel) And FlightGear needs to calculate approximates to 24 output palette then? I wonder where the 16 bit dithering overhead comes in? Might this become a CPU speed (as opposed to interface) issue if there was a lot of texture swapping going on? I would think that any dithering would be cached...but... Best, Jim My suspicions were not correct. I benchmarked the framerate again yesterday and had 7 FPS in 24bpp mode and 9 FPS in 16bpp mode. I'm pretty sure the 16bpp mode worked faster in all views and positions in comparison to 24 bpp. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec writes: In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway? 3d rendering performance really has nothing to do with how closely you view an item. It has more to do with how much geometry you are drawing, how much texture ram is consumed by the objects you are drawing, and how much layering is done (i.e. how many total pixels do you need to draw to paint the entire scene.) - When looking at a 3d cockpit, you probably have more geometry to draw because of the complexities of the inside of the cockpit. To draw a lot of geometry you want a fast CPU and a fast AGP buss. - You also could have increased texture ram use because all the instruments are made from textures attached to polygons. To draw lots of textures without having to swap memory around, you want a card with lots of texture ram. - You could have increased layering as well. Think about it this way. If are pointed up and the sky takes up the whole view, I have to draw the blue sky background. Then I may need to redraw the entire screen again to add a semi-transpant cloud texture that covers the whole sky. Maybe there are 2 layers so I need to repaint the whole screen again for the 2nd layer. That means I had to draw 1024x768 pixels for the blue sky (or whatever your resolution is.) Then I have to update those 1024x768 pixels for each cloud texture. For panels it is a similar issue because instruments are made up of layers that are drawn over the top of each other (the HSI has many layers.) When the instrument panel takes up the whole screen you may have to update a particular pixel several times to get the finished scene. To handle this sort of situation well, you want a video card with high fill rate. That won't necessarily help you get faster frame rates and won't necessarily help people afford faster video cards, but those are some of the issues ... What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already? !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1 title/title /head body text=#00 bgcolor=#ff meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1 title/title meta http-equiv=Content-Type content=text/html;charset=iso-8859-1 title/title br blockquote type=cite cite=[EMAIL PROTECTED] pre wrap= /pre blockquote type=cite pre wrap=5) Around the default KFSO, the framerate is way slower than in e.g. Slovenia. Is there any way to fix that (I know there are way more objects, but still I think it should be faster than 6 FPS when looking to the city or airfield) /pre /blockquote pre wrap=! Is that fps in cockpit view or chase view? I get that sort of fps in chase view at KSFO too, but if in chase view there's also the a/c texture overhead as well. KSFO is pretty heavy especially if you've still got the high res textures. /pre /blockquote In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway?br br What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already?br /body /html
Re: [Flightgear-devel] Speed question?
man, 28.07.2003 kl. 14.03 skrev Curtis L. Olson: - When looking at a 3d cockpit, you probably have more geometry to draw because of the complexities of the inside of the cockpit. To draw a lot of geometry you want a fast CPU and a fast AGP buss. For geometry-limited situations, a fast AGP bus does not necessarily help all that much if you're using TL hardware and vertices are not actually stored in AGP memory, since then the drivers have to use system resources to transfer the vertex data from system memory to the card on every rendering call (in case the app changed the data between them), instead of letting the card fetch the vertices it needs straight from AGP memory on its own. In some situations, EXT_compiled_vertex_array can be useful to reduce the frequency of redundant transfers. But it's also possible to use the ARB_vertex_buffer_object, NV_vertex_array_range, or ATI_vertex_array_object extensions to store vertices directly in AGP memory where the card can get at it when it wants to. Trust me, for high geometry, it *really* makes a difference. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
If you are in 3D move the view to the right or left and you'll see the rate go right back up. The reason this works is the panel items are culled from the view and I presume their textures can be swapped out by the card. The hit in the cockpit is primarily the texture ram, and a little bit more geometry (quite a bit more in the case of the p51d). In any case this little test suggests that breaking aircraft into two models won't necessarily work. And if you want to be able to see the exterior parts from inside the cockpit (which I definately do) then you will need to render both anyway. Generally if aircraft models are used in a multiple aircraft situation, we need to do at least one of two things. One is have simplified aircraft models (separate model which just has less polys and no cockpit). The other thing is to put LOD selectors in the animation xml for the model. Some of the aircraft already have xml that does this by selecting out the cockpit and maybe gear when they are viewed from a certain distance. In that case the cockpit would be removed as well as other interior geometry. I think the first option is probably the most effective. This is maybe a little different than some other approaches, but my guess is we'll find that we'll need separate models for other aircraft (AI and multiplayer) that are simplified with much less geometry and smaller textures. Best, Jim Matevz Jekovec [EMAIL PROTECTED] said: In 3d cockpit view. That leads me to another question. Is there any way we can optimize the graphic engine, not to be so slow in 3d cockpit view? I know we had similar problems with the engine in Falcon, but were never solved due to untouchable source code later (license issues). Why does it work so slow, when viewing a 3D object from close distance anyway? What about the outer views: Does FlightGear use seperated 3D cockpit files for inner view or does it use aircraft's model cockpit? In Falcon, we had completely different files for 3D cockpit and aircaft model ... I'm asking this, because the cockpit of every aircraft can be as complex as all the other parts of the aircraft together. So when showing, say 10 aircrafts together someday with their own intelligence and properties, framerate will very drop but you'll hardly see the canopies of the aircrafts, let alone the inner cockpits. I think breaking free the 3D cockpit from the aircraft model isn't a bad idea. Has anyone give this a thought already? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: If you are in 3D move the view to the right or left and you'll see the rate go right back up. The reason this works is the panel items are culled from the view and I presume their textures can be swapped out by the card. The hit in the cockpit is primarily the texture ram, and a little bit more geometry (quite a bit more in the case of the p51d). In any case this little test suggests that breaking aircraft into two models won't necessarily work. And if you want to be able to see the exterior parts from inside the cockpit (which I definately do) then you will need to render both anyway. We added wings and tails objects, taken from the aircraft you are in, to that 3d cockpit. Then you were able to see the wings and tails. However, these were seperated models and have nothing in common with the aircraft model (except the textures, so you'd think this is really the aircraft model itself). Generally if aircraft models are used in a multiple aircraft situation, we need to do at least one of two things. One is have simplified aircraft models (separate model which just has less polys and no cockpit). The other thing is to put LOD selectors in the animation xml for the model. Some of the aircraft already have xml that does this by selecting out the cockpit and maybe gear when they are viewed from a certain distance. In that case the cockpit would be removed as well as other interior geometry. I think the first option is probably the most effective. This is maybe a little different than some other approaches, but my guess is we'll find that we'll need separate models for other aircraft (AI and multiplayer) that are simplified with much less geometry and smaller textures. Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec [EMAIL PROTECTED] said: Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? You can, yes. Though it might be useful to simplify the geometry of the objects that you select to show as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Jim Wilson wrote: Matevz Jekovec [EMAIL PROTECTED] said: Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? You can, yes. Though it might be useful to simplify the geometry of the objects that you select to show as well. Best, Jim But we can use a combination of both, right? If you will look at an aircraft at range of 15 feets, you see nothing. At 100k feets, you see a dot. At 7, you would see a triangle. At 5, you would see a rough shape. At 25000, the next one and at 1 a complete model without inner instruments. At 10 feet, you would see the inner instruments as well. I think LOD selector is very usable because instruments like radar, weapon control, radio controls etc. can really eat up lots of CPU for calculating and GPU for rendering it. So, when we implement all this some day, this might save lots of FPS then. We can assign a simple texture for e.g. radar behind the real calculated radar display to fill the whole between 100 and 1 feet. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec [EMAIL PROTECTED] said: Jim Wilson wrote: Matevz Jekovec [EMAIL PROTECTED] said: Yes, LODs are a good idea. We had those in Falcon too (actually, every more complex game uses LODs to increase the framerate anyway). About that LOD selector, do you mean we can set a property for every object if it should be rendered or not at certain distance and not us having the whole simplified aircraft model for long distance? You can, yes. Though it might be useful to simplify the geometry of the objects that you select to show as well. But we can use a combination of both, right? If you will look at an Yes, absolutely. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
It's been my personal experience on a GeForce GO based laptop that 16bpp ran faster and used less texture ram the 24bpp. Ok, so the framerate is higher in 16 bit and there aren't any weird assumptions? (as I said, I judged by the eye, so obviously it was the deprivation of colours that blended my mind:)) FlightGear isn't set up to change your display resolution. It operates on the presumption that the owner of the machine will set the desired resolution and it will run on whatever it is given. So, if I want to run FlightGear in 800x600, I should restart my X in 800x600 resolution and run FlightGear then (that's a bit of a problem because there are some issues with my GF2MX PCI card and it takes about 4 minutes of frozen, blank computer when starting X, but I'll survive:)) You could remove the Textures.high subdirectory. My intension is that the textures in the regular Textures subdirectory should stay within the 256x256 limit although I've had to go in and fix a few things that crept through on occasion. :-) So, all the textures are doubled if I understand, ones in highres and ones in 256*256. What about the specific terrain/model/airport textures? Are these all included here? Yes, especially because you are running on a relatively slower machine, you will probably find yourself geometry limited. In other words the amount of geometry that get's rendered per frame will be the dominant factor in determining frame rate. Increasing FOV increases the amount of geometry (i.e. stuff) that get's drawn per frame. Is there any way you can see in the game the currnet FOV in radians or degrees? Yes, this is the same reason as for 7). By reducing visibility, you are reducing the amount of scenery the system needs to draw. That's good ... also, there is higher density terrain data for the USA (well now all of the western hemisphere but we've only used it for the USA to date) that means that there is often a higher triangle density in USA areas versus non-USA areas. I wonder, is it possible to me manually edit, shape and tile the terrain for Slovenia? I know, we were doing this in Falcon for Balkans theatre ... many tilers were needed:), but in the end it looked very neat as every one was responsible for his own part of the peninsula and we really got these various styles of look in the end then. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
On Friday 25 July 2003 21:56, Matevz Jekovec wrote: I have PII 333 Mhz with GF2MX 32MB on PCI and 256 MB of SDRAM. I have Abit LX something motherboard and SBAWE64 on ISA (I'm about to buy Live! in the next few days). I would like to run FGFS smoothly (that's about 15-20 FPS) on GNU/Debian Linux unstable and using the latest nVidia Linux drivers. By using the latest CVS version I noticed the following things: 1) In mode 24 bpp, FlightGear ran faster than in 16 bpp (I also switched the Xfree depth to 24 and 16 then). Is there any known explanation (I haven't made benchmark, but judging by the eye I thought it was faster) for this. I think it's the textures fault as they are in 32 bit palette maybe? (including alpha channel) And FlightGear needs to calculate approximates to 24 output palette then? I'm using Debian unstable too - have you tried including the line DefaultFbBpp32 in your XF86Config-4 for 24 bpp mode? This will be in the Screen section and you can add it below the DefaultDepth24 entry. Make sure you have a back-up copy of XF86Config-4 before you change it and also that you'll be able to re-instate it from the console if it goes badly wrong and X won't load. It might, or might not make a difference. I have to run FG in 16bpp on my MGA G550 32MB to get decent frame rates. 2) The resolution I had on my X was 1024x768 all the time and I wanted to run FlightGear in 800x600, but had no luck. There was a sign when starting up that it is about to run in 800x600 mode, but when switching to fullscreen, the X mode still stayed 1024x768. I have the possible resolution set in xfree86 config file and ctrl+alt++/- work fine and others applications do change the resolution as well. Is there any parameter to set FlightGear to change the system resolution and runs in that in fullscreen? (I searched for man pages, but haven't found anything) I know it worked in Windows some days. As Curt says, FG won't change your screen resolution. I run FG at 1280x960 and then CTRL+ALT+'+' a couple of times to change the X display res down to match the window. I've not had any problems re-sizing the window when FG is running. 3) --disable-textures parameter is not working. 4) Any way to limit the texture size to at most 256*256 or 512*512 pixels, because when starting up, the limit of 2048*2048 is set AFAIK. As Curt says, delete the Textures.high directory - sadly, that's what I have to :( 5) Around the default KFSO, the framerate is way slower than in e.g. Slovenia. Is there any way to fix that (I know there are way more objects, but still I think it should be faster than 6 FPS when looking to the city or airfield) Is that fps in cockpit view or chase view? I get that sort of fps in chase view at KSFO too, but if in chase view there's also the a/c texture overhead as well. KSFO is pretty heavy especially if you've still got the high res textures. 6) I tried to disable clouds (and sky blending? Is this the same thing because when sky blending is off, there are no clouds) and FPS increased from KSFO 5 FPS to about 9, 10 FPS. 7) By increasing FOV, the framerate decreases drasticly. I would really like to enjoy in a bit wider FOV when playing, but it really hits the FPS. Is this normal? 8) By decreasing visibility, the framerate increases drasticly. I like that:) 9) LJLJ airfield (Slovenia) was more or less playable (about 15 FPS average) with turned clouds on. 10) Sunsets look really nice!:) - Matevz The sunsets are lovely - I do lots of flying at dusk just because of them. Big thanks for your effort Erik. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec writes: So, if I want to run FlightGear in 800x600, I should restart my X in 800x600 resolution and run FlightGear then (that's a bit of a problem because there are some issues with my GF2MX PCI card and it takes about 4 minutes of frozen, blank computer when starting X, but I'll survive:)) Or, alternatively 1. Temporarily change your resolution using something like ALT NUM- and ALT NUM+ (if you're in XFree86). 2. Run FlightGear in a window instead of fullscreen. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
Matevz Jekovec [EMAIL PROTECTED] said: 1) In mode 24 bpp, FlightGear ran faster than in 16 bpp (I also switched the Xfree depth to 24 and 16 then). Is there any known explanation (I haven't made benchmark, but judging by the eye I thought it was faster) for this. I think it's the textures fault as they are in 32 bit palette maybe? (including alpha channel) And FlightGear needs to calculate approximates to 24 output palette then? I wonder where the 16 bit dithering overhead comes in? Might this become a CPU speed (as opposed to interface) issue if there was a lot of texture swapping going on? I would think that any dithering would be cached...but... Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed question?
On Fri, 25 Jul 2003 23:32:07 +0200, Matevz Jekovec [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: So, if I want to run FlightGear in 800x600, I should restart my X in 800x600 resolution and run FlightGear then (that's a bit of a problem because there are some issues with my GF2MX PCI card and it takes about 4 minutes of frozen, blank computer when starting X, but I'll survive:)) ..have you tried to fire up _another_ X on say ':1'? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
