• 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.

MSFS Blender2MSFS support thread

Status
Not open for further replies.
That is one way of handling it, but I would have used hyphen'd directories instead of too many nested levels, maybe 2 levels deep max. Global\Scenery-World, Local\Scenery-SimObjects, etc...

For instance, when I am building a treeview in an application, I've seen people use XML and the nests get to 100's of levels deep, when you can just use a flat text file and assign node numbers like 1-2-5-6, then when you want to move the node you can simple parse the hypen, rather than reading a file that becomes 500x unnecessarily large. Not that it's wrong to use XML for a treeview (its not), but if you are trying to keep something as optimized as possible, it's a different design.

I appreciate the input though...
 
Last edited:
When running MSFS, the Official/Onestore and Community files are combined in a VFS (virtual file system) which uses an FS-like tree structure with directories such as scenery\global, scenery\world, simobjects, effects, etc.
Looking at your screenshots, it seems that the textures searched for are not found (white colors)
In the DEV mode, it is possible via the menu to browse the VFS and see if the expected files are there or if they have been overwritten by others (identical names). It is a way to investigate.
Yes, indeed, the textures were not found. But they did before the patch. It has nothing to do with identical names, but - as I described above - with the folder structure. After the patch only this specific, complicated folder structure seems to be accepted - not what I had and what was defined in layout.json.... They screwed this up in the patch!
 

Vitus

Resource contributor
As Didier pointed out, MSFS is virtually using the file structure of fsx. Internally, all those packages get flattened out to represent something very similar to FSX. To everyone who worked with the previous versions of the sim will know their way around the folders. However, the packages make things a little bit more complicated. But the dev mode comes with a bunch of very useful tools to debug - especially missing files. Try the "Virtual File System". Or visualize any texture type (albedo, roughness, etc) directly to spot problems. It's cumbersome to set up, but it makes a lot of sense.
And don't forget how MS always insists on backwards compatibility! Maintaining the old folder structure certainly helps with that.


Btw. since you guys keep talking about the texture size being of size to the power of 2... The SDK slightly disagrees with you:
Note: input texture dimensions must be a multiple of 4 pixels and at least 8 by 8 pixels.
 
@SceneryFSX,
As this thread is about Blender2MSFS product, I suggest that you create an another thread and we can try to solve it.

Thanks Lagaffe. I'll delete my post here, and I've created a new thread below:

I posted here originally because I wasn't sure if my problem was the way I was exporting or not with the MSFS Exporter, but I agree it might get kind of long, so I made a dedicated thread above.
 
Yes, indeed, the textures were not found. But they did before the patch. It has nothing to do with identical names, but - as I described above - with the folder structure. After the patch only this specific, complicated folder structure seems to be accepted - not what I had and what was defined in layout.json.... They screwed this up in the patch!

I'm glad you figured it out and got your stuff working, good work figuring that out as it may help others what you noted.
 
SOLUTION FOUND!

  • SCENERY
    • GLOBAL
      • SCENERY
        • modellib.bgl
        • TEXTURE
          • All textures
    • WORLD
      • SCENERY
        • airport.bgl
        • airport_contents.bgl
Changed the references in layout.json to reflect this

And now all textures are back!

So after the patch the sim does not read the json and respect the definitions thera, but it requires that the folder structure above is followed! Bad. Now I have to rebuild all my sceneries and redistribute them.... :mad:

Thank you so much, this worked for me. FINALLY.
 
As Didier pointed out, MSFS is virtually using the file structure of fsx. Internally, all those packages get flattened out to represent something very similar to FSX. To everyone who worked with the previous versions of the sim will know their way around the folders. However, the packages make things a little bit more complicated. But the dev mode comes with a bunch of very useful tools to debug - especially missing files. Try the "Virtual File System". Or visualize any texture type (albedo, roughness, etc) directly to spot problems. It's cumbersome to set up, but it makes a lot of sense.
And don't forget how MS always insists on backwards compatibility! Maintaining the old folder structure certainly helps with that.


Btw. since you guys keep talking about the texture size being of size to the power of 2... The SDK slightly disagrees with you:
Thank god every power of 2 is also a multiple of 4 :)
 
Thank god every power of 2 is also a multiple of 4 :)

And I believe a 2x2 texture works, so reflecting on both our points, then I believe the SDK is wrong technically speaking.

I've never really heard of anything in computers referred to as a power of 4, unless talking about bit quantization of bits over a particular bus path.
 
Last edited:
And I believe a 2x2 texture works, so reflecting on both our points, then I believe the SDK is wrong technically speaking.

I've never really heard of anything in computers referred to as a power of 4, unless talking about bit quantization of bits over a particular bus path.

Not a power of 4 , a multiple of 4
 
EDIT
Mustang expained that technically it is a multiple and not a power, but the end point being, multiple of 2 should work hopefully.
 
Last edited:
I'm having a problem with glass on an airplane, the borders of the glass mesh are a bit transparent, but the middle is black, can't see anything through

I'm using an albedo, metallic and normal textures that started out as based on the default KA 350, then I "made" my own (quotes because it's just the same shade of gray from the KA350 on albedo, red in comp and plain blue on norm), with the same result

on top of that I also noticed the packager ignores the glass textures (I'm using the cmd packager) in the source folder and the package output comes without them, which forces me to manually add them there (with .json files "borrowed" from the KA since it didn't create them)

when I tried the suggestion a few pages back, of using it without the textures, it did work, but it wasn't as reflective as the default planes

also, while we are at it, I noticed some detail glass textures on the base textures folder, how do I use them?

TIA!

hi,

any idea how to fix this?
 
I have a question about day/night cycle for the lights: I have a simple point light, I set "has symmetry" and "da/night cycle" on, but the lights are on all the time in the sim. I have the latest version. What am I doing wrong?
No matter what I try - day/night cycle is ignored. Any ideas?
 
Hi,

I am having a issue when importing a model into FS2020.

1601551465103.png


I have traced the problem to the Detail Textures. Work Perfectly without them, gives issues with them.

1601551590179.png


My knowledge on correctly using detail textures is non existent. My research has brought up nothing.
If anybody can point me in the right direction, I would be grateful.
 
Hi,

I am having a issue when importing a model into FS2020.

View attachment 62916

I have traced the problem to the Detail Textures. Work Perfectly without them, gives issues with them.

View attachment 62917

My knowledge on correctly using detail textures is non existent. My research has brought up nothing.
If anybody can point me in the right direction, I would be grateful.


I have the same question and ran into the same issue. Would love to hear from anyone who has experience successfully using detail maps. And specifically on custom objects coming out of blender (as opposed to just adding them to a texture polygon in the editor).

Thanks so much!
 
Hi guys! Emissive texture doesn't work with this version? Who tried it? I lost the illumination in houses windows at night, after converting with version 0.4. Or is it a problem that appeared after updating the msfs?
 

Vitus

Resource contributor
My knowledge on correctly using detail textures is non existent. My research has brought up nothing.
If anybody can point me in the right direction, I would be grateful.

All the scenery stuff is not my area of expertise, so I can't really tell you what's going wrong there. Are the texture sizes OK? Also check the GLTF file to see that the extensions were properly added. Other than that, I have nothing and hope that someone else can help out!

@MrJam there was an issue updating from previous versions of the toolkit - sometimes the emissive color adjustment was a bit wacky. I'd recommend you reset the material mode by simply selecting some other material mode and then switch back. This will rebuild the shader node tree for the material and should set up your emissive properties correctly.

PLEASE NOTE that for sceneries, you probably want to set the emissive color value to [1,1,1] (or even higher!), while for aircraft lights you'd want to set the value to [0,0,0].
 
I'd recommend you reset the material mode by simply selecting some other material mode and then switch back. This will rebuild the shader node tree for the material and should set up your emissive properties correctly.
Ok, I'll try it. Thanks for answer.
 
Status
Not open for further replies.
Top