Just to clarify what I commented on earlier ... the setting 1024, 2048, 4096 simply caps the Mipmap level for the texture resources.  The actual texture sizes in the texture files being used to display terrain, airports, aircraft, etc. are still loaded, however the resources created from loading the texture file (DDS) will be created based on mipmap level setting (i.e. 1024, 2048, 4096).  

 

 

 

Hi Rob ,

 

hmm i might be confused here.

 

I have installed Flytampa EKCH with the extra HD Pack. Is is correct that even if i have TML=1024 the memory is increased because of this HD Pack of the airport?

 

In FSX using FSDT Add-on manager from within the FSX menu the amount of VAS is noticed. You can switch between 1024 and 2048 and see VAS increase and then again decrease when you switch back. This option is not aviable in P3D i can tell.

 

Thanks

Michael Moe

Is is correct that even if i have TML=1024 the memory is increased because of this HD Pack of the airport?

 

That is my understanding but I haven't seen P3D code so I really can't confirm but I have tested this with other 3rd party airports ... but I do know that in DX11 you load the .DDS file, then you allocate a resource and define the maximum Mipmap level for that resource (i.e. 1024, 2048, 4096) which is what the GPU will process.

 

I have confirmed this with other airports where I had Global setting at 1024, but had different "sets" of texture files with different max mipmap levels (in 1024, 2048, and 4096) -- files were of course different in size also.  My VAS usage was considerably less when using 1024 files vs. 4096 files -- keeping in mind my Global setting is 1024 in all cases.  

 

You might be able to confirm this with FSDT KLAX ... use the SDK ImageTool to open a KLAX file(s) that are 4096 texture ... now in the ImageTool you can do an "Extract Mipmaps" ... then simply delete the 4096 and 2048 mipmap and save the file -- it should be considerably smaller and will contain max mipmap of 1024.  Be warned, you can NOT distribute these modified files and I'm not sure if this constitutes any license violations with FSDT so make sure you get all that squared away before proceeding ... also be aware it would void any possible support from FSDT.  I have used this process with other airports (with appropriate permission) and it has in some cases save me 200-300MB in VAS.

 

From a 3rd party developer's perspective, I imagine this is sorta a pain to deal with ... it means they can't just deploy one set of 4096 texture sets IF their goal is to reduce VAS -- they need to deploy a 4096 set, a 2048 set, and a 1024 set otherwise the Global setting of 1024 isn't going to make much of a difference in VAS only what the GPU will work with.

 

But I'm willing to bet that most people would prefer to give up slightly less detailed textured airport (which really is only noticeable when you arrive at the gate and your very close to a textured object (gate/terminal building) than having an OOM on approach after 10+ hours of flight.  

 

Cheers, Rob.

That is my understanding but I haven't seen P3D code so I really can't confirm but I have tested this with other 3rd party airports ... but I do know that in DX11 you load the .DDS file, then you allocate a resource and define the maximum Mipmap level for that resource (i.e. 1024, 2048, 4096) which is what the GPU will process.

 

I have confirmed this with other airports where I had Global setting at 1024, but had different "sets" of texture files with different max mipmap levels (in 1024, 2048, and 4096) -- files were of course different in size also. My VAS usage was considerably less when using 1024 files vs. 4096 files -- keeping in mind my Global setting is 1024 in all cases.

 

You might be able to confirm this with FSDT KLAX ... use the SDK ImageTool to open a KLAX file(s) that are 4096 texture ... now in the ImageTool you can do an "Extract Mipmaps" ... then simply delete the 4096 and 2048 mipmap and save the file -- it should be considerably smaller and will contain max mipmap of 1024. Be warned, you can NOT distribute these modified files and I'm not sure if this constitutes any license violations with FSDT so make sure you get all that squared away before proceeding ... also be aware it would void any possible support from FSDT. I have used this process with other airports (with appropriate permission) and it has in some cases save me 200-300MB in VAS.

 

From a 3rd party developer's perspective, I imagine this is sorta a pain to deal with ... it means they can't just deploy one set of 4096 texture sets IF their goal is to reduce VAS -- they need to deploy a 4096 set, a 2048 set, and a 1024 set otherwise the Global setting of 1024 isn't going to make much of a difference in VAS only what the GPU will work with.

 

But I'm willing to bet that most people would prefer to give up slightly less detailed textured airport (which really is only noticeable when you arrive at the gate and your very close to a textured object (gate/terminal building) than having an OOM on approach after 10+ hours of flight.

 

Cheers, Rob.

Regarding the last from your answer you are right but what do you think of the addonmanager From FSDT inside FSX were we can change the tml on the go. It does effect VAS. Tested it plenty back and forward. P3DV2 does not come with these options. They are disabled in the addon manager. I will uninstall EKCH and just install standard textures.

 

EGLL is even worse with 3.8 gb with your longhaul settings. at gate 554

 

Thanks Rob

 

Michael Moe

 

 

what do you think of the addonmanager From FSDT inside FSX were we can change the tml on the go. It does effect VAS. Tested it plenty back and forward. P3DV2 does not come with these options. They are disabled in the addon manager.

 

I don't know how FSX and/or DX9 or DX10 API work with .DDS and mipmaps ... I'm just letting you know about DX11.  As far as Virtuali Add-on manager settings ... I'd rather not discuss and would prefer you ask the folks at Virtuali directly.  But I do know that most (dare I say ALL) airports being produce (for FSX/P3D) target FSX as primary and then retro fit to P3D ... that's just a market share reality ... it may shift over time just as FS9 shifted to FSX.

 

If I get time, I might show you the VAS difference in P3D using the method I described above ... including visual difference at various distances to the object and it's textures.

 

FlightBeam use 1024 and 2048, FSDT use a lot of 4096 (especially the more recent releases), some of Orbx newer release use 4096 ... just for reference a 1024 texture file is 1,366 KB, a 4096 texture file is 21,846 KB (21MB)... that's approximately 16 X larger.  If an airport has say 15 of these 21MB files, that's 320 MB plus other aux files to make up the airport ... vs. 1024 set that's only  20 MB total ... that's a pretty significant difference.  Obviously these aren't usually all loaded at once, it'll vary based on view and zoom ... but that's why when I test I do a full 360 pan in VC, then exit to spot zoom out as much as possible and do another 360 PAN ... get as much loaded as possible.

 

Cheers, Rob.

FSDT uses 4096 ground textures some building textures and other textures (see KLAX_4096_SF01.DDS ...) ... you can use the SDK ImageTool and take a look at them ... not all FSDT KLAX textures are 4096, but many are.

The reason being that some of their newer airports like KLAX use a lot of 4096 sized textures rather than a bunch of 512 or 1024 sized textures is to reduce draw calls. They used to use a bunch of smaller texture sheets but after Umberto and team did some testing and research, found that they could gain more performance and fewer draw calls by cramming more of the smaller textures into a larger 4096 texture sheet.

 

If you compare their older airports scenery/texture folders you will see that the older airports have tons of texture files but their newer sceneries have far fewer files because they are condensed into larger sheets.

 

Now, if they were still using just as many texture sheets as they used to and they were all now 2048 or 4096 we'd be in big trouble as far as memory consumption, just like the older ORBX Melbourne and Brisbane airports that used tons of 2048 and 4096 texture sheets.

 

So basically, even though the newer FSDT airports have some large texture sheets, since they contain so many textures for more models, they essentially are still only displaying those models as textures that would normally have their own texture sheet of 256, 512 or 1024.

 

 

Sean Campbell

Hi Sean,

 

Interesting ... I did notice that ... have they re-tested this optimization with P3D DX11 to confirm it's still beneficial?  

 

Would this optimization shift the burden to the CPU rather than the GPU ... I can certainly see the logic behind the optimization, draw calls are indeed expensive with DX11 (and hence the desire for batching/instancing), but wouldn't there need to be CPU-based transformations with such an optimization?

 

Cheers, Rob.

Hi Sean,

 

Interesting ... I did notice that ... have they re-tested this optimization with P3D DX11 to confirm it's still beneficial?

 

Would this optimization shift the burden to the CPU rather than the GPU ... I can certainly see the logic behind the optimization, draw calls are indeed expensive with DX11 (and hence the desire for batching/instancing), but wouldn't there need to be CPU-based transformations with such an optimization?

 

Cheers, Rob.

 

To be honest I don't know if they have tested it with P3D DX11, I'd have to ask Umberto. However, it seems logical that the same methodology would hold true for it as far as draw call efficiency. Knowing Umberto, I'd imagine that he has already researched or tested to make sure this would hold true, but I am just guessing knowing how through he is and how he likes to take advantage of using the most efficient way possible to design large airports with as minimal VAS usage as possible.

 

I believe this was also the way Flytampa was able to model and texture the entire city of Dubai while still keeping VAS usage low performance overall high.

 

Come to think of it, Paulo Richard who designs the Mega Sao Paulo and Rio scenery does the same and is able to cram hundreds of high rise buildings into his Sao Paulo scenery, all with no noticeable hit to FPS or VAS.

 

Sean Campbell

 

 

To be honest I don't know if they have tested it with P3D DX11, I'd have to ask Umberto.

 

Might be worth a query ... KLAX does seem to consume considerable VAS even with a mipmap at 1024.  I've compared with Aerosoft's Thessaloniki (Emilios and Ioannis - which also comes with a high density cityscape) that doesn't appear to use this method of optimization and it's performance is VERY VERY good in P3D.  So food for thought ...

 

Cheers, Rob.