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

EGCB - City Airport (Barton Aerodrome, Manchester UK)

In fact, I think I need to have a proper session and a play with this.

As long as FS2020 will let me use more than one set of UVs I think it'll work.

So I'd have the diffuse and normals on the first, unbaked set of UVs, so I can use my original textures at their original resolutions. The AO, metal, smoothness map doesn't need the same precision, as it's just altering the general properties of the surface. If a door handle's metallic surface is just 10 pixels on the final texture that doesn't actually matter, as all the detail comes from the diffuse and normal map. So I bake the AO, Metal and Roughness to the second, auto-unwrapped set of UVs, combine the channels into an RGB image and cross my fingers ^_^

I'll give this a go tonight - it all hinges on whether FS2020 recognises more than one set of UVs (maybe I could use the detail maps? Are they a separate set of UVs or just a scaled version of the main textures?)
 
In fact, I think I need to have a proper session and a play with this.

As long as FS2020 will let me use more than one set of UVs I think it'll work.

So I'd have the diffuse and normals on the first, unbaked set of UVs, so I can use my original textures at their original resolutions. The AO, metal, smoothness map doesn't need the same precision, as it's just altering the general properties of the surface. If a door handle's metallic surface is just 10 pixels on the final texture that doesn't actually matter, as all the detail comes from the diffuse and normal map. So I bake the AO, Metal and Roughness to the second, auto-unwrapped set of UVs, combine the channels into an RGB image and cross my fingers ^_^

I'll give this a go tonight - it all hinges on whether FS2020 recognises more than one set of UVs (maybe I could use the detail maps? Are they a separate set of UVs or just a scaled version of the main textures?)
You can use UDIM's. Which is pretty much multiple UV's (up to 100?) for the same 3d Model.
For example. You want one specific face of your 3d model to be 2048x2048 and the other small parts to be less or higher or whatever. You can achieve that with UDIM's.
 
Thanks, I've had a look, but it's not quite what I need. As far as I can see, they let you use multiple texture files for different parts of the model. I need kind of the opposite - different parts of the model to share the same part of a single texture.

It seems a bit wasteful to have VAST texture maps where every part of the object is represented by a different part of the texture, when a lot of the surface is just identical brick so they could share that texture.

An example. Here's a moderately complex mesh that I've textured with a simple brick texture. It's nice and high resolution on the object without needing a huge texture map, as most of the polys in the object are sharing the same parts of the texture,

1603733059633.png



Now, if I want to bake AO onto this, I'd need to create and unwrap a new set of UVs because the AO UVs can't share the same part of the texture - the AO is specific to each part of the object so every polygon needs its own space on the texture map.

1603733365923.png



If two sets of UVs are supported by the target engine, I can have the diffuse using the smaller, plain brick texture with the first set of UVs, and the AO using the second, non-overlapping set of UVs.

However if only one set are supported, I'm going to have to unwrap my model again so no parts overlap and either bake the diffuse or redraw the whole thing. Either way, it's going to need a HUGE texture to achieve the same detail if the UVs can't overlap.

1603733911638.png
 
Last edited:
You can still apply the tiling brick texture as a detail map as well as the according bump and metallic map.

But why would you want to bake AO into your model whaen MSFS2020 renders AO in real time?
 
You can still apply the tiling brick texture as a detail map as well as the according bump and metallic map.

But why would you want to bake AO into your model whaen MSFS2020 renders AO in real time?

It's only screen-space AO, it's only really any good at tight corners. It wouldn't get the wall behind the staircase for example as the space is too large to trigger it.

I've given up on multiple UVs anyway - I did some proper investigation last night into how the gtlf format works and Asobo have their engine completely ignore the setting which specifies which set of UVs to use. You can export them from Blender, you can see them defined in the gtlf code but the sim will only ever use the first set. Unless they patch it in the future my plan for the AO is not going to work.
 
Last edited:
For anyone interested, this is how the gtlf code looks, with a couple of my own comments:

Code:
    "materials" : [
        {
            "emissiveFactor" : [
                0,
                0,
                0
            ],
            "name" : "Material",
            "pbrMetallicRoughness" : {
                "baseColorTexture" : {
                    "index" : 0, 
                    "texCoord" : 0    // this number defines which TEXCOORD defined in the mesh, to use for the UVs
                },
                "metallicFactor" : 0,
                "roughnessFactor" : 0.5
            }
        }
    ],
    "meshes" : [
        {
            "name" : "Cube",
            "primitives" : [
                {
                    "attributes" : {
                        "POSITION" : 0,
                        "NORMAL" : 1,
                        "TEXCOORD_0" : 2,     // this number defines which buffer to look in to find the first set of UVs
                        "TEXCOORD_1" : 3     // this number defines which buffer to look in to find the second set of UVs
                    },
                    "indices" : 4,
                    "material" : 0
                }
            ]
        }
    ],
    "textures" : [
        {
            "source" : 0
        }
    ],

I made a simple cube with a red and white texture and two sets of UVs. The first set were unwrapped to cover only the red side of the texture and the second set unwrapped to the blue side (so the cube will display all red if it's using the first set and all blue if it's using the second). I exported the gtlf and had a play with changing the definitions and seeing what changed. If you swap the buffer indices in the TEXCOORD_0 and TEXCOORD_1 definitions, the cube turns blue in the sim, showing that both sets of UVs are definitely present in the model. However, changing the "texCoord" index in the baseColorTexture definition has no effect - the engine is hardcoded to only use the TEXCOORD_0 entry regardless of the setting.
 
Last edited:
I've given up on multiple UVs anyway - I did some proper investigation last night into how the gtlf format works and Asobo have their engine completely ignore the setting which specifies which set of UVs to use. You can export them from Blender, you can see them defined in the gtlf code but the sim will only ever use the first set. Unless they patch it in the future it's not going to work.
You don't need multiple UVs for it to work. That's what the detail mapping scale is for. You'll just need to make sure the UVs are all aligned horizontally for the detail bricks to show correctly.
 
You don't need multiple UVs for it to work. That's what the detail mapping scale is for. You'll just need to make sure the UVs are all aligned horizontally for the detail bricks to show correctly.
Yes, but that's only a scaled version of the main UVs. It still means I need to redo the texture on the whole thing. The intention was to just do a smart unwrap to a second set of UVs, hit Bake and it would magically do all my AO without me needing to remap anything.
 
You don't need multiple UVs for it to work. That's what the detail mapping scale is for. You'll just need to make sure the UVs are all aligned horizontally for the detail bricks to show correctly.
Hi , any idea where I can find a small tutorial on how to get this done?
 
Yes i suppose so.
I started a post also when MSFS 2020 was released announcing my project too.
I was hoping may be we could work together on this?
But i wish you all the best also.
 
Yes i suppose so.
I started a post also when MSFS 2020 was released announcing my project too.
I was hoping may be we could work together on this?
But i wish you all the best also.

Well, we could still possibly work together :) It looks like your project is further on than mine.

Are you planning on adding more detail to your buildings? Mine were intended to go into quite a lot of detail with full PBR textures.
 
Unfortunate I am not very good at textures, its learning processes at the moment. My main strength is drawing the models.

Do you live near Barton? I flyout of there often.
 
I have done Barton airfield, if you want the tower blender file you have it.
 

Attachments

  • pumps.png
    pumps.png
    4.4 MB · Views: 248
  • heli.png
    heli.png
    4.2 MB · Views: 253
  • gate.png
    gate.png
    4.5 MB · Views: 279
Back
Top