MSFS20 Possible to remove a certain area from a 3rd party photogrammetry area?

[Nordscape]

Hello. I am working on a helipad where I want it to be compatible with available 3rd party photogrammetry in the specific area. I've tried to add an exclusion polygon to exclude library scenery from that specific area but it doesn't show any changes.

The photogrammetry is also designed in such a way that the actual MSFS scenery mesh underneath the photogrammetry is leveled to altitude 0.

How do I raise the terrain underneath the specific custom made scenery, and remove the photogrammetry just from the custom scenery area?

 

[GaryGB]

Hi Vetle:

Just a quick reply regarding the procedure for- and fine detail capability of- a TIN exclude in MSFS SDK DevMode Scenery Editor:

https://www.fsdeveloper.com/forum/t...ve-rocky-photogrametry-monolith-trees.455740/


BTW: Which "available 3rd party photogrammetry in the specific area" (...of ENSX) are you referring to ?

If you post a link to that info, I'll take a look at it and will see if I can provide a workflow link or explanation of how to fix it.


PS: I have found (2) at flightsim.to, (both of which due to photogrammetry details are necessarily big); is it one of these ?


BTW: Now you know why I thought it would be a good idea to get access to the local ENSX LIDAR data.

You can make your own local ENSX photogrammetry from the LIDAR data if need be.

GaryGB

 

[Nordscape]

Hi Vetle:

Just a quick reply regarding the procedure for- and fine detail capability of- a TIN exclude in MSFS SDK DevMode Scenery Editor:

https://www.fsdeveloper.com/forum/t...ve-rocky-photogrametry-monolith-trees.455740/


BTW: Which "available 3rd party photogrammetry in the specific area" (...of ENSX) are you referring to ?

If you post a link to that info, I'll take a look at it and will see if I can provide a workflow link or explanation of how to fix it.


PS: I have found (2) at flightsim.to, (both of which due to photogrammetry details are necessarily big); is it one of these ?


BTW: Now you know why I thought it would be a good idea to get access to the local ENSX LIDAR data.

You can make your own local ENSX photogrammetry from the LIDAR data if need be.

GaryGB

I like your thinking! If the textures follow the buildings then we are all set in my opinion!

The photogrammetry I use I believe is this one: https://flightsim.to/file/29046/stavanger-norway

 

[GaryGB]

I like your thinking! If the textures follow the buildings then we are all set in my opinion!

The photogrammetry I use I believe is this one: https://flightsim.to/file/29046/stavanger-norway

Indeed, when imported to MCX, that 3D Object section of "photogrammetry" is # 34 while advancing into the entire library in preview mode.

I'll take a look at it later today; was there (a) particular object(s) you planned to exclude other than the TIN Helipad building ?

GaryGB

 

[Nordscape]

Indeed, when imported to MCX, that 3D Object section of TIN is # 34 while advancing into the entire library in preview mode.

I'll take a look at it later today; was there (a) particular object(s) you planned to exclude other than the TIN Helipad building ?

GaryGB

Thank you! No, just the photogrammetry helibase.

 

[GaryGB]

Hi Vetle:

Excluding all of 3D object tile # 34 above is possible, but that disables a large part of photogrammetry local to ENSX Hospital Helipad.

The entire array of 3D tile Reference Point 'placements' from enjoyitfly-stavanger 3D Library Object tile set in MCX is 8x8

NOTE: This correlates with a FS SDK Terrain quad grid interval of 305.8 Meters at LOD-15 / QMID-17 per 3D tile in SBuilderX.

This 3D tile grid array correlates with a FS SDK Terrain quad grid interval of 38.2 Meters at LOD-10 / QMID-12 per ModelPart in MCX:

MCX Hierarchy Editor can remove 6 to 7 ModelParts of that 3D tile library object local to ENSX, but one must edit a 3rd party scenery.

ModelConverterX info:

Patrick Germain's BGLViewer info for placement file: Objects.bgl.:

9C : Id               : 0xB (11)
9E : Size             : 0x40 (64) : 0x9C -> 0xDC
A0 : Longitude        : 5.729337931
A4 : Latitude         : 58.949894831
A8 : Altitude         : -372 ft / -113.38 m
AC : AltitudeIsAgl    : NO
AE : Pitch            : 0
B0 : Bank             : 359.9945
B2 : Heading          : 359.9945
B4 : Image Complexity : Very_Sparse
B6 : ???              : 00 00
B8 : InstanceId       : {00000000-0000-0000-0000-000000000000}
C8 : Guid             : {8B755D4B-31AE-4AFD-AC04-872458B18107}
D8 : Scale            : 1.00

[EDITED]

NOTE: Patrick Germain's BGLViewer states the placement Altitude of 3D Scenery Library Objects in this BGL to be: -113.38 Meters MSL

Scruffyduck BGL2XML180 states the placement Altitude of 3D Scenery Library Objects in this BGL to be: -113.382 Meters MSL.

A difference of 0.002 M = 0.07873992 Inches; this may- or may not- affect a 3D model Datum / Reference Point 'Exclusion' intercept


Yeah, I know, BGL2XML reads FS2Kx format BGLs and outputs FS2Kx format XML; but there is 'transitional' data retro-compatibility.


Ultimately I intend to also try using msfsbglxml 1.1.20220130 to see if I can get a (mostly) MSFS SDK compliant XML output file.

Then I will see if anything needs to be tweaked in the XML it outputs.


Yeah, I know, msfsbglxml is "abandonware"... like so many things in the FSDEV Community.


[RANT_MODE_ON]

It really would be refreshing if I did not have to piddle around in a 'hacky' way to get at MSFS data and work with MSFS scenery.

WANTED: FS utility authors with "MoJo" to go the full distance, and provide us with fully functional FS utilities ...like we had in FS2Kx.

NOTE: STAMINA is NOT OPTIONAL for this urgent task !!!

[RANT_MODE_OFF]


Reportedly, Google 3D content RIPs for MSFS 3rd party Photogrammetry emulation are output / placed as 3D Library Objects.

In the case of 3D objects in the "Enjoy" add-on cited above, they are placed at -372 ft / -113.382 MSL.


AFAIK MSFS 3D objects made by the Google 3D content RIP utility are hardened / collide-able; this impacts DevMode GUI vector draws.

IIUC, DevMode GUI vector draws stay on top of a "apparent" local ground surface, so one cannot place vectors at -372 ft / -113.382 MSL.

IIUC, in MSFS, Polygons can have an Altitude Attribute, but a "ExclusionRectangle" can not; does this prevent me from excluding 3D tiles ?

So I plan to test a manually coded MSFS "ExclusionRectangle" with a 'Exclude Library Objects' attribute for the entire local "Enjoy" 3D tile.

[END_EDIT]


If the author had used Norway GIS 1 Meter LIDAR themselves, there would not be an issue of requiring Googles permission for data use.

One can exclude a full 3D object # 34, and replace local objects with custom photogrammetry using 1 Meter LIDAR via ENSX' Package BGL.

To remove 6 to 7 smaller ModelParts of that 3D object local to ENSX with an exclude that works from a BGL, we must ask Arno if such an exclude can even be implemented via BGL for specified ModelParts in a glTF without actually editing / recompiling the 3D model.

I am doubtful this has been done before, but as we now have the mixed blessing / problem of increasing numbers of these custom photogrammetry scenery packages being released for MSFS which require local excludes to allow replacement with 3rd party local objects having higher accuracy, it would be very helpful to have this ability for the future of FS Development using Exclude and Replace methods.

UPDATE: I would declare the photogrammetry package in question as compatible up to a point, and you would otherwise need to replace most of the area surrounding your custom ENSX Hospital Helipad with custom 3D scenery objects, or allow default 3D scenery objects to be displayed instead.

GaryGB

 

[=rk=]

I am doubtful this has been done before, but as we now have the mixed blessing / problem of increasing numbers of these custom photogrammetry scenery packages being released for MSFS which require local excludes to allow replacement with 3rd party local objects having higher accuracy, it would be very helpful to have this ability for the future of FS Development using Exclude and Replace methods.

It's my belief that generative AI will free us from the mixed blessing of virtually every developer reinterpreting his or her own vision of a Heinz ketchup bottle, a Cessna 150 and the Eiffel Tower for fear of infringing copyright, as well as the list of sceneries that one must download and then partially exclude in order to arrive at the exact same scene as above, until at least such point that the various simulators stop carving up reality and ours relinquishes its insistence on "flight."

 

[GaryGB]

As to Heinz products, one might wonder if it would be a better- or worse- scenario if AI created more- or less- than 57 varieties.

https://en.wikipedia.org/wiki/Heinz_57


Hmmm... "simulators carving up reality and ours relinquishing its insistence on 'flight' " ?

AFAIK, most FS Developers never have time to- or seemingly never want to- ...'fly'.


Regardless, this Stavanger ENSX Helipad sets a new standard for realism compared to other "varieties" of MSFS scenery.

Oh, and it was made with an older "original Recipe" variety of ...'SKetchup'.

GaryGB

 

[Nordscape]

Hi Vetle:

Excluding all of object # 34 above is possible, but that disables a large part of photogrammetry in the vicinity of ENSX Hospital Helipad.

MCX Hierarchy Editor can remove 4 to 6 smaller ModelParts of that 3D object local to ENSX, but that requires editing a 3rd party scenery.

View attachment 94946

View attachment 94947

If the author had used Norway GIS 1 Meter LIDAR themselves, there would not be an issue of requiring Googles permission for data use.

One can use an exclude BGL for a complete object # 34, and replace local objects with custom photogrammetry using 1 Meter LIDAR.

To remove 4 to 6 smaller ModelParts of that 3D object local to ENSX with an exclude that works from a BGL, we would have to ask Arno if such an exclude can even be implemented via BGL for specified ModelParts in a glTF without actually editing / recompiling the 3D model.

I am doubtful this has been done before, but as we now have the mixed blessing / problem of increasing numbers of these custom photogrammetry scenery packages being released for MSFS which require local excludes to allow replacement with 3rd party local objects having higher accuracy, it would be very helpful to have this ability for the future of FS Development using Exclude and Replace methods.

UPDATE: I would declare the photogrammetry package in question as compatible up to a point, and you would otherwise need to replace most of the area surrounding your custom ENSX Hospital Helipad with custom 3D scenery objects, or allow default 3D scenery objects to be displayed instead.

GaryGB

Holy smokes! That looks pretty good to be fair, but I'm having some trouble relating to the obvious squared cuts in the terrain. I was kind of hoping it was possible to cut exactly around the custom scenery but if that is an issue, I think I might pass on this solution. I will however examine the other approach which is to download 3D buildings. I'll send you a link shortly.

 

[GaryGB]

Hi Vetle:

As an update on excluding a minimum of 3D object 'faux' photogrammetry tiles, I edited my post above on this thread page ...here:

https://www.fsdeveloper.com/forum/t...-party-photogrammetry-area.459478/post-929869


A better solution for the MSFS Community is FS Developers learning how to make actual MSFS SDK compliant TIN photogrammetry tiles.


Then we can exclude even the smallest portion of TIN photogrammetry geometry as I illustrated in the thread cited above:

https://www.fsdeveloper.com/forum/t...ve-rocky-photogrametry-monolith-trees.455740/


We may not exclude with fine granularity, any 'portions' of 3D modeled 'faux' photogrammetry as utilized in this add-on used at ESNS:

https://flightsim.to/file/29046/stavanger-norway

Note that the author of that add-on states:

"Big thanks and credits to

Jonahex111- Google Earth Decoder

Thalixte - Google Earth Decoder optimization tools"


Note as well that "Thalixte" the author of (aka "GEDOT") has updated this latter utility suite for use with MSFS:

https://github.com/Thalixte/Google-Earth-Decoder-Optimization-Tools

https://flightsim.to/file/26245/google-earth-decoder-optimization-tools-gedot-blender-addon


That may- or may not- prove to be a good thing for MSFS end users if sufficient SDK options are not available to exclude its output.


If we have to deal with a proliferation of MSFS 3D object 'faux' photogrammetry, it may prove difficult for MSFS end users to control.

And, in spite of how much more detailed 3D ground tiles may look compared to a drape of imagery over CVX vector TIN terrain, MSFS end users may not have the granularity of control to exclude smaller portions of custom textured 3D ground tiles compared to Terrain.


All that said, how to make MSFS photogrammetry is not documented in MSFS20 SDK Docs (yet ?) other than this obscure statement:

https://docs.flightsimulator.com/ht...Babylon_Utilities.htm?rhhlterm=photogrammetry


"KHR_materials_unlit: Specifies that a material should not be affected by light. Useful for pre-lit materials (e.g. photogrammetry)."


Hmmm... that suggests glTF files may be used in 'photogrammetry'; the question is, whether that refers to default versus custom ?


More on this "Faux-Pho" work-around task later...


Maybe I'll try to add a new product type into the MSFS Marketplace: T-Shirts that say: "MoJo for Faux-Pho".

< Or was that instead: "PayPal my 'MoJo for Faux-Pho' Apparel" ? >


No, I don't think I'll ask anyone to 'buy me a coffee'; I've had way too much today already.

GaryGB

 

[GaryGB]

OK, as promised: "More on this "Faux-Pho" work-around task".


Here is what the ENSX scenery looks like with this enjoyitfly-stavanger 3D Library Object placement BGL disabled:

[MSFS-2020_Packages path]\Community\enjoyitfly-stavanger_1gYMH\enjoyitfly-stavanger\scenery\enjoyitfly\Objects.BGL

< Note: The enjoyitfly-stavanger ModelLibBGL and Shapes.BGL are loaded; the local flatten is in the Shapes "CVX-type" BGL >

In MSFS 2020 DevMode GUI, I am now able to draw Polygons directly upon flattened local ground..


In MSFS 2020 DevMode GUI, I am now able to draw a ExclusionRectangle on flattened local ground

...that excludes Library Objects only.


I [Save Scenery], saving all vector work to a 'Shapes.shp' file in \nightstalkers ENSX projects \Package Sources sub-folder chain.

Next, I [Build All] to compile; there are no errors reported,


I then remove the existing build of:

[MSFS-2020_Packages path]\Community\nightstalkers-airport-ensx-stavanger-universitetssjukehus

...and replace it with the just-compiled version from \nightstalkers ENSX projects \Packages sub-folder chain.



In [MSFS-2020_Packages path]\Community\enjoyitfly-stavanger_1gYMH\enjoyitfly-stavanger\scenery\enjoyitfly\ sub-folder:

* I re-enable Objects.BGL.

< Note: 'enjoyitfly-stavanger_1gYMH' ModelLibBGL, Shapes, Objects.BGLs are now all loaded >


Here is what the ENSX scenery looks like with this enjoyitfly-stavanger 3D Library Object placement BGL re-enabled:

The entire enjoyitfly-stavanger 3D Library Object tile set has reloaded.

This is in spite of my placement of an underlying ExclusionRectangle on flattened local ground that excludes Library Objects only.


After re-assigning nightstalkers ENSX package to load after (on top of) enjoyitfly-stavanger_1gYMH

Here is what the ENSX scenery looks like with 'enjoyitfly-stavanger' ModelLibBGL, Shapes, Objects BGLs all loaded / re-enabled:

Again, the entire enjoyitfly-stavanger 3D Library Object tile set has reloaded.

Again, this is in spite of placing an underlying ExclusionRectangle on flattened local ground that excludes Library Objects only.


Are MSFS20 SDK DevMode ExclusionRectangles malfunctioning, or do undocumented SDK 'gotchas' require 1 Exclude per 3D 'tile' ?

Or are MSFS20 SDK DevMode ExclusionRectangles functioning properly, but maximum extent of impact is limited to a quad-size Area ?


If so, what LOD "quad" size Area (by FS legacy terrain grid scheme) are MSFS20 SDK DevMode 'ExclusionRectangles' limited to ?

In the past, IIRC, 'Area' excludes by 'Area Layer' in Scenery.Cfg were limited in granularity to LOD-13 quad extents.

LOD-13 quad extents @ Earth's Equator: ~1023 x 1023) Meters.

IIUC, LOD-13 quads are 'smaller' @ ~59 Degrees North on the globe (...where ENSX is located).


However, with FSX terrain scenery content is excluded by terrain grid quads / clips of LOD-9 / QMID-11 or LOD-13 / QMID-15 extent.


If MSFS20 SDK DevMode ExclusionRectangles requires 1 Exclude per 3D model, it is a lot of work to ID / exclude a specific 3D tile object.


Otherwise... almost as much fun as excluding SCASM / ASM 3D scenery objects; one must decompile / edit / recompile Objects.BGL.


OK, coffee break time; oh, yeah ...that's right, I've had way too much today already.


Observations / Suggestions / Shared 'Sagas' of dealing with MSFS ExclusionRectangles for custom 3D objects all welcome at this point.

GaryGB

 

[Nordscape]

OK, as promised: "More on this "Faux-Pho" work-around task".


Here is what the ENSX scenery looks like with this enjoyitfly-stavanger 3D Library Object placement BGL disabled:

[MSFS-2020_Packages path]\Community\enjoyitfly-stavanger_1gYMH\enjoyitfly-stavanger\scenery\enjoyitfly\Objects.BGL

< Note: The enjoyitfly-stavanger ModelLibBGL and Shapes.BGL are loaded; the local flatten is in the Shapes "CVX-type" BGL >

View attachment 94972

In MSFS 2020 DevMode GUI, I am now able to draw a ExclusionRectangle on flattened local ground that excludes Library Objects only.

I [Save Scenery], making certain that vector work saves to a Shapes file in \nightstalkers ENSX projects \Package Sources sub-folder chain.

Next, I [Build All] to compile; there are no errors reported,


I then remove the existing build of:

[MSFS-2020_Packages path]\Community\nightstalkers-airport-ensx-stavanger-universitetssjukehus

...and replace it with the just-compiled version from \nightstalkers ENSX projects \Packages sub-folder chain.



In [MSFS-2020_Packages path]\Community\enjoyitfly-stavanger_1gYMH\enjoyitfly-stavanger\scenery\enjoyitfly\ sub-folder:

* I re-enable Objects.BGL.

< Note: : ModelLibBGL, Shapes, Objects.BGLs are now all loaded >


Here is what the ENSX scenery looks like with this enjoyitfly-stavanger 3D Library Object placement BGL re-enabled:

View attachment 94973

The entire enjoyitfly-stavanger 3D Library Object tile set has reloaded.

This is in spite of my placement of an underlying ExclusionRectangle on flattened local ground that excludes Library Objects only.


After re-assigning nightstalkers ENSX package to load after (on top of) enjoyitfly-stavanger_1gYMH

Here is what the ENSX scenery looks like with this enjoyitfly-stavanger ModelLibBGL, Shapes, Objects.BGLs all loaded / re-enabled:

View attachment 94974

Again, the entire enjoyitfly-stavanger 3D Library Object tile set has reloaded.


Are MSFS20 SDK DevMode ExclusionRectangles malfunctioning, or does an undocumented 'gotcha' require 1 Exclude per 3D model ?


If MSFS20 SDK DevMode ExclusionRectangles requires 1 Exclude per 3D model, it is a lot of work to ID / exclude a specific 3D tile object.


Otherwise... almost as much fun as excluding a SCASM / ASM 3D scenery object; one must decompile / edit / recompile Objects.BGL.


OK, coffee break time; oh, yeah ...that's right, I've had way too much today already.


Observations / Suggestions / Shared 'Sagas' of dealing with MSFS ExclusionRectangles for custom 3D objects all welcome at this point.

GaryGB

Quite the extensive work you are putting in. Thank you so much for following the thread, and troubleshooting. Hope it's possible to solve!

 

[GaryGB]

Thanks for the encouragement.

For the FS Development Community, IMHO, it is crucial to be able to exclude the very smallest 3D tiles of such "faux photogrammetry".

Otherwise FS Developers must declare their add-ons incompatible with 3rd party photogrammetry add-ons not made as CVX vector TINs.


While having questions about possible SDK exclude bugs, or SDK quirks involving Helipads as 'World Hub' objects, now I get this:

This is the opposite of what I had previously requested; the local 3D tile shows under the Helipad, and the University does not show.

I wonder about possible 'lag' or 'latency' in VFS updates of run time rendering after packages are updated and MSFS restarted ASAP.


Polygons with duplicate attributes reportedly cancel each other out; do duplicate ExclusionRectangles cause 'opposite' rendering results ?


It seems feasible that, if a local "faux Pho" 3D tile is excluded, one can make / precision 'place' a higher resolution 3D replacement "tile".

GaryGB

 

[Nordscape]

Thanks for the encouragement.

While having questions about possible issues of SDK bugs, or SDK quirks involving Helipads as 'World Hub' objects, now I get this:

View attachment 94983

This is the opposite of what I had previously requested; the local3D tile shows under the Helipad, and the University does not show.

I wonder about possible 'lag' or 'latency' in VFS updates of run time rendering after packages are updated and MSFS restarted ASAP.

Conflicting objects are supposed to cancel each other out; it makes no sense for (2) excludes to result in the opposite rendering result.

GaryGB

Holy smokes... There is a lot of stuff going on which I do not really understand, but I am glad you are spending some time troubleshootin'

 

[GaryGB]

Hi again:

Further to the ongoing test of concept for selectively excluding tiles from enjoyitfly-stavanger 3D Library Object tile set:

MCX shows 3D model tile's Origin of Axes (aka 'Datum point' aka "Reference Point") as lower Left (SW) corner

MCX Placement To Shape Converter outputs an ESRI Shape *.SHP with *.PRJ file required to enable Google Earth import.

Entire array of 3D tile Reference Point 'placements' from enjoyitfly-stavanger 3D Library Object tile set in Google Earth:

Entire array of 3D tile Reference Point 'placements' from enjoyitfly-stavanger 3D Library Object tile set in SBuilderX:

NOTE: This correlates with a FS SDK Terrain quad grid interval of 305.8 Meters at LOD-15 / QMID-17

Selection / display of a specified 3D tile 'place' from enjoyitfly-stavanger 3D Library Object tile set Reference Point:

MSFS DevMode ExclusionRectangle Google Earth Reference Point coordinate of specified enjoyitfly-stavanger 3D tile

More to come after testing for minimum extent size of a 'ExclusionRectangle' to intercept the 3D tile Reference Point coordinate.

GaryGB

 

[Nordscape]

Hi again:

Further to the ongoing test of concept for selectively excluding tiles from enjoyitfly-stavanger 3D Library Object tile set:

MCX shows 3D model tile's Origin of Axes (aka 'central Datum point' aka "Reference Point") as lower Left (SW) corner

View attachment 95008

MCX Placement To Shape Converter outputs an ESRI Shape *.SHP with *.PRJ file required to enable Google Earth import

and selection / display of a specified 3D tile 'place' from enjoyitfly-stavanger 3D Library Object tile set Reference Point.

View attachment 95009

MSFS DevMode ExclusionRectangle Google Earth Reference Point coordinate of specified enjoyitfly-stavanger 3D tile

View attachment 95010

More to come after testing for minimum extent size of a 'ExclusionRectangle' to intercept the 3D tile Reference Point coordinate.

GaryGB

Well, Gary...this is impressive to say the least! I have no idea what is going on, but I am happy you are willing to spend time investigating possibilities! Thank you... Looking forward to any result

 

[=rk=]

Well, Gary...this is impressive to say the least! I have no idea what is going on

He's dinking with the Google default TIN. Those are the buildings that appear as if someone shot a laser gun from space at you and just before it hit, it condensed into the trees and buildings all around you in a kind of melty, spider webby way - because that's exactly how they are made. I mean, aside from the fact that you're diddling with Google's private parts, they're kind of the perfect flight simulator prop, because they only look real when you're flying!
Triangulated (laser beam shot from space) Irregular (melty spider webs) Network (trees and building all around you).

 

[Nordscape]

He's dinking with the Google default TIN. Those are the buildings that appear as if someone shot a laser gun from space at you and just before it hit, it condensed into the trees and buildings all around you in a kind of melty, spider webby way - because that's exactly how they are made. I mean, aside from the fact that you're diddling with Google's private parts, they're kind of the perfect flight simulator prop, because they only look real when you're flying!
Triangulated (laser beam shot from space) Irregular (melty spider webs) Network (trees and building all around you).

Aah, I see. Thanks for the explanation! That really describes my impression of that look!

 

[GaryGB]

Hi Vetle:

At this early stage, I am identifying a workaround for "GEDOT" methods reportedly used by the "Enjoy" Stavanger add-on author:

"Big thanks and credits to

Jonahex111- Google Earth Decoder

Thalixte - Google Earth Decoder optimization tools" (...aka "GEDOT")


< NOTE: "GEDOT" is not to be confused with "GODOT" game development platform >


"Enjoy" Stavanger 3D objects are shown above, interfere with display of your helipad, and are cited previously in these thread posts:

https://www.fsdeveloper.com/forum/t...-party-photogrammetry-area.459478/post-929858

https://www.fsdeveloper.com/forum/t...-party-photogrammetry-area.459478/post-929945


For the record, I do not encourage you to utilize "GEDOT" to make unauthorized use of Google's photogrammetry / or aerial imagery.

Hopefully your ENSX add-on may provide a way to ensure that your own work can be displayed, even if that "Enjoy" add-on is installed / loaded by end users at their own discretion.

Perhaps by providing a small 'exclude', you may ensure your ENSX add-on can be displayed, even if that "Enjoy" add-on is installed / loaded.


Alternatively, you may be able to provide a substitute "placement" BGL for the 3D model tiles used by the "Enjoy" Stavanger add-on author, which omits the 3D tile(s) local to ENSX Helipad and nearby buildings, so your own work will display without interference.

This may reduce your work extent making textured lower LOD 3D models to replace both "Enjoy"- and/or MSFS default- scenery around ENSX.

The reason for creating local replacements for the Google Earth 3D objects is obvious, as they are very low resolution:

GE's default above is as good as its gets; a "GEDOT" workflow further decimates that 3D content to even lower resolution:

I may have a chance to "dink" with this further sometime later today.

GaryGB (aka "TIN Man" ? )

 

[GaryGB]

Hi again:

MCX shows the "Enjoy" ENSX_GE_RIP_BGL_Object-34 Tile has numerous ModelParts in Hierarchy Editor (7 are removed here):

AFAIK, one would need to request the "Enjoy" author to release- or grant permission to make- an edited version of that 3D Tile BGL.

< Hmmm... one may also wonder whether "visibility condition" options can be used for ModelPart excludes and seasonal texture changes.>


Otherwise one would need to create a substitute placement BGL that excludes a minimum of full 3D tiles local to ENSX Helipad.

ENSX_GE_RIP_BGL_Object-34 Tile Origins extracted via MCX Plc2SHP in Google Earth shows a Minimum of (4) Exclude-able Tiles:

IIUC, there are separate placement coordinates for the (4) 3D tile origins in the XML, but MCX displays them as (1) 'library' meta-object.


I do still plan to test using (4) separate ExclusionRectangles to prevent run-time rendering of those (4) 3D tiles local to ENSX Helipad.


Alternatively, I shall omit 'placing' those (4) separate 3D tiles local to ENSX Helipad ...to prevent their run-time rendering.

This is likely to result in a slightly greater area of scenery objects requiring replacement with custom- or MSFS default- objects.


Additionally, one may wish to substitute a CVX Vector BGL to reduce "Enjoy" flatten extents local to ENSX Helipad.


More to come as time permits.

GaryGB