• 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 [Complete] ENSX - Stavanger EMS helicopter

And now within the sim:

Screenshot 2025-01-03 171459 (2).jpg


Screenshot 2025-01-03 172913 (2).jpg



Some terrain adjustments needs to be made, but that "rectangle height map" thing was genious! Holy. So precise and adjust exactly where I want to.
 
Superb 3D modeling, and it looks like you achieved a very good 'fit'; I can hardly wait to see the textured building screenshots. :cool:

[EDITED]

PS: Since there may always be 'some' size mis-match when working with modified aerial imagery from any tile server, one can color match building wall or roof images extending into terrain textures on the ground adjacent to 3D building models 'placed' as part of a multi-object "scene".

If a building replacement was a small 'single' object, one might be tempted to move and/or scale it to cover up a ground texture mis-match that shows part of a building within BING imagery extending out onto the ground at one or more sides of an intended replacement 3D building.

However, 'Scaling' custom replacement 3D buildings of any size as larger multi-object "scenes"- or single objects- may lead to visually objectionable results, so DevMode GUI ground texture Material edits may be a better option for optimizing a local "scene" to match its IRL appearance.

Federico Pinotti (aka "mamu") has a tutorial on YouTube which shows how to create a Grass replacement Polygon via a Material 'close' in color / texture pattern, which can be further edited to match its color to that of underlying default MSFS MSVE (aka "BING") PR imagery:

The segment on that method is at 22:40 elapsed time.


GaryGB
 
Last edited:
Superb 3D modeling, and it looks like you achieved a very good 'fit'; I can hardly wait to see the textured building screenshots. :cool:

[EDITED]

PS: Since there may always be 'some' size mis-match when working with modified aerial imagery from any tile server, one can color match building wall or roof images extending into ground textures on the terrain adjacent to 3D building models 'placed' as part of a multi-object "scene".

If a building replacement was a small 'single' object, one might be tempted to move and/or scale it to cover up a ground texture mis-match that shows part of a building within BING imagery extending out onto the ground at one or more sides of an intended replacement 3D building.

'Scaling' custom replacement 3D buildings of any size as larger multi-object "scenes"- or single objects- may lead to visually objectionable results, so DevMode GUI ground texture Material edits may be a better option for optimizing a local "scene" to match its IRL appearance.



GaryGB
Thanks for the tip! I will look into it when starting on the placement process in not too long. I will first have to make some of the window textures emissive, but it will have to be made through Gimp so that the window sections light up individually without also including the mullions. I believe I saw a video made by Mamu about it🤔

In the mean time, please see the included images of the textured hospital. I have learned a lot about repeating processes and where I may save some time. I've used both the official Norwegian online maps, Bing birds-eye view and google earth to close in on colors and window types. Google earth is also excellent to evaluate the actual size comparison where the height map provided by the www.hoydedata.no is unsuifficient. The textures are mainly non-pbr textures to reduce file size, except for the parking building, shingle roof and west side of patient hotel St. Svithun. I am quite happy with the final result, but it remains to be seen how it looks in the sim...

Screenshot 2025-01-07 210409.png


Screenshot 2025-01-07 210424.png


Screenshot 2025-01-07 210448.png


Screenshot 2025-01-07 210613.png


Screenshot 2025-01-07 210635.png


Screenshot 2025-01-07 211057.png
 
The scenery is coming along nicely. I've decided to put any experiments about environmental effects on hold and try out different suggestions as a test-project before implementing it into the models. I need to finish ENSX first :)

The hospital, parkingbuilding and helipad have now all been adjusted to the terrain using rectangle height map - a great, powerful tool once you learn it! It takes some time adjusting but it is significantly better than the previous method of adjusting the terrain using only polygons with terraform and falloff 🤦‍♂️

Now remains only the -in developer mode- detailing, such as stairs, air vent ducts, trees and different vegetation. I will also add roads.



Screenshot 2025-01-12 131235.jpg
 
Alright! I have recieved some feedback on my released version, saying the file size is quite big (too big) with dependencies also needed. Are textures the main reason for a typically large file size? I have been careful to use only a couple of premade components in sketchup which are not too detailed and large in size, so I would guess I should reduce on textures where I can? The scenery is not that large, so I understand the feedback.
 
Hi Vetle:

Your public package build is about what I would expect for a detailed 'airport' (Helipad), even if it is only 1 building in its distributed form.

The current build size is more likely from the textures, rather than the wire frame geometry complexity and LODs.


There will be some potentially easy to implement adaptations you can utilize to offer the original detail alongside a lower texture resolution version.

Most end users will not even be able to display the full high resolution MIPMAPs of the ENSX Helipad building unless they Slew into very close proximity to the building surfaces.

At normal flight and 'landed-on-Helipad' Altitudes, the MSFS rendering engine LOD switching will force display of down-sampled MIPs rather than the full 4K resolution 'higher-resolution' MIPs.

I will try later tonight, to put together an explanation of how- and why- you may wish to provide a lower-resolution version of your mapped textures that can be swapped for the current distributed higher-resolution set of mapped textures.


Your project is looking exceptionally good thus far, and I am confident it will continue to get even better over time. :)

GaryGB
 
Last edited:
Hi Vetle:

Your public package build is about what I would expect for a detailed 'airport' (Helipad), even if it is only 1 building in its distributed form.

The current build size is more likely from the textures, rather than the wire frame geometry complexity and LODs.


There will be some potentially easy to implement adaptations you can utilize to offer the original detail alongside a lower texture resolution version.

Most end users will not even be able to display the full high resolution MIPMAPs of the ENSX Helipad building unless they Slew into very close proximity to the building surfaces.

At normal flight and 'landed-on-Helipad' Altitudes, the MSFS rendering engine LOD switching will force display of down-sampled MIPs rather than the full 4K resolution 'higher-resolution' MIPs.

I will try later tonight, to put together a better explanation of how- and why- you may wish to provide a lower-resolution version of your mapped textures that can be swapped for the current distributed higher-resolution set of mapped textures.


Your project is looking exceptionally good thus far, and I am confident it will continue to get even better over time. :)

GaryGB
Thank you for your insight :)

I am currently planning on replacing all textures which are absolutely not necessary (for example the lower parts of the building which are a "mossy wall", as an example. Same with the staircase and other details which are not within immediate view from either the roof or ground helipad. I will keep the textures immediately around the helipad, for example the helipad itself, and the ground surrounding it, as well as the fabric gate right in front of the heli as it will recieve lights from the helicopter. A little bit more uncertain about the building wall, but not something I will spend time investigating.

I've used different other projects as comparison and I see that the more texture detail there are, the larger the file is. The question then is - how much of an issue is it. I've not recieved feedback about other issue than the file size itself, so I won't worry too much about it, but still do what I can when I can - e.g. using lower resolution textures where I should/where possible.
 
Hi Vetle:

To initially assess why your ENSX 'released version' "file size is quite big (too big) with dependencies also needed", I see this info:

ENSX - Stavanger University Hospital (Universitetssjukehus) - 315.87 MB

Mikea.at - AssetPack - 302.99 MB

EDHK Lights & Objects Developers Pack (Asset-Pack) - 51.92 MB


Effectively, the declared 'dependencies' more than double your ENSX 'released version' installed size on disk.

IMHO, your own project is less an issue as far as installed size on disk; but certainly there may be room for adaptation of texture size.


Also, if you consider use of 3rd party assets cited above as essential for your ENSX 'released version', lets look at "which" 3D models.

Can you please specify GUID's of 3D model 'library objects' you have "placed" from the above cited 3rd party assets cited above ? :scratchch


PS: I sent you a PM here at FSDEV. ;)

UPDATE: I 'should' be able to ID 3rd party 'dependency' 3D library object GUID's used based on the build cited in your last PM reply.


More to come in a reply tomorrow (...it is quite early in the morning hours of Wednesday here in the USA Central Time Zone).


Since AFAIK it is 'later' morning on Wednesday in Stavanger's Time Zone, as your day permits, you may wish to review this info:

https://www.fsdeveloper.com/forum/t...stom-object-texture-sheets.444761/post-817987


https://community.sketchucation.com/topic/123552/plugin-goldilocks-v2-0#p281153

https://community.sketchucation.com/topic/115351/plugin-goldilocks/21?page=2


https://docs.flightsimulator.com/html/Asset_Creation/Textures/Textures.htm?rhhlterm=quality

https://docs.flightsimulator.com/html/Asset_Creation/3D_Models/LODs.htm?rhhlterm=quality

https://docs.flightsimulator.com/html/Introduction/Release_Notes.htm?rhhlterm=quality

"High quality flag is not set by default anymore for AO/Roughness/Metal (COMP) textures."
:pushpin:



IIUC, new DDS compression formats output by MSFS' SDK are more efficient than just using LZW-compressed PNG texture sources.


AFAIK, Arno's MCX defaults to "better" image quality when processing PNGs and DDS source files for MSFS' SDK package compiler.


Additionally, we must consider MSFS end users' own graphics settings impact on what actually can render- and how it renders:

IIUC, FS2Kx legacy "Visual Display Radius" and "Texture Max Load" in MSFS' is configured via at least (2) GUI Graphics 'Settings':

https://www.avsim.com/forums/topic/621604-3d-buildings-radius/

Objects Level of Detail



Texture Resolution



GaryGB
 
Last edited:
Hi Vetle:

To initially assess why your ENSX 'released version' "file size is quite big (too big) with dependencies also needed", I see this info:

ENSX - Stavanger University Hospital (Universitetssjukehus) - 315.87 MB

Mikea.at - AssetPack - 302.99 MB

EDHK Lights & Objects Developers Pack (Asset-Pack) - 51.92 MB


Effectively, the declared 'dependencies' more than double your ENSX 'released version' installed size on disk.

IMHO, your own project is less an issue as far as installed size on disk; but certainly there may be room for adaptation of texture size.


Also, if you consider use of 3rd party assets cited above as essential for your ENSX 'released version', lets look at "which" 3D models.

Can you please specify GUID's of 3D model 'library objects' you have "placed" from the above cited 3rd party assets cited above ? :scratchch


PS: I sent you a PM here at FSDEV. ;)

UPDATE: I 'should' be able to ID 3rd party 'dependency' 3D library object GUID's used based on the build cited in your last PM reply.


More to come in a reply tomorrow (...it is quite early in the morning hours of Wednesday here in the USA Central Time Zone).


Since AFAIK it is 'later' morning on Wednesday in Stavanger's Time Zone, as your day permits, you may wish to review this info:

https://www.fsdeveloper.com/forum/t...stom-object-texture-sheets.444761/post-817987


https://community.sketchucation.com/topic/123552/plugin-goldilocks-v2-0#p281153

https://community.sketchucation.com/topic/115351/plugin-goldilocks/21?page=2


https://docs.flightsimulator.com/html/Asset_Creation/Textures/Textures.htm?rhhlterm=quality

https://docs.flightsimulator.com/html/Asset_Creation/3D_Models/LODs.htm?rhhlterm=quality

https://docs.flightsimulator.com/html/Introduction/Release_Notes.htm?rhhlterm=quality

"High quality flag is not set by default anymore for AO/Roughness/Metal (COMP) textures."
:pushpin:



IIUC, new DDS compression formats output by MSFS' SDK are more efficient than just using LZW-compressed PNG texture sources.


AFAIK, Arno's MCX defaults to "better" image quality when processing PNGs and DDS source files for MSFS' SDK package compiler.


Additionally, we must consider MSFS end users own graphics settings impact on what actually can render- and how it renders:

IIUC, FS2Kx legacy "Visual Display Radius" and "Texture Max Load" in MSFS' is configured via at least (2) GUI Graphics "Settings:

https://www.avsim.com/forums/topic/621604-3d-buildings-radius/

Objects Level of Detail



Texture Resolution



GaryGB
Thanks Gary! I will review the above links when able.

I am currently only using AC-units, and some other small details from Mikea.at + the lights from EDHK-project. I believe I am able to produce the assets Mikea.at provide myself to an acceptable level, but I will then have to do it in Sketchup, or hope MSFS have a similar item available. I am not using enough of the Mikea.at-provided assets to currently justificy the large file size, so I believe I will keep them out of the current project build (which I am rebuilding from scratch)
 
Thank you for your insight :)

I am currently planning on replacing all textures which are absolutely not necessary (for example the lower parts of the building which are a "mossy wall", as an example. Same with the staircase and other details which are not within immediate view from either the roof or ground helipad. I will keep the textures immediately around the helipad, for example the helipad itself, and the ground surrounding it, as well as the fabric gate right in front of the heli as it will receive lights from the helicopter. A little bit more uncertain about the building wall, but not something I will spend time investigating.

I've used different other projects as comparison and I see that the more texture detail there are, the larger the file is. The question then is - how much of an issue is it. I've not received feedback about other issue than the file size itself, so I won't worry too much about it, but still do what I can when I can - e.g. using lower resolution textures where I should/where possible.

Hi again:

IMHO, your observations regarding texture detail (aka "resolution" in Meters / Pixel) versus package size are correct. :pushpin:


Math for the East wall of ENSX Helipad building: (wall width in Meters / texture width in mapped Pixels)

22.4120 Meters / 4096 pixels=0.0054716796875 Meters / Pixel


That correlates with a mapped run time texture resolution of 5.4716796875 Millimeters / Pixel at LOD-23 / QMID-25

https://www.fsdeveloper.com/forum/threads/flattens.425495/post-633002


An Inverse Square Law applies to FS Quad Mesh, so each LOD numeric unit decreases distance between Pixels by a factor of (2).

Thus a texture at LOD-23 is 8x higher resolution than 3.5 cm / Pixel LOD-20 cited in a example by rhumbaflappy linked above.

https://www.fsdeveloper.com/forum/t...stom-object-texture-sheets.444761/post-817987


Since textured 3D scenery object size and distance from user aircraft camera impacts LOD / MIPMAP switching and visibility, IIUC, one may swap texture images to those resized via MCX' Texture Converter to ex: 1024x1024 for reduced Pixel resolution. :idea:

"8.3 Texture converter

With the texture convert tool you can view and edit texture files, see Figure 8.3.

In the toolbar the following options are available:

• With the Load file button you can load a texture file from disk.
See section 9.2 for more information on the supported formats.

• With the Save file button you can save the texture file to disk again. With the dropdown
list next to the button you can select the format that it should be saved in. See section 10.3
for more details about the supported formats.

• With the Set transparent color button you can choose which color in the texture should
become transparent. The alpha channel will then be generated based on this.

• With the Convert normalmap to FS button you can convert a normalmap to the FSX
specifications. You load a texture made by a normalmap plugin and then save it to DDS
after pressing this button.

• With the Resize button you can resize the texture to the specified size.

• Using the channel buttons you can select if you want to see all channels, or only the red (R),
green (G), blue (B) or alpha (A) channel.

• With the mip level dropdown menu you can select which mip map of the image is rendered in the window"


I am evaluating graphics applications / utilities that can extract / edit / restore MIPMAPs from textures output by MSFS SDK.

I hope later today (Thursday) to have a demonstration for Texel resolution versus run time LOD / MIPMAP switching in MSFS.

UPDATE:

Multiple real life commitments keep popping up, and complicate the new problem of finding graphics utilities that process MSFS DDS files.

glTF as implemented by Asobo uses (2) new compression methods, and graphics utilities are lagging behind in support.

This latter demo might take a while.

GaryGB
 
Last edited:
Hi again:

IMHO, your observations regarding texture detail (aka "resolution" in Meters / Pixel) versus package size are correct. :pushpin:


Math for the East wall of ENSX Helipad building: (wall width in Meters / texture width in mapped Pixels)

22.4120 Meters / 4096 pixels=0.0054716796875 Meters / Pixel


That correlates with a mapped run time texture resolution of 5.4716796875 Millimeters / Pixel at LOD-23 / QMID-25

https://www.fsdeveloper.com/forum/threads/flattens.425495/post-633002


An Inverse Square Law applies to FS Quad Mesh, so each LOD numeric unit decreases distance between Pixels by a factor of (2).

Thus a texture at LOD-23 is 8x higher resolution than 3.5 cm / Pixel LOD-20 cited in a example by rhumbaflappy linked above.

https://www.fsdeveloper.com/forum/t...stom-object-texture-sheets.444761/post-817987


Since textured 3D scenery object size and distance from user aircraft camera impacts LOD / MIPMAP switching and visibility, IIUC, one may swap texture images to those resized via MCX' Texture Converter to ex: 1024x1024 for reduced Pixel resolution. :idea:

"8.3 Texture converter

With the texture convert tool you can view and edit texture files, see Figure 8.3.

In the toolbar the following options are available:

• With the Load file button you can load a texture file from disk.
See section 9.2 for more information on the supported formats.

• With the Save file button you can save the texture file to disk again. With the dropdown
list next to the button you can select the format that it should be saved in. See section 10.3
for more details about the supported formats.

• With the Set transparent color button you can choose which color in the texture should
become transparent. The alpha channel will then be generated based on this.

• With the Convert normalmap to FS button you can convert a normalmap to the FSX
specifications. You load a texture made by a normalmap plugin and then save it to DDS
after pressing this button.

• With the Resize button you can resize the texture to the specified size.

• Using the channel buttons you can select if you want to see all channels, or only the red (R),
green (G), blue (B) or alpha (A) channel.

• With the mip level dropdown menu you can select which mip map of the image is rendered in the window"


I am evaluating graphics applications / utilities that can extract / edit / restore MIPMAPs from textures output by MSFS SDK.

I hope later today (Thursday) to have a demonstration for Texel resolution versus run time LOD / MIPMAP switching in MSFS.

GaryGB
Thanks for you input Gary. Currently the unwrapped scenery within the community folder is about 800mb, which is too high, I believe. I don't mind, personally, but others may. The zipped file is about 400mb.

I will resize the textures to 1024 as you mentioned. I do not need any higher size than that - I think... . Will report back when tested
 
The project has now been completed after some quite intense work this weekend. Most of it has been frustration regarding object placement, which shows differently in the developer mode and when in the community folder. I believe "best practice" is to set buildings which are supposed to get objects placed "on" them to the aboveAGL=false setting. One of the main issues have been that the building itself - due to significant terraforming - is moving up and down in such a way that it disrupts the object placements.

Anyway; there seem to be some sort of issue with uploading to flightsim.to, so I am unable to release at the moment. Will try again tomorrow.

Gary; I am uploading the project to dropbox very soon. Ill send you the link.
 
I'll see what might be causing the inconsistent Altitude rendering when I get the download tonight.

GaryGB
 
Hi Vetle:

I downloaded and launched the updated ENSX, but see no Altitude anomalies thus far.


WOW ! :yikes:

Your scenery of the Helipad with adjacent Hospital campus and the West parking deck looks extraordinary. 😃

The Hospital campus looks exceptionally good day and night, with night windows more realistic than MSFS' default buildings.

I also really got a kick out of the lighting and cars in the highly detailed West parking deck, especially on the lower level.


I may have to try using a MSFS vehicle to drive around in the parking deck, and go sightseeing on the Hospital campus. :cool:

But uh-oh... then we might have to put in Hillevåg Tunnel and others in the local tunnel network ...beneath "fake terrain".:rotfl:

Google Earth Desktop Edition users may wish to un-zip the attached *.KMZ file.

Then in Windows Explorer, double-click it, and "follow the yellow brick road" (...to 'Oz-gard' ?) . ;)


Very well done.


GaryGB
 

Attachments

Last edited:
Hi Vetle:

I downloaded and launched the updated ENSX, but see no Altitude anomalies thus far.


WOW ! :yikes:

Your scenery of the Helipad with adjacent Hospital campus and the West parking deck looks extraordinary. 😃

The Hospital campus looks exceptionally good day and night, with night windows more realistic than MSFS' default buildings.

I also really got a kick out of the lighting and cars in the highly detailed West parking deck, especially on the lower level.


I may have to try using a MSFS vehicle to drive around in the parking deck, and go sightseeing on the Hospital campus. :cool:

But uh-oh... then we might have to put in Hillevåg Tunnel and others in the local tunnel network ...beneath "fake terrain".:rotfl:

Google Earth Desktop Edition users may wish to un-zip the attached *.KMZ file.

Then in Windows Explorer, double-click it, and "follow the yellow brick road" (...to 'Oz-gard' ?) . ;)


Very well done.


GaryGB
Thanks Gary! :) Really appreciate it, but a lot of credit for this goes directly to your involvement in helping me out! I would not have had the motivation without your feedback. Thank you so much!

The altitude anomaly was in a previous version. I "fixed" it by adding the aboveAGL=false value to the ENSX building which stopped the building from bumping up and down. However, doing this also moves the Gizmo tools in a position which basically makes it unmanageable. The camera needs to be pointed at the ground to see the placement, but the gizmo-tool is way high up, so you need to find a spot where both the tool and the object can be seen - which was quite difficult, and not at all practical when dealing with multiple objects...

I was thinking about adding the Hillevåg Tunnel, so that might come later. :) If you consider "driving" around the hospital campus, let me know if you meet any issues with collision objects. I think I might have messed something up by making some materials unpenetrable. Not a big issue, but I encounter them when moving the drone around.
 
Back
Top