• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS20 Scenery Package size is getting too big due to textures!

Messages
15
Country
brazil
Hello.

I'm currently working on a solo project making a payware scenery and i'm facing some issues with how big the scenery file is getting each time new buildings are added. It's not a huge airport nor does it contain many buildings as something like KJFK but it's already 6GB in size! Inibuilds KJFK is only 3GB size and KJFK is 4x the size of my project! This is absurd and i have no idea what type of workaround Inibuilds or any other developer that has made a big scenery discovered and i would love to get advice and guesses about how to fix this issue! It makes no sense!

I am not using 4K textures on everything, i have balanced out texture sizes according to level of detail, what i mean is that i'm using 4K only where needed, always shooting for lower resolutions when possible! I have even tried to use JPGs!

As you can see by the amount of exclamation points, it's an issue that is making me go a bit worried and quite frustrated with the SDK. Any help is welcome!
 
How many textures do you put on each building then? Even if they are not 4K, having many per building can quickly add up.
 
How many textures do you put on each building then? Even if they are not 4K, having many per building can quickly add up.
Hello Arno! Thanks for coming by.

Only one texture set for each building, unless it's a complete separate object like a steel roof, but that happened only once from what i remember. I'm still to optmize one of the buildings with a better unwrap but one building only shouldn't be that big of a trouble i believe, at least not to justify 6GB haha.

I believe there's indeed areas to optmize but i believe the problem is the .dds files that don't care about the size of the original file it seems... But still, 6GB lol

Edit: Altough i've been working on this scenery for quite a while, i'm still new to all of this so i can surely benefit from any past experience you and any one else had and wants to share with me :D
 
Last edited:
Hello.

I'm currently working on a solo project making a payware scenery and i'm facing some issues with how big the scenery file is getting each time new buildings are added. It's not a huge airport nor does it contain many buildings as something like KJFK but it's already 6GB in size! Inibuilds KJFK is only 3GB size and KJFK is 4x the size of my project! This is absurd and i have no idea what type of workaround Inibuilds or any other developer that has made a big scenery discovered and i would love to get advice and guesses about how to fix this issue! It makes no sense!

I am not using 4K textures on everything, i have balanced out texture sizes according to level of detail, what i mean is that i'm using 4K only where needed, always shooting for lower resolutions when possible! I have even tried to use JPGs!

As you can see by the amount of exclamation points, it's an issue that is making me go a bit worried and quite frustrated with the SDK. Any help is welcome!
Is that 6GB compiled or source? Changing the image format wont help with file size since everything gets compiled to DDS. Also check that you're not accidentally adding an alpha channel. You should really be using 16bit PNG's as your source to ensure best quality when it get's compiled to DDS.

If you have multiple buildings that are the same design and you could share textures between, a good way to go about reducing texture size is to make everything with tiling textures and then use the detail albedo channel to add some grunge to the buildings. You can then use vertex alpha to adjust the opacity of the grunge in some areas.

This method, you don't have as much control over your textures, and you loose out on any baking (AO, etc), but if you do all 1K (1024px) textures, you can get some good texel density for a fraction of the file size. You can check out this project I have been working on to see examples of some hangars I have textured by tiling 1K's.

Most of those bigger airports are going to be done with tiling and decals.

The only other option is that you just have to reduce the resolution of your texture sheets. You can try to reduce your COMP and Normal textures by 50% and see how that looks. I've done that a few times.
 
Last edited:
Is that 6GB compiled or source? Changing the image format wont help with file size since everything get's compiled to DDS. Also check that you're not accidentally adding an alpha channel. You should really be using 16bit PNG's as your source to ensure best quality when it get's compiled to DDS.

If you have multiple buildings that are the same design and you could share textures between, a good way to go about reducing texture size is to make everything with tiling textures and then use the detail albedo channel to add some grunge to the buildings. You can then use vertex alpha to adjust the opacity of the grunge in some areas.

This method, you don't have as much control over your textures, and you loose out on any baking (AO, etc), but if you do all 1K (1024px) textures, you can get some good texel density for a fraction of the file size. You can check out this project I have been working on to see examples of some hangars I have textured by tiling 1K's.

Most of those bigger airports are going to be done with tiling and decals.

The only other option is that you just have to reduce the resolution of your texture sheets. You can try to reduce your COMP and Normal textures by 50% and see how that looks. I've done that a few times.
Great Rotornut! Thank you for the reply.

The 6GB is compiled, the source is 2.24GB
It's great to know that it doesn't matter to change the image format because at least everything will look good in the normal textures. I've been paying attention to not export things with alpha channels so that didn't happen really.

About tiling texutres and the use of vertex alpha etc. I've never heard of any of that, it's new to me. You've really shed a light on this with mentioning this technique, i gotta learn it now, i'm glad there's something to do. The project images look great!

I'll be trying these out, including the 50% reduction of comp and normal textures to see if things improve.

Again, thank you so much!
 
Good update, there's hope!

And i'll explain it for the good of future people and my shame lol


Basically my workflow isn't healthy as it is right now, i started searching for possibilities of optmizing texture usage in my scenery and i realized that i've been giving each new fence it's own chainlink png 4k texture, which is obviously terrible. So i'm doing that, replacing all fences with one single texture file.

That would be the only possible case of replacing many textures with only one. I can't do the same to the buildings since that would take a long time to finish and throw the project finish line to another month, which is a time i do not have.

What i'm gonna do next is to decrease the resolution of the COMP (metallic) and the Normal Maps by 50%, sometimes i decrease the COMP resolution by 75% since they are less noticeable than normal maps. Saving more space.

So far with these few changes and there being much more to do, i've already reduced 800MB from the scenery project. And i haven't even finished replacing the fences texture.

At the end, it is a workflow issue rather than a SDK issue. Yes, the shame is on me.

I still need to figure out how to tile textures as Rotornut said, but idk how to do that for buildings.
Thank you both for the replies and thank you Rotornut for the in depth suggestions of improvements! :D
 
Workflow is everything. What you're doing now is probably the best case if going back and reworking is not an option. Just know that if you ever end up releasing on Marketplace for Xbox, this is all stuff you will really want to consider because the Xbox is ruthless when it comes to optimization. More so the Series S and Cloud Gaming.

I think the biggest thing I have learned is that you really have to think about optimization from the start, meaning all the way down to how you build and texture a model. Some models might be able to be done in a similar way to this dock I did a while back:

dock_blender.PNG


I have 12 dock models that all use the same 2K texture sheet, and the texel density is still very good.

The trick is thinking of the parts that would make up the 12 variations as modular.

dock_blender2.PNG


As you can see, out of 12 model variations, I only have a few core parts that I actually pack onto the texture sheet. Then the dock variations get built from these parts.

The tie-off railings are raised into the air so that they don't cast any Ambient Occlusion on the tops of the dock pieces when I go to bake and paint it in Substance Painter. That's because for several of the variations, I didn't want to have the railings. Kind of like how I don't want to have tires on some either.

If I were to build all 12 docks to how I want them and pack all of the pieces to a texture sheet, I would end up with at least a 4K texture sheet, and my models would still have much lower texel density than what they do with my 2K sheet now.

So, if you have something that is going to be reused multiple times in the same model, if you can get away with it, only pack it on the texture sheet once and just duplicate it where you need it on the model later on. Obviously you still need to consider how things will bake when you go to paint, but if the model part is going to bake the same way, it's worth doing to save some space on the texture sheet.

You also may notice that the tire is not on the dock texture sheet. That's because it's reused from a stand-alone model, which uses it's own 1K texture set. So, since I already have that model, and I'm just going to stick it on the side of the dock multiple times, it doesn't make sense for me to pack it to the dock texture sheet. That would be OK if I were only using it for the dock, but it's just a waste of space since I already use the same tire model as a stand-alone.

Now, that is another set of textures being called by the dock model, however I can also get rid of this texture memory in my LODs. Eventually you won't be able to see the detail of the tires in one of the LODs, and at that point the material just gets swapped to Vertex paint that matches the color of the tire. So, the dock texture is still loaded, but now the tire textures get unloaded. Eventually, the same will happen for the dock textures so that at a distance the model is not using any texture memory - just vertex paint with a single material.

Obviously this doesn't benefit every situation, but it can be useful for some situations where you are doing a lot of similar models.


Another tip: you can also expand on this method by using vertex paint for color variations. I can go back to the tire for this example.
Tire_ALBD.jpg
tires.jpg


I have multiple variations of my tire, but they all use the exact same mesh, no matter if they are stacked or a different color. Traditionally, if you wanted different colors, you would just pack all of these tires to a texture sheet and do it all in paint. Or if you were a bit smarter about it, you would just unwrap one tire and have a different albedo texture for each color, but share the Comp and Normal. However, you can go a step further:

In my example, (in Substance) I just painted the base color of my tire white, but kept the roughness and such for the rubber material, and then put any grunge I wanted on top of that, like usual. That gives you an Albedo texture that looks like the above. The comp and normal export the same as they would if I had just painted the tire red in Substance. The only difference is just setting that base albedo color to white instead of using the natural rubber texture. Then in Blender you just go into vertex paint mode and paint (fill) the mesh with whatever color you want it to be.

It wont display correctly in Blender (see the dock photo), but it will come out looking like the above shot when it is rendered in the sim.

With this method, I use the same Material, Albedo, COMP, and Normal texture for each tire. So, I don't need extra albedo textures for each color variation. The texel density stays high since you only have one tire UV on the sheet, and in tern you can use a lower resolution texture or fewer individual textures for the exact same result. Just a little bit more effort, of course.



Doing little stuff like this can really help control bloat when it comes to smaller items. Hopefully I didn't go to far down the rabbit hole with these tips. I just figured it might help to demonstrate a few methods I have been using lately to do things cheaply (performance wise), even if it's not something you might be able to dabble with until your next project. It's also getting late and my brain is going more and more to mush, so hopefully my words just make sense in general... lol

I have a hard time explaining this stuff sometimes, because you really just have to adapt your workflow to the situation while trying to keep everything balanced out. Like, you don't want too much of anything. Use the least amount of materials and textures as possible to do the job, but also sometimes more materials and textures are to your benefit if it means not using a 4K and having an overall lower file size for that model's textures.

Eventually I wouldn't mind doing a video on tiling textures, but since I just tried it for the first time, I'm still messing around with what all works best for me. It's pretty straight forward though. You just use smaller texture(s) that can tile and map your UVs to it. Then scale them up until you get the texel density that you want. Obviously the higher you go, the more you might notice a repeating pattern, but that's where the grunge in the detail texture comes in to help break it up a bit. Just getting the detail texture to blend well can be a challenge sometimes.
 
Last edited:
Just as a comparison. My recently released EFTP has about 15 custom buildings, almost 30 other custom objects, a total of about 100 textures, mainly 2K but some very small and a couple 4K, ranging from 1 Kb to 23 Mb in size (the original png files). There are three simobjects, 15 custom materials, a lot of vegetation polygons, aprons, painted lines, taxiways etc. The total size of the compiled package is 238 Mb!

Is it possible that your project source includes some stuff that you do not need or use in your actual project? 6Gb or more than 2Gb compiled sounds extreme to me...
 
Workflow is everything. What you're doing now is probably the best case if going back and reworking is not an option. Just know that if you ever end up releasing on Marketplace for Xbox, this is all stuff you will really want to consider because the Xbox is ruthless when it comes to optimization. More so the Series S and Cloud Gaming.

I think the biggest thing I have learned is that you really have to think about optimization from the start, meaning all the way down to how you build and texture a model. Some models might be able to be done in a similar way to this dock I did a while back:

View attachment 92861

I have 12 dock models that all use the same 2K texture sheet, and the texel density is still very good.

The trick is thinking of the parts that would make up the 12 variations as modular.

View attachment 92863

As you can see, out of 12 model variations, I only have a few core parts that I actually pack onto the texture sheet. Then the dock variations get built from these parts.

The tie-off railings are raised into the air so that they don't cast any Ambient Occlusion on the tops of the dock pieces when I go to bake and paint it in Substance Painter. That's because for several of the variations, I didn't want to have the railings. Kind of like how I don't want to have tires on some either.

If I were to build all 12 docks to how I want them and pack all of the pieces to a texture sheet, I would end up with at least a 4K texture sheet, and my models would still have much lower texel density than what they do with my 2K sheet now.

So, if you have something that is going to be reused multiple times in the same model, if you can get away with it, only pack it on the texture sheet once and just duplicate it where you need it on the model later on. Obviously you still need to consider how things will bake when you go to paint, but if the model part is going to bake the same way, it's worth doing to save some space on the texture sheet.

You also may notice that the tire is not on the dock texture sheet. That's because it's reused from a stand-alone model, which uses it's own 1K texture set. So, since I already have that model, and I'm just going to stick it on the side of the dock multiple times, it doesn't make sense for me to pack it to the dock texture sheet. That would be OK if I were only using it for the dock, but it's just a waste of space since I already use the same tire model as a stand-alone.

Now, that is another set of textures being called by the dock model, however I can also get rid of this texture memory in my LODs. Eventually you won't be able to see the detail of the tires in one of the LODs, and at that point the material just gets swapped to Vertex paint that matches the color of the tire. So, the dock texture is still loaded, but now the tire textures get unloaded. Eventually, the same will happen for the dock textures so that at a distance the model is not using any texture memory - just vertex paint with a single material.

Obviously this doesn't benefit every situation, but it can be useful for some situations where you are doing a lot of similar models.


Another tip: you can also expand on this method by using vertex paint for color variations. I can go back to the tire for this example.
View attachment 92864View attachment 92865

I have multiple variations of my tire, but they all use the exact same mesh, no matter if they are stacked or a different color. Traditionally, if you wanted different colors, you would just pack all of these tires to a texture sheet and do it all in paint. Or if you were a bit smarter about it, you would just unwrap one tire and have a different albedo texture for each color, but share the Comp and Normal. However, you can go a step further:

In my example, (in Substance) I just painted the base color of my tire white, but kept the roughness and such for the rubber material, and then put any grunge I wanted on top of that, like usual. That gives you an Albedo texture that looks like the above. The comp and normal export the same as they would if I had just painted the tire red in Substance. The only difference is just setting that base albedo color to white instead of using the natural rubber texture. Then in Blender you just go into vertex paint mode and paint (fill) the mesh with whatever color you want it to be.

It wont display correctly in Blender (see the dock photo), but it will come out looking like the above shot when it is rendered in the sim.

With this method, I use the same Material, Albedo, COMP, and Normal texture for each tire. So, I don't need extra albedo textures for each color variation. The texel density stays high since you only have one tire UV on the sheet, and in tern you can use a lower resolution texture or fewer individual textures for the exact same result. Just a little bit more effort, of course.



Doing little stuff like this can really help control bloat when it comes to smaller items. Hopefully I didn't go to far down the rabbit hole with these tips. I just figured it might help to demonstrate a few methods I have been using lately to do things cheaply (performance wise), even if it's not something you might be able to dabble with until your next project. It's also getting late and my brain is going more and more to mush, so hopefully my words just make sense in general... lol

I have a hard time explaining this stuff sometimes, because you really just have to adapt your workflow to the situation while trying to keep everything balanced out. Like, you don't want too much of anything. Use the least amount of materials and textures as possible to do the job, but also sometimes more materials and textures are to your benefit if it means not using a 4K and having an overall lower file size for that model's textures.

Eventually I wouldn't mind doing a video on tiling textures, but since I just tried it for the first time, I'm still messing around with what all works best for me. It's pretty straight forward though. You just use smaller texture(s) that can tile and map your UVs to it. Then scale them up until you get the texel density that you want. Obviously the higher you go, the more you might notice a repeating pattern, but that's where the grunge in the detail texture comes in to help break it up a bit. Just getting the detail texture to blend well can be a challenge sometimes.
This is an awesome read, the more examples the better, this clarified and helped me visualize how i would do things. Thank you so much Rotornut, a Youtube video on this would be insanely useful!
 
Just as a comparison. My recently released EFTP has about 15 custom buildings, almost 30 other custom objects, a total of about 100 textures, mainly 2K but some very small and a couple 4K, ranging from 1 Kb to 23 Mb in size (the original png files). There are three simobjects, 15 custom materials, a lot of vegetation polygons, aprons, painted lines, taxiways etc. The total size of the compiled package is 238 Mb!

Is it possible that your project source includes some stuff that you do not need or use in your actual project? 6Gb or more than 2Gb compiled sounds extreme to me...
I don't think i have unused stuff in my project... But now i know that surely my workflow is to blame with excessive use of textures (since i used to unwrap each object and building). I'll be improving that in the coming days, just gotta learn texture tiling and trimsheets...
 
Back
Top