Why some devs are able to achieve very detailed airports / sceneries  with less than 400-500 MB , but some can only achieve less or equal amount of details with 3-4 GB ? 

Edited October 31, 20214 yr by kt069

I believe it mostly comes down to the size of the textures.

I don't want to play the moderator here, but those three exclamation marks accomplish nothing but annoyance to the reader.

Just now, Fiorentoni said:

I don't want to play the moderator here, but those three exclamation marks accomplish nothing but annoyance to the reader.

I am most annoyed by the space between "Sceneries" and "!!!".

On topic: What Tuskin38 said. You can model the interior of every building and still be well under 500mb if you use lower resolution textures. On the other hand, you can easily fill up 3 GB only by putting ultra high resolution wall textures on the terminal.

1 minute ago, crimplene said:

I am most annoyed by the space between "Sceneries" and "!!!".

And why is 'difference' capitalized 🤓

2 minutes ago, Sethos said:

And why is 'difference' capitalized 🤓

Every noun is capitalized, obviously a common thing in the OPs mother language (e.g. german). But I think we digress 🙂

36 minutes ago, Fiorentoni said:

I don't want to play the moderator here, but those three exclamation marks accomplish nothing but annoyance to the reader.

In french, it is common :

"Le point d'exclamation peut être doublé, triplé et même combiné au point d'interrogation pour exprimer l'incrédulité, l'étonnement"

No annoyance for me !!!

41 minutes ago, Fiorentoni said:

I don't want to play the moderator here, but those three exclamation marks accomplish nothing but annoyance to the reader.

I suspect that the three exclamation marks indicate the author's excitement over having unlocked some global mystery, a secret pathway to the nirvana of whatever....

Thanks for grammar clarifications. I tried to correct most of them. Please ignore grammar check 🙂

I would like to get opinions on the subject.

Textures are most probably the cause of the size but personally I would prefer to have design with smaller size in harddisk space, where it represents all the details but having a bit optimised textures.

 

Edited October 31, 20214 yr by kt069

17 hours ago, kt069 said:

Why some devs are able to achieve very detailed airports / sceneries  with less than 400-500 MB , but some can only achieve less or equal amount of details with 3-4 GB ? 

A proper reply would probably too long, and include a mini-course in modeling/texturing, which won't fit here and will bore everybody.

But, in general, you shouldn't assume anything about a product just looking at its size. Sometimes a small size might be a result of clever optimization, but not always. Sometimes big size might be a result of more detailed modeling/texturing, but not always.

It's just not possible to generalize or give something like a "universal" metric, especially if you are comparing different airports. Even at roughly the same real-life size, different airports might have very different sizes when modeled, depending how they are in reality. A very modern airport made using lots of repeating elements and glass, like Dubai for example, can probably modeled with far fewer textures than something like KJFK, which is a patchwork of 8 entirely different terminals, each one made in a different time period with its specific style and materials.

More interesting questions might be:

"Why developer A modeled airport XXXX and took 500MB, while developer B also modeled XXXX and took 4GB ? Both airports looks just equally fine to me"

Assuming both looks fine compared to real life, this might just be the case of developer A modeled in a "smarter" way, for example using lots of modularity, in order to reuse common architectural elements to better optmize use texture space. This method also *usually* gives also performance benefits too so, if the real airport was suitable to this modeling technique, it's likely developer A did a better job than B here, because B failed to recognize there could be some savings to be achieved. Smarter modeling usually takes more time, especially during the planning phase.

"Why XXXX from A looks a bit boring/default, although it's functionally accurate, while the same airport from B looks more real ?"

In this case, maybe A achieved memory savings by not fully using PBR, perhaps assuming its only needed for "metal effect" ( a common mistake ) so, most of the airport used simpler materials, which takes 1/3 of texture space, but they look "plain" and "boring". If developer B used PBR for everything, the scenery will integrate better in the MSFS graphic engine, which is 100% PBR, so non-PBR assets tend to stick out as "flat". Or, perhaps, developer A used lots of default library objects and/or textures, without even taking time to customize them a bit (with MSFS it's extremely easy to take a default texture and tweak the appearance just by apply colorization to it). In this case, I'd say developer B did the better job but, we can't say that unless taking FPS/Memory usage into account too. If the airport from A is mich lighter on memory and fps, both products have a full right to coexist, depending on users preferences and hardware used.

Right now, you don't have *that* many complex 3rd party airplanes which will eat up 50% of your RAM/VRAM so, airport developers have it easier by simply adding more and more stuff in. In the next years ( or possibly even sooner, when DX12 will come ), the hard reality of VRAM being a previous resource which right now is even incredibly expensive to update will struck, and I guess users might discover the value of optimization again.

"Why XXXX from A looks as good as the one from B, takes only 500MB it has a better fps, and it works on Xbox too ?"

As a complement to the previous one, I might definitely say A DID a better job here but, before saying A is a better developer than B, we cannot possibly know if he just got lucky because airport XXXX was more suitable to optimizations and/or it was in an area easier to work with. Sure, B did the same airport less efficiently, but we can't be sure if A tried to do "difficult airport YYYY in fps-heavy area" if he could achieve the same results.

Also, while textures number/resolution are usually the things that contributes the most to an airport install size, you can't easily say a product is "better" ( who decides what "better" means anyway ? and we haven't even touched the matter of price... ) just because it's larger or smaller.

And, it's not automatic if something is "bigger", it will also automatically be "heavier on fps". Again, it depends. Using multiple LOD levels for objects, for example, will INCREASE the installed size but, it might have a dramatic (positive) effect on fps.

 

Edited November 1, 20214 yr by virtuali

2 hours ago, virtuali said:

A proper reply would probably too long, and include a mini-course in modeling/texturing, which won't fit here and will bore everybody.

Good and interesting explanation. On a side note (speaking of addons), how is GSX coming along (I know it's a sneaky question to ask but I couldn't resist!)?

@virtuali,Thank you for your detailed explanation, your time and effort.

Edited November 1, 20214 yr by Ray Proudfoot
Long quoted post removed.

We should also consider that some developers, in addition to the complexity of the airport textures and building models used in their projects, improve the terrain details using high resolution imagery and custom colouring to the landscape, including terrain and its vegetation, that adds up a lot of data to the overall size of the product.

Examples of the above are the good scenery that's been released for the Hawaiian islands.

3 hours ago, steve310002 said:

Good and interesting explanation. On a side note (speaking of addons), how is GSX coming along (I know it's a sneaky question to ask but I couldn't resist!)?

It's coming along just fine, and we are adding new features too.

As explained many times on our forum, we can't just "port" GSX to MSFS, so we could make a quick buck with something users are expecting.

It's not really a coding issue, our code already works fine on MSFS,because is mainly platform neutral but, from a graphical point of view, we don't want to just recompile the old models/animations/textures, because many of them were made taking into account some limitation coming from FSX, especially with character animations. Sure, the latest P3D PBR objects are much better, but we want to raise the level again for MSFS, which basically mean redoing all the models from scratch.

Fromt he coding point of view, it already works, we are just waiting Asobo to fix a couple of things still missing or bugged from the FSX SDK. Many other add-ons require these features, so we are confident they'll arrive, eventually.

Edited November 1, 20214 yr by virtuali