Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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: [email protected]
To: [email protected]
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-26 Thread 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

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Renk Thorsten 
> Recently I was told that some planes have liveries of so high resolution  
> that you have to install low resolution versions to have a decent fps  
> during multiplay. But doesn't FG use mipmaps for liveries? If not then  
> are there plans to do so? Or should the livery be prepared in a certain  
> way to trigger mipmap generation?
>
> Perhaps mipmaps should also be applied to interiors as sometimes you can  
> see the insides through the window.

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.

* 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread jean 

On 26/09/2013 01:16, Tomash Brechko wrote:
2013/9/26 jean pellotier >


it's the same here, FG take age sometimes to load 3D stuff, mostly
because it create the mipmap on the fly,


At this point I'm kinda lost :).  Back to my original question then: 
does FG mipmaps liveries by default, or does it not?  It's not clear 
whether you include aircrafts in "3D stuff" or not :).


Yes the aircrafts are included in "3D stuff" and FG create the mipmaps  
when loading the planes.


jano
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Tomash Brechko 
2013/9/26 jean pellotier 

> it's the same here, FG take age sometimes to load 3D stuff, mostly
> because it create the mipmap on the fly,
>

At this point I'm kinda lost :).  Back to my original question then: does
FG mipmaps liveries by default, or does it not?  It's not clear whether you
include aircrafts in "3D stuff" or not :).


-- 
  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread jean pellotier 
Le 25/09/2013 23:39, Gary Neely a écrit :
>   I've felt my machine come to a crawl while
> certain planes are loaded in MP-- I had to remove some because they
> were too much of a hit for my poor aging system.
it's the same here, FG take age sometimes to load 3D stuff, mostly 
because it create the mipmap on the fly, from the png/jpg/rgb texture, 
and this operation is long specially for huge textures!

I didn't removed them, but converted them to dds with a bash script:
http://wiki.flightgear.org/Fr/convertir_un_avion_en_dds

About FG and dds texture, could it be possible to propose a dds version 
of our planes in an official manner, or do i need to make a paralel 
hangar, with hidden advertisings?

I'm fine with fgdata having png/rgb textures, as they are lossless and 
easy to work on, and a non dds version is still needed for who don't 
want to use dds (for patent issues, or other reasons).

If you want to try a dds version, to make an opinion, i've converted 
some here:

http://janodesbois.free.fr/flightgear/dds_planes_2.12/

you will need the Generic folder, and you can add the Instrument and 
Instrument-3d, to have full dds planes.

my concern is not to force dds use, but to allow a better mp experience 
(try to change livery for example, in external view).

jano


--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Tomash Brechko 
But high res liveries already there, so the choice is between using more
memory or having low fps.  I think the choice should be obvious: if you do
have spare memory, not using it doesn't make you any good.

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.


2013/9/26 Gary Neely 

> OK, I see what you're getting at now-- the selection of the mipmap for
> rendering rather than the memory footprint.
>


-- 
  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Gary Neely 
On Wed, Sep 25, 2013 at 4:46 PM, Tomash Brechko
 wrote:
> 100 / cos(45), but you get the idea ;)


OK, I see what you're getting at now-- the selection of the mipmap for
rendering rather than the memory footprint. Yes, that makes sense to
me-- the engine should be able to choose a mipmap that best fits the
screen scale based on distance, so for a larger base image it's
dropping down deeper into the mipmaps.

There is still the issue of resources. A 4096x4096 texture without an
alpha channel is about 50MB, a 1024x1024 is about 3MB. Add +33% for
mipmaps. So a single 4096 texture would buy a lot of 1024's. Also, I
believe the larger the image, the more initial overhead is necessary
to create the mipmaps, unless the image is a DDS type in which case
mipmaps can be pre-generated. So the larger the image, the more memory
resources required, and there's a bigger load hit when the resources
are initially loaded. I've felt my machine come to a crawl while
certain planes are loaded in MP-- I had to remove some because they
were too much of a hit for my poor aging system.

-Gary

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Tomash Brechko 
100 / cos(45), but you get the idea ;)


2013/9/26 Tomash Brechko 

> On second thought I'm starting to have doubts about what you are saying
> being true.  I thought that the engine chooses right mipmap size based on
> the estimate of the dimensions of the resulting screen projection.  And if
> it works like you describe than there should be some absolute scale for all
> textures that says what mipmap level corresponds to what resolution.  I.e.,
> if the fragment is going to be about 100 pixels wide, and is at a 45 degree
> angle, the engine should choose the texture no less than 256 pixels wide
> (closest from above power of two to 100 * cos(45)).  You say it will choose
> minpam level X - based on what criteria?
>
>


-- 
  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Tomash Brechko 
On second thought I'm starting to have doubts about what you are saying
being true.  I thought that the engine chooses right mipmap size based on
the estimate of the dimensions of the resulting screen projection.  And if
it works like you describe than there should be some absolute scale for all
textures that says what mipmap level corresponds to what resolution.  I.e.,
if the fragment is going to be about 100 pixels wide, and is at a 45 degree
angle, the engine should choose the texture no less than 256 pixels wide
(closest from above power of two to 100 * cos(45)).  You say it will choose
minpam level X - based on what criteria?
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Tomash Brechko 
Ah, I see your point now, sorry.  Still, crunching 256x256 texture to
produce a 10-pixel image of a plane at a distance is surely a lot better
than crunching original 4096x4096.


2013/9/26 Gary Neely 

> I used the first mipmap level as an example of the effect at any given
> mipmap reduction level, not an artificial limit
>

-- 
  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Gary Neely 
On Wed, Sep 25, 2013 at 3:37 PM, Tomash Brechko
 wrote:
> Why limit yourself to only one downscale level?  Mipmap can go several
> levels down, so it doesn't make much difference whether you started 4096 or
> 2048 (leaving space issues aside).


I used the first mipmap level as an example of the effect at any given
mipmap reduction level, not an artificial limit. Mipmap level is
determinied by virtual viewing distance to the object and image
filtering mechanisms. For any given mipmap level, a mipmap for a
higher resolution texture compared to a mipmap of a lower resolution
texture will have the same size ratio as their base images. So the
initial texture size makes a substantial difference.

-Gary

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Tomash Brechko 
Why limit yourself to only one downscale level?  Mipmap can go several
levels down, so it doesn't make much difference whether you started 4096 or
2048 (leaving space issues aside).

I suppose mipmaps aren't used for liveries in FG.  What would be the cost
to do so?  It doesn't sound right that every user should replace liveries
on their side to run MP, and one can't tell in advance what other aircrafts
she will encounter.


2013/9/25 Gary Neely 

> On Tue, Sep 24, 2013 at 6:04 PM, Tomash Brechko
>  wrote:
> > Hello,
> >
> > Recently I was told that some planes have liveries of so high resolution
> > that you have to install low resolution versions to have a decent fps
> during
> > multiplay.  But doesn't FG use mipmaps for liveries?  If not then are
> there
> > plans to do so?  Or should the livery be prepared in a certain way to
> > trigger mipmap generation?
> >
> > Perhaps mipmaps should also be applied to interiors as sometimes you can
> see
> > the insides through the window.
> >
> > --
> >   Tomash Brechko
>
>
>
> Use of mipmapping only mitigates the issue. If a very high resolution
> 4096x4096 texture is being used, the first level of mipmapped texture
> reduction is 1/4 of that in pixel area, or 2048x2048. If a texture of
> more modest resolution like 1024x1024 is used, then the first level of
> mipmap reduction would result in a 512x512 texture. So a high
> resolution base texture is still going to result in a larger mipmap
> texture than a lower resolution base texture at the same mipmap
> reduction level.
>
> This is true of any texture in the scene where the object is not
> culled by LOD settings, etc. Liveries just tend to be the biggest
> hits.
>
> The results are cumulative for your video hardware. So in multiplayer,
> all those additional aircraft in the scene using high-resolution
> textures will tax your video card more heavily than aircraft using
> lower resolution images, even with mipmapping enabled.
>
> Hope that helps,
>
> -Gary aka Buckaroo
>
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Mipmapping of liveries

2013-09-25 Thread Gary Neely 
On Tue, Sep 24, 2013 at 6:04 PM, Tomash Brechko
 wrote:
> Hello,
>
> Recently I was told that some planes have liveries of so high resolution
> that you have to install low resolution versions to have a decent fps during
> multiplay.  But doesn't FG use mipmaps for liveries?  If not then are there
> plans to do so?  Or should the livery be prepared in a certain way to
> trigger mipmap generation?
>
> Perhaps mipmaps should also be applied to interiors as sometimes you can see
> the insides through the window.
>
> --
>   Tomash Brechko



Use of mipmapping only mitigates the issue. If a very high resolution
4096x4096 texture is being used, the first level of mipmapped texture
reduction is 1/4 of that in pixel area, or 2048x2048. If a texture of
more modest resolution like 1024x1024 is used, then the first level of
mipmap reduction would result in a 512x512 texture. So a high
resolution base texture is still going to result in a larger mipmap
texture than a lower resolution base texture at the same mipmap
reduction level.

This is true of any texture in the scene where the object is not
culled by LOD settings, etc. Liveries just tend to be the biggest
hits.

The results are cumulative for your video hardware. So in multiplayer,
all those additional aircraft in the scene using high-resolution
textures will tax your video card more heavily than aircraft using
lower resolution images, even with mipmapping enabled.

Hope that helps,

-Gary aka Buckaroo

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel