MSFS20 [Complete] ENSX - Stavanger EMS helicopter

[Nordscape]

And now within the sim:

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.

 

[GaryGB]

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

[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

 

[Nordscape]

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

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

 

[Nordscape]

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.

 

[Nordscape]

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.

 

[GaryGB]

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

 

[Nordscape]

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.

 

[GaryGB]

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 ?


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

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

 

[Nordscape]

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 ?


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

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)

 

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


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.

"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

 

[Nordscape]

Hi again:

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


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.

"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

 

[Nordscape]

I changed the texture size to 1024 and it decreased the file size to 1/3 (!) . Closing in for final release...

 

[Nordscape]

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.

 

[GaryGB]

I'll see what might be causing the inconsistent Altitude rendering when I get the download tonight.

GaryGB

 

[GaryGB]

Hi Vetle:

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


WOW !

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.

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

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

 

[Nordscape]

Hi Vetle:

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


WOW !

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.

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

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.

 

[Nordscape]

ENSX Released in its "current" final state (with a quick hotfix). https://flightsim.to/file/86240/ensx-stavanger-university-hospital-universitetssjukehus