Re: [Flightgear-devel] Moving menus (aka, usability)

[sb356607]

You know one of the things that needs to happen with light-year is that the 
menus need to be accessible for the visually impaired it is very difficult to 
get to the menus we need to see the menus on the menu bar and have a little 
more accessibility to this because I use this mostly by keyboard and I can't 
get to some of the menu if not all of them

Sent from my iPhone

> On Sep 26, 2013, at 12:29, Clement de l'Hamaide  wrote:
> 
> Hi,
> 
> > - merge 'Autopilot' into the Equipment menu, as a section (probably the 
> > first section)
> 
> I have no objection with this.
> 
> 
> 
> > - potentially rename 'Environment' to 'World' 
> 
> Environment word looks fine to me. 
> A quick search on Google reveal that X-Plane use "Environment" but FSX use 
> "World". So other simulators doesn't help here :-D
> 
> 
> 
> > reserve the Ctrl (Command on Mac) keybinding space for menu/non-aircraft 
> > keyboard shortcuts
> 
> I agree with this.
> 
> 
> Regards,
> Clément
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Moving menus (aka, usability)

[Clement de l'Hamaide]

Hi,

>  - merge 'Autopilot' into the Equipment menu, as a section (probably the 
> first section)

I have no objection with this.



>  - potentially rename 'Environment' to 'World' 

Environment word looks fine to me. 
A quick search on Google reveal that X-Plane use "Environment" but FSX use 
"World". So other simulators doesn't help here :-D



> reserve the Ctrl (Command on Mac) keybinding space for menu/non-aircraft 
> keyboard shortcuts

I agree with this.


Regards,
Clément
  --
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Moving menus (aka, usability)

[Thomas Albrecht]

> The Autopilot menu change does make sense (although there may possibly be a 
> case for keeping such a flight-critical menu rapidly accessed at the top 
> level?)

I don't see this need. When I'm in a hurry, I use my left hand to enter a 
keyboard shortcut, rather than taking my right hand off the most critical 
flight controls to grab the mouse and navigate to/through a menu. 

> the control key is usually one of the easiest modifiers to find on a keyboard
Mhh.. personally, I'd slightly prefer the shift key over the control key for 
the most important two-key-shortcuts. Using one hand (remember, the other hand 
is on the stick;), shift enables a slightly larger range than control: I can 
somewhat easily type shift+5, whereas control+5 becomes a little difficult.

Tom

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Moving menus (aka, usability)

[James Turner]

On 26 Sep 2013, at 16:21, AJ MacLeod  wrote:

> That's exactly what the word environment means though, isn't it!  I really 
> don't think there's any point at all in changing the name of that menu entry; 
> the current one perfectly accurately describes "things around you" and avoids 
> having to change documentation etc.  

Okay, to me 'World' sounds a bit less technical, and it's also a shorter word. 
But either work, I agree.

> Regarding the control key mapping restrictions, I'm definitely not too keen 
> on that for this reason; the control key is usually one of the easiest 
> modifiers to find on a keyboard, and if anything I personally think more 
> flight-related functions should be accessed using the control key as you 
> often want to access those rapidly, perhaps even by feel without hunting 
> around the keyboard.
> 
> Program related functions on the other hand are rarely needed in a hurry and 
> could be mapped to any modifier without making much difference to 
> functionality.
> 
> Just my opinions, possibly strange ones :-)

Hmm, the problem is the OSs have already decreed that Ctrl (Command on Mac) is 
the standard shortcut key, so lots of Ctrl-something have standard meanings 
which FlightGear deviates from. Though we escape the worst of it since we don't 
support file or edit operations.

Keep in mind if the GUI things such as dialogs were moved to Ctrl-blah, that 
frees up lots of normal keys for use, which are currently taken up by simulator 
things. While I agree Ctrl is probably the easiest modifier to access (except 
maybe shift, since there's two, so it's more friendly for left-handed people), 
I think by this logic a shortcut with *no* modifiers is even easier to access, 
and that's an argument in *favour* of such change :)

I still don't have a good technical way to migrate this, so it's not a big deal 
anyway.

James--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Moving menus (aka, usability)

[AJ MacLeod]

On Thu, 26 Sep 2013 11:45:38 +0100
James Turner wrote:

The Autopilot menu change does make sense (although there may possibly be a 
case for keeping such a flight-critical menu rapidly accessed at the top level?)

>  - potentially rename 'Environment' to 'World' 
> If most of the AI stuff moves to 'World', I think that name makes sense - 
> it's about things outside your aircraft, which does include tankers, carriers 
> and scenarios, as well as the weather and time/season.

That's exactly what the word environment means though, isn't it!  I really 
don't think there's any point at all in changing the name of that menu entry; 
the current one perfectly accurately describes "things around you" and avoids 
having to change documentation etc.  

Regarding the control key mapping restrictions, I'm definitely not too keen on 
that for this reason; the control key is usually one of the easiest modifiers 
to find on a keyboard, and if anything I personally think more flight-related 
functions should be accessed using the control key as you often want to access 
those rapidly, perhaps even by feel without hunting around the keyboard.

Program related functions on the other hand are rarely needed in a hurry and 
could be mapped to any modifier without making much difference to functionality.

Just my opinions, possibly strange ones :-)

AJ

-- 

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[TDO Brandano]

Another approach could be the use of multiple UV layers, like other game 
engines, err, scenegraphs use. One base texture, and one or more uv layers for 
decals, with the possibility to define in the material properties if a texture 
repeats or not. the limit here is posed by the use of a model format that is 
more limited than what the scenegraph is capable of. I am not saying that FGFS 
should not use the AC3D format, but since it already extends it, for example 
adding a format for animating sub-meshes, it ought to be possible to do the 
same to add support for this sort of features, along with vertex weights and 
skeletal systems for example. 

Date: Thu, 26 Sep 2013 15:53:32 +0400
From: tomash.brec...@gmail.com
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Mipmapping of liveries

Also the question to GPU gurus: I think most aircrafts that have hi-res 
liveries do so because of several small signs here and there.  So does it makes 
sense to have a lo-res opaque texture that paints aircraft's body, and then a 
hi-res transparent one that places signs on top of the first?  This way hi-res 
texture will be mostly "empty" - will it substantially improve GPU cycles and 
memory usage?



-- 
  Tomash Brechko



--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel   
  --
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 89, Issue 11

[Tomash Brechko]

Keep in mind that texture resolution alone doesn't tell you much unless you
know how much surface area is fitted into it.  Some planes fit both sides
of wings, fuselage, gears and much more into a single rectangle so it being
of hi-res doesn't mean that you can see every grain of sand on a tire.


2013/9/26 BARANGER Emmanuel 

> I tried many times to explain this. But it seems that some do not want to
> understand: (
>


-- 
  Tomash Brechko
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[Tomash Brechko]

2013/9/26 Renk Thorsten 

> Full GPU memory leads to performance deterioration.


Well, I'm not entirely convinced that plus-munis some tens of MBs made a
difference in one case I heard of (tu154b, five 1024x1024 textures for the
exterior).  Yet I'm convinced that mipmap alone is not a panacea for a
problem.

Thanks for all the replies!

-- 
  Tomash Brechko
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Moving menus (aka, usability)

[Stuart Buchanan]

On Thu, Sep 26, 2013 at 11:45 AM, James Turner wrote:
> I was reviewing the current menu structure and would like to propose a couple 
> of changes. Partly because we have too many menus, all quite short, but also 
> to remove some bad terminology.
>
> Each of these changes is independent, comments explicitly requested:
>
>  - merge 'Autopilot' into the Equipment menu, as a section (probably the 
> first section)
>
> Autopilot is just another piece of equipment, and route-manager and GPS are 
> really parallel features, since route-manger is basically the FMC. The 
> combined menu is still a reasonable length. Aircraft without the default 
> autopilot (including the C172) would need to
> disable just those menu items, but that's ok

OK with me.

A while back I introduced a Nasal abstraction layer so that aircraft
could disable particular menu items without needing to know the the
structure of the menu itself.

So, in theory this should be pretty straightforward and not require
any aircraft updates.  However, I think you'll need to update the
Nasal code (in gui.nas IIRC - not at my FG computer right now) so that
the "autopilot" item now maps to the full set of autopilot items.
That's slightly ugly, but at least hides this from the aircraft
developer.

>  - potentially rename 'Environment' to 'World'
>
> This is less of an issue, but makes sense with the next one:
>
> - Move the AI items elsewhere
>
>   -- Traffic / Scenarios move to 'World' menu
>   -- ATC services mode to World or Equipment (opinions requested)
>   -- All the 'controls' for tanker/carrier/wingman also move to world (or 
> somewhere even smarter … unfortunately PUI doesn't support sub-menus)
>
> The rationale here is that 'AI' is a completely meaningless term for most 
> users, and the way we use it in FlightGear has long since ceased to be 
> accurate. 'AI objects' are really what is normally called a 'mobile' or 
> 'actor' in most game engines. So the menu needs to either be removed or 
> renamed, and I don't think there's a sane meaningful new name, compared to 
> relocating the items.
>
> If most of the AI stuff moves to 'World', I think that name makes sense - 
> it's about things outside your aircraft, which does include tankers, carriers 
> and scenarios, as well as the weather and time/season.

I'm OK with this as well.

I expect that such large changes will require a significant update to
The Manual, so please let me know what the final changes are once you
make them and I'll update The Manual code.

> A separate step, much harder to make happen, would be to explicitly reserve 
> the Ctrl (Command on Mac) keybinding space for menu/non-aircraft keyboard 
> shortcuts. I would really like to do this so we can have user-friendly 
> key-bindings for dialogs and standard items, such as Ctrl-Q to quit, Ctrl-A 
> for autopilot dialog, Ctrl-P for pause, Ctrl-R for reply, etc. [And the 
> entire normal key / key + shift / key+alt ranges available FOR aircraft 
> functions, of course) The problem is right now we have aircraft using Ctrl- 
> shortcuts for many things (usually because they're the only choice), and I 
> can't decide a sane way to migrate to this split without lots of breakage and 
> frustration. Any ideas welcome.

I think this is a good idea.

I think it would be worth doing this as part of a wider re-org of the
keyboard so we only have to re-assign keys on aircraft once.

 I'm sure there are various keys (time/sim acceleration) that pre-date
the GUI and really no-longer need/deserve key bindings for the
majority of users.  Hopefully that would free up some keys, and allow
us to set aside a standard set of keys for aircraft bindings.

-Stuart

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 89, Issue 11

[BARANGER Emmanuel]

Le 26/09/2013 12:30, flightgear-devel-requ...@lists.sourceforge.net a 
écrit :



Message: 8
Date: Thu, 26 Sep 2013 06:18:53 +
From: Renk Thorsten
Subject: Re: [Flightgear-devel] Mipmapping of liveries
To: FlightGear developers discussions

Message-ID:
Content-Type: text/plain; charset="us-ascii"
In contrast, planes typically map to areas of 10x10m, so using a 2048x2048 
texture gives you a 5 mm resolution. Assuming a FOV of 60 deg, you need to be 
closer to 4 m to the MP plane to actually get to see the hires texture. I think 
it's fair to say that you'll almost never reach that distance, so you're 
spending lots of memory on things which you'll never get to see in flight. 
Assuming you see MP planes from at best 40 m distance, a 256x256 sheet is quite 
enough. For the same reason, it makes a lot of sense*not*  to render the plane 
interior of MP planes.

Hi :)

I tried many times to explain this. But it seems that some do not want 
to understand: (
A very simple example. Study the T6 Texan. It has textures in 1024x1024 
and each in 2048x2048. Place to 6 or 7 meters from the airplane and move 
from one to the other (High-> Low - Low-> High). The differences are so 
minimal that there is no interest to use High textures for the planes lol


Unless, of course, want to stick your nose on the fuselage. This is not 
very convenient for flying.


By cons, for all the creators of aircraft textures. I do give one piece 
of advice. Work in 2048x2048 (or better in 4096x4096). And once all the 
work is completed, reduce the size for 1024x1024. the results will be 
perfect in 99% of cases.
But if it is only the desire to show your talent at all in this case, 
always remember the users. Always the users. Provide your textures in 
both resolutions. High for your pleasure, and low for all users.


Regards Emmanuel

--
BARANGER Emmanuel

http://helijah.free.fr

http://embaranger.free.fr

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[Renk Thorsten]

>  But several people reported that hi-res aircrafts break fps in MP, and  
> downscaling liveries solves the problem (and this follows from Stuart's  
> email). But if mipmap _is_ applied to liveries, then why we have to have  
> lo-res liveries separately? Won't one of mipmap levels do the same? Note  
> that people complain about fps drop, not some load delay or space issues.

Full GPU memory leads to performance deterioration. If you load a hires 
texture, mipmapping doesn't automatically remove the hires maps from memory and 
keeps only the resolution level you actually need, it stores everything. Even 
if you effectively use a 128x128 mipmap, for memory and ultimately performance, 
it makes a difference whether this comes from a 128x128 sheet or a 4096x4096 
sheet mapped down.

> Also the question to GPU gurus: I think most aircrafts that have hi-res
> liveries do so because of several small signs here and there.  So does it
> makes sense to have a lo-res opaque texture that paints aircraft's body,
> and then a hi-res transparent one that places signs on top of the first?
> This way hi-res texture will be mostly "empty" - will it substantially
> improve GPU cycles and memory usage?

I don't think so - that'd potentially only help if you would store compressed 
textures (see the dds issue), but we don't, and so it would just make memory 
usage worse. In addition, transparent bits are always more difficult to render.

There's some clever things you can do with shader effects which save memory 
(and sometimes even end up being fast) - but that gets difficult to implement 
for aircraft creators.

* Thorsten
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[Tomash Brechko]

Also the question to GPU gurus: I think most aircrafts that have hi-res
liveries do so because of several small signs here and there.  So does it
makes sense to have a lo-res opaque texture that paints aircraft's body,
and then a hi-res transparent one that places signs on top of the first?
This way hi-res texture will be mostly "empty" - will it substantially
improve GPU cycles and memory usage?


-- 
  Tomash Brechko
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Help for Aircraft Graphics

[Stuart Buchanan]

Hi Satish,

On Thu, Sep 26, 2013 at 10:50 AM, Satish Srivastava wrote:
> Kindly tell me the platform and code for only simulating the some aircraft
> like jaguar graphics. My interest is to simulate flight by giving string of
> aircraft data necessary for flight like velocity, acceleration, roll, pitch,
> yaw and control surface positions.

If you want to use FlightGear to visualize data from another source,
there are lots of options.

Under the Docs/ directory of your Flightgear installation there will
be various README files, and a README.pdf file which is compilation
of all of them.  Have a look at README.IO and (IIRC) README.generic
for information.

-Stuart

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Static B737 at SFO (Was: Mipmapping of liveries)

[Durk Talsma]

On 26 Sep 2013, at 13:04, Erik Hofman wrote:

> On 09/26/2013 12:47 PM, James Turner wrote:
>> 
>> On 26 Sep 2013, at 11:33, Erik Hofman > > wrote:
>> 
>>> On that topic, there's a static 737 on the taxi tracks that's there
>>> since the old days when there was no AI traffic, it is probably a good
>>> idea to remove it from the scenery now.
>> 
>> Mostly i agree, but it's sort of a piece of FG history now, like Durk's
>> roof-parked Fokkers. Which was such a good idea that EHAM copied it in
>> real life. No sign of KSFO placing a 737-200 at that location in homage
>> to FG yet, clearly we have more fans in .NL
> 
> Grin :)
> 
> Erik

:-)

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[Detlef Faber]

> Stuart Buchanan  hat am 26. September 2013 um 12:22
> geschrieben:
> 
> 
[snip]
> 
> Perhaps we should mandate that aircraft over a certain size should have an AI
> version created?
> 

There is an alternative to an AI Version. For Aircraft with Livery Select it is
possible to have the MP/AI Version load it's texture from a different directory
with smaller sized Images. That way only the Liveries Images and the XML files
need adaption.
Another Loading time increasing factor is the Cockpit with all it's instruments.
I now use a low poly version without instruments for MP. This is triggered by a
property set from the nasal section of the Model XML file. That way only the MP
Model gets low poly and by setting the Property one can get the whole detailed
Cockpit back if necessary (e.g. for dual Control). Check the Model XML files of
the F-86 for an example.



> -Stuart
> 
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Static B737 at SFO (Was: Mipmapping of liveries)

[TDO Brandano]

I always thought it was a 737 hulk  used for fire crew training.
I think there's no reason why mipmaps could not be pre-generated for formats 
other than DDS, nothing stops FGFS from defining a texture as a combination of 
a series of images and a snippet of XML code describing the way these are 
arranged as mipmap levels.

From: zakal...@mac.com
Date: Thu, 26 Sep 2013 11:47:26 +0100
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Static B737 at SFO (Was: Mipmapping of  
liveries)


On 26 Sep 2013, at 11:33, Erik Hofman  wrote:On that topic, 
there's a static 737 on the taxi tracks that's there since the old days when 
there was no AI traffic, it is probably a good idea to remove it from the 
scenery now.
Mostly i agree, but it's sort of a piece of FG history now, like Durk's 
roof-parked Fokkers. Which was such a good idea that EHAM copied it in real 
life. No sign of KSFO placing a 737-200 at that location in homage to FG yet, 
clearly we have more fans in .NL
:D
James

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel   
  --
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Static B737 at SFO (Was: Mipmapping of liveries)

[Erik Hofman]

On 09/26/2013 12:47 PM, James Turner wrote:
>
> On 26 Sep 2013, at 11:33, Erik Hofman  > wrote:
>
>> On that topic, there's a static 737 on the taxi tracks that's there
>> since the old days when there was no AI traffic, it is probably a good
>> idea to remove it from the scenery now.
>
> Mostly i agree, but it's sort of a piece of FG history now, like Durk's
> roof-parked Fokkers. Which was such a good idea that EHAM copied it in
> real life. No sign of KSFO placing a 737-200 at that location in homage
> to FG yet, clearly we have more fans in .NL

Grin :)

Erik

-- 
http://www.adalin.com
- Hardware accelerated AeonWave and OpenAL for Windows and Linux
- AeonWave Audio Effects software for DJ, Instrumentalist and Vocalist

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Static B737 at SFO (Was: Mipmapping of liveries)

[James Turner]

On 26 Sep 2013, at 11:33, Erik Hofman  wrote:

> On that topic, there's a static 737 on the taxi tracks that's there 
> since the old days when there was no AI traffic, it is probably a good 
> idea to remove it from the scenery now.

Mostly i agree, but it's sort of a piece of FG history now, like Durk's 
roof-parked Fokkers. Which was such a good idea that EHAM copied it in real 
life. No sign of KSFO placing a 737-200 at that location in homage to FG yet, 
clearly we have more fans in .NL

:D

James

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Moving menus (aka, usability)

[James Turner]

I was reviewing the current menu structure and would like to propose a couple 
of changes. Partly because we have too many menus, all quite short, but also to 
remove some bad terminology.

Each of these changes is independent, comments explicitly requested:

 - merge 'Autopilot' into the Equipment menu, as a section (probably the first 
section)
   
Autopilot is just another piece of equipment, and route-manager and GPS are 
really parallel features, since route-manger is basically the FMC. The combined 
menu is still a reasonable length. Aircraft without the default autopilot 
(including the C172) would need to
disable just those menu items, but that's ok

 - potentially rename 'Environment' to 'World' 

This is less of an issue, but makes sense with the next one:

- Move the AI items elsewhere 

  -- Traffic / Scenarios move to 'World' menu
  -- ATC services mode to World or Equipment (opinions requested)
  -- All the 'controls' for tanker/carrier/wingman also move to world (or 
somewhere even smarter … unfortunately PUI doesn't support sub-menus)

The rationale here is that 'AI' is a completely meaningless term for most 
users, and the way we use it in FlightGear has long since ceased to be 
accurate. 'AI objects' are really what is normally called a 'mobile' or 'actor' 
in most game engines. So the menu needs to either be removed or renamed, and I 
don't think there's a sane meaningful new name, compared to relocating the 
items.

If most of the AI stuff moves to 'World', I think that name makes sense - it's 
about things outside your aircraft, which does include tankers, carriers and 
scenarios, as well as the weather and time/season.

A separate step, much harder to make happen, would be to explicitly reserve the 
Ctrl (Command on Mac) keybinding space for menu/non-aircraft keyboard 
shortcuts. I would really like to do this so we can have user-friendly 
key-bindings for dialogs and standard items, such as Ctrl-Q to quit, Ctrl-A for 
autopilot dialog, Ctrl-P for pause, Ctrl-R for reply, etc. [And the entire 
normal key / key + shift / key+alt ranges available FOR aircraft functions, of 
course) The problem is right now we have aircraft using Ctrl- shortcuts for 
many things (usually because they're the only choice), and I can't decide a 
sane way to migrate to this split without lots of breakage and frustration. Any 
ideas welcome.

Regards,
James
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Static B737 at SFO (Was: Mipmapping of liveries)

[Erik Hofman]

On 09/26/2013 12:30 PM, James Turner wrote:

> Some of the folks on the fourm have been doing greta work up the AI
> models of our transport-category aircraft, mostly to improve appearance
> of Traffic. The A320 and A330 have had overhauls and now look great, and
> I believe the Boeings are next on the list, which is good because the
> current AI 744 and 777 look pretty bad. But revised A320 is exactly the
> kind of model we want for MP - a realistic silhouette and nice liveries
> when parked without going crazy in any one area.

On that topic, there's a static 737 on the taxi tracks that's there 
since the old days when there was no AI traffic, it is probably a good 
idea to remove it from the scenery now.

Erik

-- 
http://www.adalin.com
- Hardware accelerated AeonWave and OpenAL for Windows and Linux
- AeonWave Audio Effects software for DJ, Instrumentalist and Vocalist

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[Tomash Brechko]

I'm not trying to convince anyone to use hi-res liveries.  But several
people reported that hi-res aircrafts break fps in MP, and downscaling
liveries solves the problem (and this follows from Stuart's email).  But if
mipmap _is_ applied to liveries, then why we have to have lo-res liveries
separately?  Won't one of mipmap levels do the same?  Note that people
complain about fps drop, not some load delay or space issues.

Could it be that livery textures follow another execution path and mipmap
isn't applied to them after all (mipmapping doesn't happen in GPU unless
you explicitly request it)?

-- 
  Tomash Brechko
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Help for Aircraft Graphics

[Satish Srivastava]

Kindly tell me the platform and code for only simulating the some aircraft
like jaguar graphics. My interest is to simulate flight by giving string of
aircraft data necessary for flight like velocity, acceleration, roll,
pitch, yaw and control surface positions.
Thanks
Please reply on this mail-id
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[James Turner]

On 26 Sep 2013, at 11:22, Stuart Buchanan  wrote:

> One further point to make is that we do have the AI/Aircraft directory
> specifically
> used for low-poly/resolution models.
> 
> So, if there are specific aircraft that are causing problems, arguably
> the correct
> way to resolve them is to create an AI version.  This would be quite a good
> task for someone wanting to get to grips with modeling, as it's easier to 
> remove
> things than add them.
> 
> Perhaps we should mandate that aircraft over a certain size should have an AI
> version created?

+1 on all counts.

Some of the folks on the fourm have been doing greta work up the AI models of 
our transport-category aircraft, mostly to improve appearance of Traffic. The 
A320 and A330 have had overhauls and now look great, and I believe the Boeings 
are next on the list, which is good because the current AI 744 and 777 look 
pretty bad. But revised A320 is exactly the kind of model we want for MP - a 
realistic silhouette and nice liveries when parked without going crazy in any 
one area.

Regards,
James

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[Stuart Buchanan]

On Thu, Sep 26, 2013 at 8:27 AM, James Turner wrote:
> Just to say, Thorsten has in this case saved me writing an email, thanks.
>
> To re-iterate - GPU VRAM is a precious commodity, so we should spend it on
> texels you can actually see.

One further point to make is that we do have the AI/Aircraft directory
specifically
used for low-poly/resolution models.

So, if there are specific aircraft that are causing problems, arguably
the correct
way to resolve them is to create an AI version.  This would be quite a good
task for someone wanting to get to grips with modeling, as it's easier to remove
things than add them.

Perhaps we should mandate that aircraft over a certain size should have an AI
version created?

-Stuart

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

[James Turner]

On 26 Sep 2013, at 07:18, Renk Thorsten  wrote:

> Mipmaps for textures are pretty generic for the rendering process. If you 
> would not mipmap  textures, they'd create flickering Moire patterns whenever 
> the texture resolution is higher than the screen resolution as (leaving 
> antialiasing aside) the pixel color is determined from a single texture 
> lookup, and the point for that lookup is ill defined when many texture pixels 
> are mapped to a single screen pixel, i.e. the pixel color would flicker frame 
> by frame (that is a problem for procedural texturing).
> 
> Whenever a texture is loaded into the GPU memory, it is mipmapped if it isn't 
> already.  One advantage of dds is that it can contain pre-generated mipmaps - 
> in this case the mipmaps can just be loaded with the base texture, otherwise 
> the mipmap generation is part of the texture loading process.
> 
> If uncompressed dds is used, the final result is the same - a mipmap tower 
> resides in GPU memory, but the time to load the texture is shorter for dds at 
> the expense of having  a larger file. So non-dds textures may generate a 
> short to long (dependent on system) frame delay, whereas dds works a bit 
> smoother. dds can also be compressed, in which case it saves GPU memory, but 
> since that requires proprietary graphics drivers to work, it is not 
> considered an option for FG.
> 
> The main difference between hires and lowers textures is not lookup speed 
> (that's taken care of by mipmapping) but memory - if the GPU memory is full, 
> system memory needs to be used (which is slower), if that overruns, virtual 
> memory must be used (which is even slower) - I have managed at some point to 
> fill the whole 11 GB of my combined GPU and system memory, and the 
> performance degradation was quite substantial.
> 
>> Quite recently there was a discussion about 2048x2048 textures for  
>> scenery, and I'm sure they are mipmapped, otherwise it won't fly. A  
>> typical plane fits all of its exterior into at most a dozen hi-res  
>> textures, so the added cost of mipmapping those is negligible I think.
> 
> Scenery textures are typically mapped to 2000x2000 m areas, so you get about 
> 4x4 m per pixel with a standard 512x512 terrain texture, assuming a 60 deg 
> FOV, you get a good graphical impression only for view distances of 2500 m 
> and more. That's okay for airliner cruise altitude, but really lousy for low 
> leve flight.
> 
> Going to 2028x2048 improves the optimum view distance down to ~800 m, which 
> starts to make it okay for private aviation in single-engine planes, but 
> still lousy  for low level flight.
> 
> So for scenery, there's not only a need for high resolution, but it's also 
> something that you tend to see quite often (almost all the time) at less than 
> optimal resolution. And the whole scenery doesn't need more than two dozens 
> of such textures at any given time - according to your calculation, that's 
> just the performance footprint of two MP planes.
> 
> In contrast, planes typically map to areas of 10x10m, so using a 2048x2048 
> texture gives you a 5 mm resolution. Assuming a FOV of 60 deg, you need to be 
> closer to 4 m to the MP plane to actually get to see the hires texture. I 
> think it's fair to say that you'll almost never reach that distance, so 
> you're spending lots of memory on things which you'll never get to see in 
> flight. Assuming you see MP planes from at best 40 m distance, a 256x256 
> sheet is quite enough. For the same reason, it makes a lot of sense *not* to 
> render the plane interior of MP planes.
> 
> So, not only would hires MP liveries be insanely expensive as compared to 
> scenery if you just have a few planes in the scene, they would also be 
> utterly useless because you can never get close enough. 
> 
> Hope that answers the question conclusively.

Just to say, Thorsten has in this case saved me writing an email, thanks.

To re-iterate - GPU VRAM is a precious commodity, so we should spend it on 
texels you can actually see. While rivets on other aircraft (or static ground 
vehicles) look cool for demo screenshots, they come at a huge cost in terms of 
texels being stored. The mapped texel size calculation that Thorsten is making 
above is one every modeller should be doing, to estimate what detail is 
actually needed. Eg for a building, even an airport terminal, you're rarely 
closer than 50m, often more than 250m for a building outside the airport 
boundary (there are exceptions of course, mostly involving helicopters). 

Save the texels/VRAM for your cockpit interior models, they're much closer to 
the camera and occupy a much larger portion of your field of view :)

Regards,
James

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Int