MSFS20 3rd party photogrammetry excluding night lights

[GaryGB]

Yesterday I did a Google search on FSDEV and found a few threads discussing the quirks of Orbs, Light Supports and their display distance.

IIRC, there were possible work-arounds identified for some of the 'gotchas'.

I'll post some links to that info soon, after I get back to my other computer where I saved the FireFox 'session' of Windows / Tabs / URLs.

GaryGB

 

[Nordscape]

Yesterday I did a Google search on FSDEV and found a few threads discussing the quirks of Orbs, Light Supports and their display distance.

IIRC, there were possible work-arounds identified for of the 'gotchas'.

I'll post some links to that info soon, after I get back to my other computer where I saved the FireFox 'session' of Windows / Tabs / URLs.

GaryGB

Probably this one? https://www.fsdeveloper.com/forum/threads/msfs-scenery-lights.455868/

 

[GaryGB]

That URL may be "the best of the bunch"; IIRC, I did not pick that one up in my query yesterday, as I had omitted "orb" as a query string.

I'll post the other links a little later; the thread you found above merits primary study and testing compared to those I found yesterday.

GaryGB

 

[GaryGB]

BTW: We owe a debt of gratitude to Dick for his work with many aspects of FS; most notably with "Lights".

He was the first to ID how to make and place "Light Balls" in early FSX, and posted example objects we could utilize in 3rd party scenery.


Dean Mountford subsequently made some specialized color versions for his projects at the time, and released them for us all to use, too.


These are the kinds of generous efforts that keep this community thriving over multiple versions of FS over many years of "evolving" code.

Many thanks to all here, who share their insights and fruits of their labors for others to learn from.

GaryGB

 

[Nordscape]

BTW: We owe a debt of gratitude to Dick for his work with many aspects of FS; most notably with "Lights".

He was the first to ID how to make and place "Light Balls" in early FSX, and posted example objects we could utilize in 3rd party scenery.


Dean Mountford subsequently made some specialized color versions for his projects at the time, and released them for us all to use, too.


These are the kinds of generous efforts that keep this community thriving over multiple versions of FS over many years of "evolving" code.

Many thanks to all here, who share their insights and fruits of their labors for others to learn from.

GaryGB

Totally agree. I am quite impressed by the community and dedication here, but one special gratitude goes directly to you Gary! Thanks for all your feedback and inputs, which is outstanding...

I am starting to understand that it is not possible to add the autogen lights back into the scenery with the photogrammetry addon. If they were able to be put back in, it would be occluded by the photogrammetry mesh anyway. I will therefore start to focus on adding lights a different way. I've tried with lightrows+lightsupport which adds the lightbulb when using the orb as a mesh. But the glow disappears after a relatively short distance.

What I can do, is to manually place glowing light objects around the lightrows+lightsupport, and in/around city locations. Unless anyone have an idea to automatically place these objects. Chatgpt suggested importing a OSM-file which defines roads, and then import those coordinates into an .xml file which can be read by the scenery - but now we are talking things I definitely do not know how to do

 

[GaryGB]

Totally agree. I am quite impressed by the community and dedication here, but one special gratitude goes directly to you Gary! Thanks for all your feedback and inputs, which is outstanding...

Thanks for the kind words; I am glad to be of some help.

I am starting to understand that it is not possible to add the autogen lights back into the scenery with the photogrammetry addon. If they were able to be put back in, it would be occluded by the photogrammetry mesh anyway. I will therefore start to focus on adding lights a different way. I've tried with lightrows+lightsupport which adds the lightbulb when using the orb as a mesh. But the glow disappears after a relatively short distance.

What I can do, is to manually place glowing light objects around the lightrows+lightsupport, and in/around city locations. Unless anyone has an idea to automatically place these objects. Chatgpt suggested importing a OSM-file which defines roads, and then import those coordinates into an .xml file which can be read by the scenery - but now we are talking things I definitely do not know how to do

I would advocate more study of XML de-compilations from Vizipok's implementation of the GEDOT methods (it has a few different options), as I believe it may help save some work, and time spent 'climbing the learning curve'.

In the event we discern how the GEDOT methods work, we may be able to derive a version of placement that can be a "Replacement" BGL.

Even if Norse / OSM data sets are available to use for a replacement of default light placement, we may still incur 'occlusion' due to GEDOT.

That raises the question as to how / why Gedot Exclusion code is able to clobber default lights, as they "should" be separate from TINs.


I have a 'hunch' that default "Orbs" are placed as vectors, and are treated as a photogrammetry component along with TINs.

We should be able separately place light "Orbs", and also exclude them separately, but I am not yet certain where / how MSFS default does it.

But, we may also find the OSM light placement replacement strategy is an easier way to separate them from TIN Photogrammetry vectors GEDOT may 'clobber'.

Implementing OSM data is not that complex, and may only require some attribute edits to swap lights for other objects already placed.

GaryGB

 

[GaryGB]

While it is an option to manually Replace lights as ModeLib scenery library objects since MSFS default light placement is more sparse than is likely in real life, one would still need to resolve the visibility distance issues if used instead of light "orbs".

But, as much as Asobo dislikes the idea, we may need to use the big non-textured Face trick to ensure distance visibility of light models.

It would also mean more work.


Assuming one resolved the distance visibility issues, the quality of GIS vector data I have seen for Norway is among the highest of countries with web portals, so one could utilize 'cadastral'-type data sets to yield results for features such as lights that are more detailed and accurate than MSFS default scenery.


But that is peripheral to the primary focus on making scenery in the immediate vicinity of ENKH, and may involve some learning to work with vectors and importing them into MSFS SDK DevMode Scenery Editor.

SBuilderX has the ability to work with ESRI SHP files that can be imported to MSFS DevMode Scenery Editor as 'primitive' vectors.

One can simply assign updated and fully MSFS SDK compliant attributes to the vector primitives after they have been imported.


I make the case again for further exploration of how the MSFS default lights are placed, extracting the data, and using it to Replace the lights separate from other vector objects such as TIN Photogrammetry.

This could be done with a goal to work around exclusion of default lights by the Vizipok G-Polys.


Alternatively, edited copies of the Vizipok G-Poly "Objects" placement BGLs could be made after review of assigned exclusion attributes in the de-compiled XML code, which may prevent clobbering of MSFS default lights.

In that scenario, the extracted data set would otherwise not be different than the MSFS default, but placed separately from other vectors.


PS: Have you considered disabling Vizipok Kristiansand-1 G-Poly add-on at Night only, to allow MSFS default to show (with lights) ?

Even if you place miscellaneous street lights around the city, you would still be missing lights on buildings, including illuminated windows.

AFAIK, this may be the method others use, and they only replace few major landmarks around cities to be seen at night by local explorers.


Tomorrow (Monday) I planned to take a look at the details of the (above) de-compiled XML to see what may be done to save some work.

https://www.fsdeveloper.com/forum/t...try-excluding-night-lights.459941/post-933352


Thus far it seems default street lights / other vector data / TINS may be placed via CGL files that we may not yet be able to de-compile ?

GaryGB

 

[Nordscape]

While it is an option to manually Replace lights as ModeLib scenery library objects since MSFS default light placement is more sparse than is likely in real life, one would still need to resolve the visibility distance issues if used instead of light "orbs".

But, as much as Asobo dislikes the idea, we may need to use the big non-textured Face trick to ensure distance visibility of light models.

It would also mean more work.

Indeed. I'll try to avoid this approach as long as I can...

Assuming one resolved the distance visibility issues, the quality of GIS vector data I have seen for Norway is among the highest of countries with web portals, so one could utilize 'cadastral'-type data sets to yield results for features such as lights that are more detailed and accurate than MSFS default scenery.

Well, ChatGPT suggested, and "offered" to make the .xml file needed to place the coordinates for the lights around the city, using OSM-data. I may give that a serious try actually...

I make the case again for further exploration of how the MSFS default lights are placed, extracting the data, and using it to Replace the lights separate from other vector objects such as TIN Photogrammetry.

This could be done with a goal to work around exclusion of default lights by the Vizipok G-Polys.

I would certainly like to explore this solution, absolutely...

PS: Have you considered disabling Vizipok Kristiansand-1 G-Poly add-on at Night only, to allow MSFS default to show (with lights) ?

Even if you place miscellaneous street lights around the city, you would still be missing lights on buildings, including illuminated windows.

AFAIK, this may be the method others use, and they only replace few major landmarks around cities to be seen at night by local explorers.

That is true, but no. I did not consider that mostly because it would involve coding - I assume -, and because I don't want the scenery to have any sort of pop-in/pop-out effect during the transition between night/day/night. But that is indeed a creative approach to the issue which deserves some thought! I will consider it if all else fails.

 

[Nordscape]

Alright, some more troubleshooting - mostly for my own clarification(?).

It seems that an exclusionrectangle with "excludeall" setting does not exclude any default generated props - such as default buildings, lights and so on.

A polygon with "excludebuildings" does not remove the street lights either - unless specifically told to through "exclude streetlights".

Adding the "Exclude street lights" function removed the streetlights - as expected.

I saved the project and put into the community folder.

I then created a new project with the intent to override the settings from the mentioned test-project above.

1: I made an exclusion rectangle with the exclude polygon/rectangle box ticked. It was large enough to cover the relevant polygon and then some.
2: I created a new polygon within the exclusionrectangle, but without any boxes ticked - thinking maybe that polygon would override the settings from the polygon excluding the streetlights.

None of those options had any effect on the project excluding the lights and buildings.

 

[GaryGB]

IIUC, Vizipok G-Polys were not loaded for the tests, to see how Exclude Rectangles / Polygons behave if attempting to "Restore" 'autogen' ?

and IIUC, the result was, after an initial exclude clobbers certain scenery content ('autogen'). it was not "Restored" by re-enabling it ?


Just to clarify, did you utilize the procedures intended to configure Polygons / Rectangles to re-enable autogen cited here: ?

https://www.fsdeveloper.com/forum/t...try-excluding-night-lights.459941/post-933354

GaryGB

 

[Nordscape]

IIUC, Vizipok G-Polys were not loaded for the tests, to see how Exclude Rectangles / Polygons behave if attempting to "Restore" 'autogen' ?

and IIUC, the result was, after an initial exclude clobbers certain scenery content ('autogen'). it was not "Restored" by re-enabling it ?


Just to clarify, did you utilize the procedures intended to configure Polygons / Rectangles to re-enable autogen cited here: ?

https://www.fsdeveloper.com/forum/t...try-excluding-night-lights.459941/post-933354

GaryGB

The Kristiansand G-poly was loaded, but the test area was outside of the G-poly area, covering the rest of the hospital not inside the photogrammetry area.

In short; what I tried was to test outside of the photogrammetry area what has to happen for the street lights to disappear. As far as I can see the street lights have to be excluded through a polygon, and it is a specific setting within its properties which needs to be assigned.

I then made a new project with an exclusion rectangle and polygon without any specific settings which was intended to bring back the street lights, hopefully overriding the previous setup by giving it a high priority number, but it didn't do anything.

 

[rhumbaflappy]

First of all, these are not photogrammetry, at least not in the sense of MSFS. These are library objects ripped from Google. The ripped models are in the modellib and the objects.bgl are the placement of those objects, along with some polygons.
The kristiansand-1 addon you are trying to override includes polygons that exclude osm, vegetation, etc... and they also flatten the elevation to 4.0 meters.

You need to make an exclusion rectangle that excludes polygons. You may need to make new flatten polys at 4.0 meters to re-flatten the terrain. The package that contains the new exclusion rectangle should be named something like "zzz-mywonderfulscenery"... starting as zzz so it is loaded after the kristiansand-1 package. You can make a package, and then rename it after the compiling, and placing it in Community if you want.

 

[Nordscape]

First of all, these are not photogrammetry, at least not in the sense of MSFS. These are library objects ripped from Google. The ripped models are in the modellib and the objects.bgl are the placement of those objects, along with some polygons.
The kristiansand-1 addon you are trying to override includes polygons that exclude osm, vegetation, etc... and they also flatten the elevation to 4.0 meters.

You need to make an exclusion rectangle that excludes polygons. You may need to make new flatten polys at 4.0 meters to re-flatten the terrain. The package that contains the new exclusion rectangle should be named something like "zzz-mywonderfulscenery"... starting as zzz so it is loaded after the kristiansand-1 package. You can make a package, and then rename it after the compiling, and placing it in Community if you want.

View attachment 96525

View attachment 96526

Thank you so much for the clarification and your input. I was unaware of the "zzz-" designation to load it last. I will certainly try out your suggestion!

 

[GaryGB]

(Vizipok's) Kristiansand-1 G-polys were loaded, but the test area was outside of the G-poly area, covering the rest of the hospital not inside the photogrammetry area.

In short; what I tried was to test outside of the photogrammetry area what has to happen for the street lights to disappear. As far as I can see the street lights have to be excluded through a polygon, and it is a specific setting within its properties which needs to be assigned.

I then made a new project with an exclusion rectangle and polygon without any specific settings which was intended to bring back the street lights, hopefully overriding the previous setup by giving it a high priority number, but it didn't do anything.

Thanks for that clarification, Vetle; that is a useful test to run, as it takes place outside the extent of the Vizipok G-Polys.

This has the potential to see if the MSFS SDK Exclude process is working OK locally, or if other variables may be interfering with that.


IIUC, the initial goal is to confirm that the MSFS SDK Exclude process is working OK locally, and to better define 'how' it works.

Then the next goal IIUC, is to proceed further in "Restoring" local scenery content (if possible) that got clobbered by the Vizipok G-Polys.


I quote again, my citation of SDK Docs sections on easily overlooked extra attribute check boxes for "Restoring" content as further tests:

https://www.fsdeveloper.com/forum/threads/enkh-kristiansand-hospital.459612/post-933184

Hi Vetle:

Remembering the basic principle and Caveat we should always abide by in FS scenery development: Exclude ...then Replace:

* A ExclusionRectangle is configured to Exclude the specified 3rd party G-Poly tile 3D meta-object

* A Polygon is configured to Replace / add specified objects back to the area where we excluded the 3rd party G-Poly tile 3D meta-object


To verify whether you are replacing in the area of the unwanted 3rd party G-Poly tile 3D meta-object with Scenery objects you have placed:

In addition to a ExclusionRectangle object you placed, have you also placed a Polygon with multiple feature 'Attribute' options checked ?


Note: in this linked SDK Doc:

https://docs.flightsimulator.com/html/Content_Configuration/Environment/Scenery_Objects/Scenery_Object_Definitions.htm?rhhlterm=exclusion rectangle&rhsearch=exclusion rectangle


...that the <Attribute> section contains a link to the Polygons introduction page:

https://docs.flightsimulator.com/html/Developer_Mode/Scenery_Editor/Objects/Polygon_Objects.htm

...and on that Polygons page in the Properties section, it lists "the following Properties which can be edited".


IIRC, we must impose these Attributes on a Polygon placed in a layer above the area of the G-Poly excluded by your ExclusionRectangle:

(NOTE: By layer above a layer, I mean a layer which loads later... after a preceding layer to be excluded / otherwise processed has loaded).

This can also be enforced via "alpha-numeric" naming of files; adding a z-, zz-, or zzz- prefix to the file name tells FS to "load it later".

* Force Detected Buildings

This option can be used to force the rendering of detected buildings for an area.

(MSFS default automatically generated)


* Force Buildings On Tin

This can be used when you have excluded TIN data, but want to still have TIN generated buildings present.

(MSFS default Photogrammetry)


AFAIK, you can add this Polygon to your Project so it loads from the same Asset Group as the one containing your ExclusionRectangle.


Your ExclusionRectangle successfully excludes the G-Poly, when it loads "after" the G-Poly; try putting your Polygon into that same layer.

GaryGB

 

[GaryGB]

(Dick: ) Thank you so much for the clarification and your input. I was unaware of the "zzz-" designation to load it last. I will certainly try out your suggestion!

Hi again:

Many thanks to Dick for his input on this testing and configuration process, to work around the impact of unique custom 3D G-Polys.


Indeed, as Dick points out, we can enforce load sequencing of files based on use of "alpha-numeric" file naming (this works in FS2Kx too).


I am not certain if / how it works independently from a internal "Priority" numbering attribute MSFS SDK Docs mentions in this web page:

https://docs.flightsimulator.com/html/Developer_Mode/Scenery_Editor/Objects/Rectangle_Objects.htm

"Priority

This option sets the render priority for the rectangle. The default render priority is 0, which for most cases is fine.

However, if you have overlapping rectangles and want one to render over another one, then you will need to change this value clicking the + or - buttons to raise or lower the priority value.

Higher priority values will render over lower priorities; for example, a rectangle with priority 1 will render over one with priority 0, which in turn will render over one with priority -1.

Note that we cannot guarantee the render order for rectangles with the same priority, so if you need something to render over or under something else, you need to set this value.

Note that if the rectangle is flagged as terraforming then the priority value will be rendered in the world view to make debugging easier."


My 'hunch' is that "alpha-numeric" file naming works 'better' than the internal "Priority" numbering attribute MSFS SDK recommends.


I hope the "Restore" features quoted again immediately above, may work to save manually placing night lights to work around G-Polys.


Although as Dick observes, we are not knowingly dealing with MSFS default photogrammetry content by unique object type, it seems that the exclude process may clobber vector light placements, possibly because the night light category of vector objects is grouped together with TINs and other vector content for purposes of a exclusion process, ultimately ending up as a target of the vector exclude.

Nice of Asobo to offer the above "Restore" features for buildings otherwise excluded in a vector category; but we want lights back also.

Not wishing to cast doubts on the testing process, but I still wonder if a dastardly "Hidden Hex-clude" is imposed by GEDOT G-Polys.

GaryGB

 

[Nordscape]

First of all, these are not photogrammetry, at least not in the sense of MSFS. These are library objects ripped from Google. The ripped models are in the modellib and the objects.bgl are the placement of those objects, along with some polygons.
The kristiansand-1 addon you are trying to override includes polygons that exclude osm, vegetation, etc... and they also flatten the elevation to 4.0 meters.

You need to make an exclusion rectangle that excludes polygons. You may need to make new flatten polys at 4.0 meters to re-flatten the terrain. The package that contains the new exclusion rectangle should be named something like "zzz-mywonderfulscenery"... starting as zzz so it is loaded after the kristiansand-1 package. You can make a package, and then rename it after the compiling, and placing it in Community if you want.

View attachment 96525

View attachment 96526

YES! Worked perfectly!.

We are getting close, but still some scenery adaption necessary for it to be complete, but the light issues have been resolved! Thank you so much

 

[Nordscape]

And it's done, thanks to all your help! ENKH is complete and fully released on Flightsim.to