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

Blender Normal map lighting issues

I'm new to Blender and am running into an issue where the natural lighting is either on or off, and looks unnatural. This only occurs when I try to use normal maps, which look great in direct sunlight, but too dark with indirect. There is no transition. See attached images for reference. The textures used on the various hangars are the same texture files and same settings in Blender. I have verified that all normals are facing the correct direction. As you can see the brightness is very different depending on the light angle.
Using Nodes I have the normal map > normal map node > normal plug of Principled BSDF > Material Output

unknown.png

blendertroubles.png
 
EDIT --- It looks like you may need to {reload} or {recompile and reload} your project and that the different buildings are in a different point in time with the textures.

You can disable the building shadows in FS 2020 in the properties of the building / object you are placing. The larger buildings might be laying a shadow over the small buildings. If you want less "reaction" to light, you can also try addding more roughness (less reflection) and possibly an emmission color maybe to interact with the lighting less. It is also possible to add custom lighting from Blender. Also make sure you are inverting your normal, or try just a plain flat normal that is just purple with no contrast. Test it without the normal as well and just do some troubleshooting.

Lighting is a pain in FS 2020, although the environmental lighting in the game is amazing, it's a bit exaggerated for certain times of day.
It happens to the default buildings in the game too, try changing the time of day and watch the buildings change color.

For instance going from Noon to 3pm can totally change the color of a building, even during a clear sky, that is not really realistic.
Now in reality, that could happen if say the angle of the sun is a certain way and is bouncing off water or another building, but in general it wouldn't change the color that much.
 
Last edited:
Thanks for the tips SceneryFX. I tried turning shadows off, changing the time of day, and reloading the project with the same results. If I delete the normal map, the building lights correctly, but the textures look like they're printed on cardstock. It's not the worst option, just not as realistic as I'd like. A grey emmission color helped to reduce the obviousness of the shine, but it's still too metallic (metallic settings are off AFAIK). A pure purple normal map shows the same error, but clearly defined. What I mean is that there is no texture depth, but it does shine brightly/reflectivly, almost as smooth as a mirror but without the seeing any image in the mirror. This occurs through about 270* of rotation when circling the object in dev cam.

Could you expand more on "inverting the normal"? To clarify, should the normals in blender be facing inwards?

Thanks for helping!
 
When talking about inverting the normal, I was speaking of the actual image normal (normal map), rather than the Blender Normals.
You have to go into Photoshop, Gimp, or use a program called Materialize; then invert only the green channel of the normal...

Another thing to try (separate from above) is select all your faces in Blender, and in Edit mode, choose Mesh > Recalculate Normals from Outside.
That may help.
 
Bingo! Inverting the green channel seems to have worked. I need to tweak the blender values a little bit to correct the harshness of the normals, but the blinding shine and dark shadows are gone. I downloaded the textures from a website, didn't think I would need to make any edits to get them working properly.

Thank you so much SceneryFX, I've spent the last week going insane over these hangars.
 
Bingo! Inverting the green channel seems to have worked. I need to tweak the blender values a little bit to correct the harshness of the normals, but the blinding shine and dark shadows are gone. I downloaded the textures from a website, didn't think I would need to make any edits to get them working properly.

Thank you so much SceneryFX, I've spent the last week going insane over these hangars.
To touch a little further on this, the reason this exists is due to OpenGL versus DirectX methods for rendering normals. MSFS is using the DirectX method.

From Google: "In terms of normal maps, the difference result in how the green channel of a RGB texture should be interpreted. OpenGL expects the first pixel to be at the bottom while DirectX expects it to be at the top. ... OpenGL can be referred as Y+ (bottom-up) while DirectX is referred as Y- (top-down)."
 
Hi, Im having the same issue it seems. How do I invert the green channel? I watched youtube vids but my texture is just one layer when I open in PS. Im using Substance Painter to export my textures and I get normalmap in PNG format.. Thanks
 
Last edited:
Hi, Im having the same issue it seems. How do I invert the green channel? I watched youtube vids but my texture is just one layer when I open in PS. Im using Substance Painter to export my textures and I get normalmap in PNG format.. Thanks
The fs2020 Substance Painter export template is what you're looking for. SP will export the Normal in DirectX method, it's in the export options. Select the preset in the dropdown during texture export.
https://www.fsdeveloper.com/forum/resources/substance-painter-export-presets-for-msfs-2020.257/
substancePainter_MS2020export_01.JPG substancePainter_MS2020export_02.JPG
 
Last edited:
Are you starting your SP project as DirectX or OpenGL normals? I was starting mine as DirectX and when using the FS2020 excporter my normals were getting flipped to OpenGL ;). Edit your project configuration back to OpenGL if it's DirectX and try exporting textures again.
 
Yes there is DirectX when I start a project so I assume all my projects were started using this settings. But when going to Project Configuration to change it there is OpenGL. Ill keep investigating.
EDIT: I did the most straight forward thing. Recreated the textures in SP, started as OpenGL and it seems to fix the issue. Thank you
 
Last edited:
Just FYI I think it's not that simple. I had this problem a lot, and I found out that the offending faces were too shiny or too dark, even next to similar faces right next to it on the same wall. So same lighitng, same angle - drastically different look. Turned out if I rotat UV map for that sureface 180 degrees, it goes away and becomse the same as others. So ti does have something to do with UV map orientation, at least in my case. After "Smart UV project" there are faces inevery kind of orientation, and it doesn't suppose to matter, but somehow it does.
 
That is right, you must rotate the UV map to match the proper orientation, unless a seamless texture is a perfect mirror or perfectly symmetrical, which most are not. I do this out of habit now and forget to tell people that, just rotate 180 in the UV side of the window.

Also, seems there is something going on with the normals as I had posted prior in Roman's thread. Some are not being converted to DDS the same as others are by the compiler. I'll experiment myself and once I know a lot more, I'll post back in the other thread with my findings, just haven't a had a chance yet.
 
Last edited:
That is correct, you must rotate the UV map to match the proper orientation, unless a seamless texture is a perfect mirror or perfectly symmetrical, which most are not. I do this out of habit now and forget to tell people that, just rotate z 180 in the UV side of the window.
Would that have the same effect as scaling the UV map by - 1? I had a similar problem where one side of a gabled roof was being lit totally differently from the other one. I saw that both roof sides were separated UV islands and although they looked identical in size scaling the wrong lit one by - 1 seemed to improve the way it reacted to light. But I still think the lighting in MSFS has some odd abrupt changes during the day cycle which though it looks great seems exaggerated sometimes.
 
i don't know which scaling method you used, but rotating the UV map is different usually and changes the physical orientation of the texture.
Rotating the UV map by 180 is the same as flipping the image in Photoshop, well in a sense, not exactly the same depending on your UV mapping area.
 
Last edited:

Pyscen

Resource contributor
The difference between OpenGL and DirectX is the V in the UV, meaning the Y. So flipping the Y should solve it.
 
Having the texture orientation incorrect can sometimes look similar to having the normal incorrect. Beyond that, the compiler fails to convert the normals properly sometimes but will still pass the object and let you use it, and you'd never know unless you open the DDS file.

In total, I'm aware of many different issues as per the cause of off-lighting just going by memory, but there are probably about 15 different causes total:

1) Normal needs inverting
2) An improperly rotated texture will cause a tint mismatch to adjacent texturing
3) Metallic or other texture or setting is darkening your object and causing a higher reflectivity change in game lighting
4) The comp / PBR texture is not embedded into the RGB correctly
5) The normal is not agreeing with the comp texture, hence you need to redo the normal
6) The normal has too high frequency rolloff points, redesign it or smooth it off
7) Lighting setup is too sensitive in this game (go to June - Aug) and set it to 10am - 2pm
8) Shadows problem from an object behind a wall
9) Two unconnected meshes are too close together and the game lighting is getting confused
10) draw order maybe?
11) The compiler did not properly convert the normal DDS file.

There are more I'm sure... Lighting in this game can be a pain sometimes.
 
Having the texture orientation incorrect can sometimes look similar to having the normal incorrect. Beyond that, the compiler fails to convert the normals properly sometimes but will still pass the object and let you use it, and you'd never know unless you open the DDS file.

In total, I'm aware of many different issues as per the cause of off-lighting just going by memory, but there are probably about 15 different causes total:

1) Normal needs inverting
2) An improperly rotated texture will cause a tint mismatch to adjacent texturing
3) Metallic or other texture or setting is darkening your object and causing a higher reflectivity change in game lighting
4) The comp / PBR texture is not embedded into the RGB correctly
5) The normal is not agreeing with the comp texture, hence you need to redo the normal
6) The normal has too high frequency rolloff points, redesign it or smooth it off
7) Lighting setup is too sensitive in this game (go to June - Aug) and set it to 10am - 2pm
8) Shadows problem from an object behind a wall
9) Two unconnected meshes are too close together and the game lighting is getting confused
10) draw order maybe?
11) The compiler did not properly convert the normal DDS file.

There are more I'm sure... Lighting in this game can be a pain sometimes.
I make it a habit now to enable normals visually to double check. I was duplicating walls and moving to opposite side and rotating 180 but the normals didn’t for some reason, with double sided off it was invisible from the wrong side
 
OK I'm seriously confused now. First, some people here seem to mix up flipping or rotating the normals of the Mesh faces in Blender with flipping or rotating the normal map of the texture. Second, some people claim that you need to invert the y axis of the normal map while others talk about inverting the uv map. This would have totally different effects. If I flip, rotate or however manipulate the Uv map this will change how my whole texture is applied, it will be upside down, sideways, whatever. If I just flip the normal map in Photoshop or gimp only the normal map will be different while the albedo and metallic texture will keep their orientation. I remember that in prepar3d you also had to flip the y axis of your whole texture (which had the same effect as flipping the uv map would have in Blender) before exporting. Model Converter X even had an option for this in the material editor. Additionally, flipping the y axis and rotating it by 180 degrees is NOT the same, this seems to get mixed up too. Someone said to rotate the UV 180 degrees in the Z axis, but does a 2 dimensional image even have a z axis??? I just wonder why the exporter tool does not automatically take care of this. If direct x interprets the y orientation differently, why not automatically flip the y axis when converting from png to dds?
 
Last edited:
Top