Is there a penalty for having unused objects in the PackageSources

[jgarnold]

For example will the output Packages be larger than it could be for having objects in PackSources which are not used in the project?

 

[arno]

Any object in the package sources folder will end up in the final bgl file. So, yes, unused objects will increase the file size. But I don't think there is much of a penalty else.

 

[=rk=]

Actually FSPackagetool.exe is fairly discriminating about what it will compile. Any unrecognized documents in the package directory containing the model, texture and .cfg files will be flagged and prevent a build, however we are allowed to store as many files and folders within the Model folder as we like, so long as we have edited to obscure the "xml" suffix. Any unrecognized xml files in the model folder or within subdirectories of the model folder will also prevent a build.

As to textures, knock yourself out. You can leave your package sources texture folder as a texture repository, call only the ones you want and find only the ones you expect in your final build. Since this is the time of year - or life - that I am unable to be certain of what I am certain of, I ran a quick test to confirm using Arno's mugshot and the SimpleAircraft sample; images below (notice the file modification dates have changed).

Before:

After:

EDIT:

One thing I wanted to add is that textures that are not actually linked can still end up in the final texture folder. If you have software that stores textures as "materials," then those must be removed from the model using the 3d software, or just hide them from FSPackagetool.exe. Never used to have this problem with just Sketchup and MCX, but 3ds Max stores textures differently, it is as if once one has applied a picture of shingles to a polygon, now that model contains a "shingle material model" that has to be purged or used.

 

[jgarnold]

Thanks arno and Rick. Yes I had also meant to ask if superfluous textures would also have an effect. They are a little easier to 'manage' as most if not all of the textures as I keep textures for an object in the same folder as the object and so occasionally I delete all entries in the texture folder and then copy them back from each scenery object folder AND if I miss one then I see it in PINK in MSFS.

I will 'revisit' FSPackagetool.exe which I haven't used in a very long time.

And the extra filesize (containing unused scenery objects) won't worry my disk capacities but would make downloading by others slightly longer (and also slightly eat up their diskspace).

 

[=rk=]

Except FSPackagetool.exe performs all build operations, whether using MCX, DevMode or by dropping a project.xml onto the FSPackagetool.exe icon.

 

[jgarnold]

by dropping a project.xml onto the FSPackagetool.exe icon.

That's the only way I know of using it.

 

[=rk=]

Yep recently been using the Build button because it's at the point where it seems like it can start being tuned and while the Aircraft Editor probably works for any aircraft, this one needs to reside in the VFS so the edits can be seen after resynching. The Console seems much less informative in this mode, imo.

 

[Anthony31]

That's the only way I know of using it.

Batch files are useful

"C:\MSFS SDK\Tools\bin\fspackagetool.exe" [name of your project].xml

pause

Make a text file and make the suffix .bat then use the above text. Put the batch file into the same folder as your .xml (or put it on your desktop and change the pathway to point to your .xml)

I find it's just a little bit easier to double click on the batch file rather than dragging and dropping the xml onto the fspackagetool icon.

 

[jgarnold]

Thanks. Yes I have used batch (.bat) files in the past but not for fspackagetool as I didn't know for a start and it doesn't seem all that easier to use than simply dragging the xml file onto it (eg it means I would have to create a .bat file as well). Useful I guess so thanks for the tip.

 

[KAI31]

I used to use a bat file for projects, but I was faced with the fact that when copying, I had to manually rewrite the paths in the file itself, otherwise it would be a mess (you can just forget to do this or enter the wrong path). Then I simply started using the shortcut created in the location and cut from the directory where fspackagetool.exe is located. The convenience is that the shortcut is located in the project folder next to xxx_progect.xml; when copying the project, the paths do not need to be changed and everything is in its place. And dragging xxx_progect.xml to the shortcut takes the same two clicks on the bat file. But there are many options and who likes which one...

 

[Marionettework]

When do you guys find it convenient to use fspackagetool instead of clicking “build all” in the SDK, what is the use case? When I build my scenery it’s always after editing something in the SDK and looking at the resulting change, so I’m curious when it would be convenient to build a package outside the sim.

Regarding files in PackageSources, I recently did some cleanup in my first project where I used files in various places without understanding exactly where they were needed. I saved several gigabytes of 4K PNG files by deleting duplicates. Here’s my current “best practice”, let me know if you agree or use something better:
- Store all texture files for all models under a “texture” subfolder of the modelLib: I noticed that the textures MUST be under the modelLib in order to build the package correctly, so use a common texture folder for all models.
- In Blender, assign texture files from that same “texture” folder to all my materials: this avoids all texture file duplication by essentially exporting the textures to themselves. I’m still not sure if I can simply not export the textures at all in the exporter plugin or if this will cause issues with some PNG files (e.g. missing properties).
- Store Blender models outside of PackageSources to avoid “unsupported file” warnings in the SDK, e.g. somewhere else in that project folder
- Store source texture files outside of PackageSouces for the same reason

To minimize warnings in the SDK about “missing roughness, occlusion and metallic texture”, originally I thought the SDK discourages you from leaving these texture slots unassigned. But after reading the SDK docs about optimization I saw that they actually encourage you to leave out the ARM textures and even leave out the diffuse texture for lower LODs, so I guess it’s perfectly OK to have no textures. They encourage use of “vertex color” and I’m not totally sure what that is in Blender, is it when you simply assign a color to the MSFS Standard material?

 

[rhumbaflappy]

The current Asobo exporter doesn't include vertex colors as an option. But it does exist. First you'd need to learn to use the Vertex Paint Mode. You tube helps here.

Then you need to use the Shading workspace to connect the vertex color to multiply the final albedo color. RonH has a alternate exporter that includes the vertex color in the Shader already, which simplifies this.
https://github.com/ronh991/glTF-Blender-IO-MSFS/tree/3.3.x---Combined-Fixes

I wouldn't wait for Asobo to fix this... the Asobo exporter is dead in the water, even though there are some problems with it. Regarding the use of vertex coloring, I'm not sure if it really makes a big difference in the load on the GPU. Dropping the Comp and Normal for distant LODs would have a greater effect I think.

 

[=rk=]

Vertex color has no draw call making it especially attractive for LOD models where texture detail does cost draw calls.

 

[jgarnold]

The current Asobo exporter

That reminds me. Has the Asobo exporter been updated yet to work on Blender versions above 3.3?
Someone from the Blender exchange sent me a blender file which caused 3.1 to crash and when I asked him could he send one created with an earlier version (that 4.2 would you believe), and which he did, he suggested I upgrade Blender and I had to tell him I can't because of the Asobo exporter.
If not is there anything on the horizon to suggest it will be upgraded and when? It version much now 'outdated' with respect to current Blender versions. Maybe a development fund where we can donate to (I certainly would).

 

[=rk=]

Maybe a development fund where we can donate to (I certainly would).

Kind of like a super premium flight simulator. Everyone has to pay to play, but if you really want it to work, then you have to pay. I mean it's already pixels and bits anyway, might as well milk them for all they're worth.
You will likely get a current Blender exporter, along with a chance to donate money for it, starting sometime shortly (hopefully) after tomorrow!

This will be my last message in the world, for 2023, see you all in the year of MSFS 2024!

 

[jgarnold]

Rick. It's already 2024 here in Australia .
Will we get to see Kilroy again in 2024? You have no idea how I miss him

 

[pinkjr]

Ive been playing with SDK developer tool for s few weeks now, and noticed that it will only pack the items under the Package Source object library, and its textures. So if you do any cleaning there it will reflect on your Scenery package. Hope that helps!

 

[=rk=]

Will we get to see Kilroy again in 2024? You have no idea how I miss him

Kilroy was here, but there was an unfortunate circumstance almost a year ago. I put a lot of trust in someone I thought to be a friend that turned out ot be anything but that, so as to be expected, Kilroy evokes mixed memories. He probably wouldn't have it any other way.

 

[jgarnold]

Ive been playing with SDK developer tool for s few weeks now, and noticed that it will only pack the items under the Package Source object library, and its textures. So if you do any cleaning there it will reflect on your Scenery package. Hope that helps!

That's interesting. It would be really neat though if there was a 'clean' function which would report on anything in the PackageSouces which were not used (ie in the airport.xml). Recently to fix another 'problem' I decided to 'append' 4 scenery objects into a single larger object and then remove the existing 4 separate objects in the editor and add the new (appended) object. Even though the original 4 objects were not placed anymore in my scenery the resulting Package grew a few Mb. I remembered the names of the original objects so removed them from PackeSources and did BUILD ALL again and the Package size was reduced.

The only method I know of to check if there are any unused objects is to edit the airport.xml, and cross check the lines which contain <!-- SceneryObject name: nnnnnnnnnnn --> (where nnnnnnn is the object name) with the objects in PackageSources, remove any not in the airport.xml and then do another BUILD ALL. This can very laborious especially when you have lots of duplicate scenery objects but can result in a package quite a few Mb in size smaller. Maybe there is an easier way which I would love to know.

Kilroy was here.

That is concerning my friend. Hope all is now well. Hopefully he will 'raise his head' again one day.