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

Altitude

Messages
1,029
When using the Ground Polygon Wizard in the latest development version of MCX, there is in red text that says, "Enter absolute altitude!" What does this mean? Is that altitude AGL or is that above MSL? And where the altitude is entered, I always assumed it was MSL and not AGL. So, which is it?

I also tried to raise a polygon 0.1 meter above the ground so that it will be above the other. The airport elevation is 185.012076 meters. I entered 185.112076, which is 0.1 meter higher, and it did not raise the polygon at all. It stayed right on the ground. I entered different altitudes, and there is no change in the sim. This is for P3Dv 4.5, not FSX. Of course, there is no version 4.5 shown but a 4.4, but I assume the 4.4 button will work for P3D version 4.5.

Ken.
 
Last edited:
The proper definitions for aviation as used in USA, at least, is here: (...this is, after all, a "Flight Simulator" )

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

  • Absolute altitude is the vertical distance of the aircraft above the terrain over which it is flying. It can be measured using a radar altimeter (or "absolute altimeter").[1] Also referred to as "radar height" or feet/metres above ground level (AGL).
  • True altitude is the actual elevation above mean sea level. It is indicated altitude corrected for non-standard temperature and pressure."

Unfortunately, in the MCX G-Poly Wizard, "absolute altitude" refers to AMSL- rather than AGL. :banghead:

IIRC, in one of Don Grovestine's FS utilities "absolute altitude" also refers to AMSL- rather than AGL.


I'm not certain if there may be a different use of that term "absolute altitude" in Europe or Canada ? :scratchch

Regardless, I believe the above definition should be used in the FS Development "Aviation" Community.


BTW: Did you output a legacy SCASM / ASM G-Poly with Z-Bias ...instead of a P3Dv4.x MDL-based G-Poly ? ;)

FSDT apparently forces 3D MDL objects to assume elevations relative to its custom G-Poly "Platform" surfaces.


GaryGB
 
Last edited:
Hi,

You need to enter MSL alttiude. I'll see if I can rename the label.

The alttiude is only used to calculate the correct curve of the polygons. They polygons are still placed on ground level whatever you enter.
 
Regardless, I believe the above definition should be used in the FS Development "Aviation" Community.
I wholeheartedly agree and if rogue developers don't follow canon, the members of the FSDAC should universally dismiss their creations as "UFO's."

vril-flying-saucer2.jpg


One may compile a ground polygon using Resample.exe. Then, using MCX, extract that model and compile as a library .bgl, which can be placed at any given altitude.
 
https://www.fsdeveloper.com/forum/threads/altitude.446488/post-833751

I wholeheartedly agree and if rogue developers don't follow canon, the members of the FSDAC should universally dismiss their creations as "UFO's."

vril-flying-saucer2.jpg


One may compile a ground polygon using Resample.exe. Then, using MCX, extract that model and compile as a library .bgl, which can be placed at any given altitude.


G-Polys are 3D objects 'placed' in very close proximity to local ground surfaces ...with- or without- Z-Bias applied.

SDK Resample is a raster processing compiler capable of writing vector placement into BGLs; AFAIK, it does not output 3D models that can be imported by MCX; for that one would use SCASM / ASM or MDL -based compilers.

FSDT does, however use MDL-based SimObjects (with- or without- "Platforms") as G-Polys, which it places at assigned elevations via 1 or more Python-based proprietary FS Modules.

[EDITED]

In some cases the FSDT MDL-based SimObjects are multi-planar, and only certain faces of the overall 3D object are configured to have "Platforms" via AttachPoints in order to function as G-Polys where the 3D object is to be "on ground",

Technically, FSDT MDL-based SimObject G-Polys with Sim.Cfg files 'could' be configured to work as BGLComp-compiled scenery objects and be 'placed' via BGLComp-type or Autogen type XML methods, or conditionally display as AI / Ground Traffic, user-operated standard- or Multi-Player- aircraft, custom Control Towers (... or even as "UFOs"). ;)

[END_EDIT]


AFAIK, this thread pertains to making "replacement" ground markings at FSDT airports as originally discussed here:

https://www.fsdeveloper.com/forum/t...-textures-for-updated-airport-scenery.441812/


GaryGB
 
Last edited:
SDK Resample is a raster processing compiler capable of writing vector placement into BGLs, it does not output 3D models that can be imported by MCX; for that one would use SCASM / ASM or MDL -based compilers.
This is essentially correct, Resample.exe compiles ground polygon .bgl's, that are essentially a polygon model with placement information. Using MCX, one can extract the ground polygon and instead, incorporate that into its own, or a unique library .bgl that contains a collection of objects. From there, it is a relatively simple matter of placing the ground polygon, like any scenery object.

I used this "hack" sucessfully to complete a commercial project. Id's already completed the ground polygon to satisfaction and a request was made for a chalk line in the grass. Rather than reconstruct a perfectly good scenery element, I tried this idea and it worked, more or less, perfectly. I was not able to match the image attributes of the original polygon, but the slight difference in shine, or whatever, was lost in the grass. I used Instant Scenery 3 for placement and I know the OP mentions P3Dv4. In that regard, I had to make two versions, the chalk line was not visible in P3Dv4, using the version compiled for FSX. For P3Dv4, I had to elevate the chalk line polygon ever so slightly to make it visible and this version in FSX had the line high enough to noticeably pass through the airplanes tires.
 
Resample.exe compiles ground polygon .bgl's, that are essentially a polygon model with placement information. Using MCX, one can extract the ground polygon and instead, incorporate that into its own, or a unique library .bgl that contains a collection of objects. From there, it is a relatively simple matter of placing the ground polygon, like any scenery object.

MCX can't read BGL files that are made by resample, it will only read BGLComp BGL files.

I'm not sure I can follow you when you say resample compiles polygons, AFAIK it can only compile raster data into photoreal or elevation BGL files.
 
https://www.mediafire.com/file/tq4ez00y40mlsnq/KDFW_C39_Ground_Markings.zip/file

The above *.ZIP contains source code and a imagery BGL compiled by SDK Resample for Ken's C39 replacement ground marking G-Poly project area at FSDT KDFW as discussed in the original thread linked above:

https://www.fsdeveloper.com/forum/t...-textures-for-updated-airport-scenery.441812/


AFAIK, SDK Resample does not output 3D models that can be imported by MCX.

Perhaps there is undocumented info you are alluding to that Arno may not yet have disclosed to the rest of us about MCX having the ability to import SDK Resample BGLs ? :scratchch


Otherwise, IIUC, to do what you seem to describe, MCX would have to import a 3D object from:

* SCASM / ASM source code or compiled BGLs in legacy non-MDL format

...or:

*.ASM / *.X file source code or compiled BGLs in MDL-based format (from ex: MakeMDL or XtoMDL compilers).


I believe when anyone attempts to import the BGL in the linked *.ZIP above, MCX will not import it. :rolleyes:


GaryGB
 
MCX can't read BGL files that are made by resample, it will only read BGLComp BGL files.

I'm not sure I can follow you when you say resample compiles polygons, AFAIK it can only compile raster data into photoreal or elevation BGL files.
It was quite some time ago, I apologize for the confusion. I am absolutely certain that I placed a flat polygon, over a compiled ground polygon. It was an adaptation of the procedure I'd described in the Wiki. You can see, in the image below, it can be an effective trick for adding small details to a larger GP.

Ground.JPG


I see now that I did not use Resample.exe, I did indeed use the GPW, but then I extracted the polygon model from that complied .bgl. From that point, the procedure is essentially what I'd described above.

 
The proper definitions for aviation as used in USA, at least, is here: (...this is, after all, a "Flight Simulator" )

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

  • Absolute altitude is the vertical distance of the aircraft above the terrain over which it is flying. It can be measured using a radar altimeter (or "absolute altimeter").[1] Also referred to as "radar height" or feet/metres above ground level (AGL).
  • True altitude is the actual elevation above mean sea level. It is indicated altitude corrected for non-standard temperature and pressure."

Hi Gary,

Yes, I read that at Wikipedia and that's what I thought it would be, altitude above the ground as measured using a radar altimeter. But I was always hearing that the altitude was entered as MSL when using the Ground Poly Wizard. I don't know why I forgot about this but, Arno states that the altitude is only used to calculate the correct curve of the polygons. The polygons are placed at ground level, no matter what altitude you enter, and that's exactly what was happening. So, apparently, this altitude has nothing to do with placing my ground markings at a certain height. When you convert the compiled bgl to an xml file, you will see that the Altitude is 0.0 meters and AGL = True. To change the altitude, one would use the "Convert and Place Object Wizard." This will allow for setting the height of ground markings

But this is not going to work in the FSDT for P3Dv4.5. I've been doing more testing, and I believe I've figured out what I need to do to make this work, at least so far. It will be a little time consuming but I guess that's okay. I've stated the problem that every time I go out a few miles from the airport and returned, my ground custom ground marking C39 would be gone. It was no longer there and it was back to C32. Here's what I found out: So far, this problem only occurs whenever I used the "Convert and Place Object Wizard" and when I place that C39 0.1 meter, or about 4 inches, about the C32. But when I use the "Ground Poly Wizard," I no longer have that problem and my C39 remained on the ground, even after I returned back to the gate, and the good thing is that my C39 was right on the ground as it should be. But the problem is that the C32 is still in view along with the C39 and you see both the C39 and C32. I thought maybe setting the layer priority would solve that problem but apparently doesn't work that way. Setting my C39 at a higher layer made no difference, and I set the layer all the way to 64, both in the + and - directions. I found a thread just the other day, and if I remember correctly, Arno stated that setting the layer to a higher priority does not hide what's below it, correct me if I'm wrong Arno. I've thought at one time that if the layer is set it to a higher layer, it hides what's below it, but I'm not seeing that, unless I'm not doing something right. And one thing, I'm using a transparent background, and only the numbers themselves are opaque. So, I would like to determine if using a totally opaque layer and setting it to a higher number will hide what's below.

Since the FSDT ground textures are mapped over the model, they need to be removed. That can be done by removing the FSDT_det10.dds. But you also remove all of the ground markings, including the V shaped parking radius markings and the runway edge lines. To avoid this, I made a copy of the original FSDT_det10.dds and removed ONLY the letters and numbers that were relating to those ground markings, and leave everything else intact. All I need to do is to use the original numbers and letters from that texture to create the correct ground marking gate numbers using the Ground Poly Wizard. I no longer have to worry about the C32, or any wrong numbers on the ground because they will be gone. Whatever I replace it with should be right on the ground and nothing will be below it. This should work without any problem.

I'm trying to figure out how to make 2 separate layer windows in Gimp, but have not been able to do so. I uncheck the Single Window Mode, but it's still does not load my windows separately. I mean, they do come up separately but instead of having 2 windows, they just show up on the right in a menu. It's not that important and I'm just having to switch between layers in that menu on the right. What I'm trying to do is open the original texture FSDT_det10.dds into Gimp and use that to create my C39 as well as all the other gates that are numbered wrong. If possible, I prefer to select and copy the letters and numbers and past them onto another separate transparent layer. I know I could use the Fuzzy Select Tool but sometimes, it doesn't seem to get all of the outline and inside very well. I've been able to copy and past the Letter "C" but when I try to go back and select the number 3, it doesn't past it in the other layer. It may be that I'll have to use the Fuzzy Tool.


Unfortunately, in the MCX G-Poly Wizard, "absolute altitude" refers to AMSL- rather than AGL. IIRC, in one of Don Grovestine's FS utilities "absolute altitude" also refers to AMSL- rather than AGL. :banghead:

Yes, that's what was confusing me.


Did you output a legacy SCASM / ASM G-Poly with Z-Bias ...instead of a P3Dv4.x MDL-based G-Poly ? ;)

I'm not sure what you mean and what that legacy SCASM/ASM means, or what that is, but I don't think I did. I never used any tool that said SCASM/ASM because I'm not familiar with it and how to use it. Does Arno have a video that explains that, or is there a tutorial that explains that in detail?


Ken.
 
Last edited:
Hi Ken:

I am again compelled to recommend that you review the original thread on this topic in its entirety:

https://www.fsdeveloper.com/forum/t...-textures-for-updated-airport-scenery.441812/

[EDITED]

Please especially take note of the information I recently edited into a post in that thread ...here:

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-798357

[END_EDIT]


To do what you are attempting to do would require extensive self-study, and may take quite a bit of time. :redflag:


I must remind you that IMHO, it is impractical to attempt to edit all existing Material maps / properties / functions / animations etc. and then re-compile a copy of FSDT's:

KDFW_sett07_sf.mdl :alert:


...as previously discussed here:

https://www.fsdeveloper.com/forum/t...or-updated-airport-scenery.441812/post-798485

fsdt-kdfw-c32-ground-markings-mcx_heirarchy_editor_info-jpg.53486


(FSDT KDFW "Demo" version MDL shown)



I believe it may be best to create a "FSX" legacy format- not a P3D format- G-Poly in MCX' G-Poly Wizard.

Note that a FSX (FS2002 aka "FS8") legacy format G-Poly will be compiled from legacy format (SCASM / ASM) source code.

A FSX G-Poly will have limited Material display attributes, but has the ability to apply Z-Bias to its display position relative to the ground surface where it is placed.

You must pick an Altitude and Z-Bias (VTP Layer#) to place your G-Poly relative to FSDT G-Poly KDFW_sett07_sf.mdl


The MCX wiki documentation for G-Poly Wizard is here:

https://www.fsdeveloper.com/wiki/index.php?title=ModelConverterX#Ground_polygon_wizard


Arno's YouTube video on ModelConverterX - Ground Polygon Wizard is here:



GaryGB
 

Attachments

  • FSDT KDFW C32 ground markings MCX_Heirarchy_Editor_Info.jpg
    FSDT KDFW C32 ground markings MCX_Heirarchy_Editor_Info.jpg
    234.2 KB · Views: 1,351
Last edited:
"Bumped" for edits to update a linked thread above:

https://www.fsdeveloper.com/forum/threads/altitude.446488/post-833800


NOTAM: This "gotcha" involves otherwise undocumented complexities involved with use of the new P3D SDK "Z-Bias" Material Property ...when vertically Z-sorting multiple 3D MDLs in the same scene with a true P3D "G-Poly" : :banghead:

Interested readers may discern the issue was solved using legacy methods of 2 layer intervals between "even" layer numbers. :laughing:


GaryGB
 
Last edited:
Hi Ken:I am again compelled to recommend that you review the original thread on this topic in its entirety:

https://www.fsdeveloper.com/forum/t...-textures-for-updated-airport-scenery.441812/

Okay, now I understand better how to use Gimp. But I used a different method than what I've used the last time.


To do what you are attempting to do would require extensive self-study, and may take quite a bit of time. :redflag:

Yes, I know that. I've realized and said that it would take some time. The real problem was, and is, with the understanding of how all of this works in FSDT, and I've learned quite a bit staying with it. I'm just determined to learn and better understand how all of the sceneries, models, and textures are put together. Each time I came back on this project, I've learned something new.


I must remind you that IMHO, it is impractical to attempt to edit all existing Material maps / properties / functions / animations etc. and then re-compile a copy of FSDT's:

KDFW_sett07_sf.mdl :alert:

I know you reminded me several times regarding this being impractical, but I have successfully completed all 26 ground markings at the C Terminal without any issues in P3Dv4.5, and completed this 3 days ago:


Completed Ground Markings 1.jpg



Completed Ground Markings 2.jpg



I've only completed the C Terminal and I'll work on the A, B, D, and E terminals at a later date. It's not that it's impractical. Some of my problems were in the way I was using the Tools in MCX, not using the correct ones and not understanding some of it's functions. Since the textures were mapped over the model and the ground markings were the things I was concerned with, and since I would be compiling my own ground .bgl files, I did not need to do anything with the KDFW_sett07_sf.mdl model. I know the way I did this would not have been the way FSDT would have done it if they made these changes, but this was the best way I knew for the time being.

I've noticed you have a screen shot of a Hierarchy Editor below. I do have some idea about it but I did not use this method to remove the wrong gate numbers on the ground. One can use this method but you cannot just select a particular ground marking, such as C32, and remove it without removing other ground markings. There are several ground markings that's tied together in just 1 file. One can also do this in the Material Editor after loading the model. From my understanding, the KDFW_dett10.dds is a template for these ground textures, and only removes what's drawn on that texture sheet if you remove that file. If you noticed, when you select the FSDT_dett10.dds in the Material Editor, those ground markings highlight in red, letting you know what texture or item will be changed or removed.


fsdt-kdfw-c32-ground-markings-mcx_heirarchy_editor_info-jpg.53486



I've also noticed that your attachment says FSDT KDFW C32 Ground Marking with an image from the Hierarchy Editor. I don't think the kdfw_32 represents the C32 ground marking. There are 5 of these in the properties of the material editor with that same name - kdfw_32. If you select each one, it does not select that C32 ground marking in the mdl model. I'm glad it worked successfully. There was extra work I had to do to get them placed exactly as they were originally, and there are 26 gates.


FSDT KDFW C32 ground markings MCX_Heirarchy_Editor_Info.jpg


Ken.
 
Last edited:
Hi Ken:

Congratulations on what IIUC is your reported progress with output of G-Polys from MCX that are now displaying properly in P3Dv4.5. :)


When I get some time I shall verify the KDFW_32 object selected in the MCX Hierarchy Editor is highlighted in RED, and post a screenshot.

That would of course merely be a note in passing as to what MCX is able to display, and would not be useful to your current process of covering up such FSDT KDFW ground markings with replacement G-Polys made via MCX G-Poly Wizard in either FS2Kx / legacy or P3Dv4.5 format.


By now you should know that I am confident in your ability to achieve all that you wish; keep up the good work with the learning process ! ;)

GaryGB
 
Last edited:
Hi Ken:

Congratulations on what IIUC is your reported progress with output of G-Polys from MCX that are now displaying properly in P3Dv4.5. :)


When I get some time I shall verify the KDFW_32 object selected in the MCX Hierarchy Editor is highlighted in RED, and post a screenshot.

That would of course merely be a note in passing as to what MCX is able to display, and would not be useful to your current process of covering up such FSDT KDFW ground markings with replacement G-Polys made via MCX G-Poly Wizard in either FS2Kx / legacy or P3Dv4.5 format.


By now you should know that I am confident in your ability to achieve all that you wish; keep up the good work with the learning process ! ;)

GaryGB


Hi Gary,

These are the ones I have that highlighted but you can check yours and see if you get the same:


kdfw_32 - 1.jpg




kdfw_32 - 2.jpg




kdfw_32 - 3.jpg




kdfw_32 - 4.jpg



Ken.
 
Back
Top