Continuation of Discussion about AFLT and Ground Polygons

[=rk=]

rk, I can't be of much help at this point. First of all I can't tell foreground from background because they are both black. It would help if you conducted these tests at dusk. Secondly, such statements as:

"In the foreground are AFLT lights as FS9 models, although I'd compiled them as .bgl lights, only the day-glo textures illuminate.

Clearly it is well above the ground level polygon, which is actually set at -.01m:​

an AFLT derived .bgl light, invoked at 1m offset of the aircraft using the FX Tool, at a height of 2m"

lead me to believe there may be some misunderstandings about the use of AFLT and ground polys. With AFLT, generally, you compile a model that includes an attachpoint for a BGL_LIGHT (in a separate file); you don't get to choose whether its a BGL_LIGHT or something else. Up close, the "day-glo" (actually, in this case, it's the _LM) texture will prevail over the BGL_LIGHT illumination. This is normal. Ground polys are drawn at a reference elevation determined by the system. You can't change that elevation. If you are able to set the elev of that poly, then it's not a "ground poly" as we use that term in ADE. AFLT lights are referenced to a geographic point, not the user aircraft. You also mentioned a file named "airport.bgl" and some use of "FX Tool". I have no knowledge of either of these.

My earlier reference was to ground polys suppressing stock lights, not BGL_LIGHTs. Nonetheless, even the portion of a BGL_LIGHT which is below the ground poly is suppressed. However, that portion of a BGL_LIGHT that casts above ground is displayed. And that's fortunate since it allows one to control the appearance of lights placed on the surface of a runway or taxiway, such as centerline lights.

I have just finished updating the custom lighting at all six of my airports. Those updates include a wide variety of light types with pilot-controlled lighting generated with AFLT. I experienced no such difficulty, nor has anyone else reported such. That doesn't mean you are not experiencing problems, but it does suggest you are trying to do something quite unusual.
I'm happy to work with you to sort out those difficulties. But, to do so, I need your local library folder so I can see how you have specified those lights. A narrative of what you are trying to accomplish with each light would also be helpful.

Could I suggest we move any further discussion on this to the AFLT forum.

Don

To be more clear, when creating a AFLT library, one may specify whether the light, base or combination is created. That is what I was referring to as an "FS9" light, one that had been compiled with the attachpoint, which is not possible with FSX lights.

The "FX Tool" is part of the SDK, I believe, it is available within sim from the Tools drop-down menu. It will render and edit any effect within the flight simulator interface, it's only real limitation being that the effect is invoked in relation to the user aircraft on a x/y/z axis, meaning the effect can't really be placed or flown past, it moves as the aircraft moves.

You wrote that ground polys are drawn at a reference elevation. This may well be the case, but I compile my ground polys as .mdl objects and place them using an addon scenery tool. I can incrementally control orientation and elevation and place them precisely upon their photo "shadows," using the placement tool within FS. I use Instant Scenery 3.

The airport .bgl is the file that contains all relevant airport data that ADE produces.
I can give you my working files and directories and even a portion of a ground polygon that you could place and experience in your own simulation.

I am trying to replace the bi-directional end lights and also the row of uni directional green threshold lights that are obscured by my polygon, or determine a way to display them properly.

 

[gadgets]

when creating a AFLT library, one may specify whether the light, base or combination is created.

No, Light Only or both. You can't create just a base.

The "FX Tool" is part of the SDK, I believe, it is available within sim from the Tools drop-down menu. It will render and edit any effect.

AFLT doesn't use effects. In your other post you referred to invoking an AFLT-derived light with FX Tool.

I compile my ground polys as .mdl objects and place them using an addon scenery tool

Then these are not true ground polys. (This term generally refers to FS8-style ground polys over which you have no elevation control.) They are plane scenery objects and their effect depends on their precise characteristics, positioning and texture.

The airport .bgl is the file that contains all relevant airport data that ADE produces.

Thanks for the clarification.

I can give you my working files and directories and even a portion of a ground polygon that you could place and experience in your own simulation.

I'm happy to take a look at the end result, but it would probably be just as useful for you to repeat today's experiment at dusk - allowing some visual reference - and a brief summary of the position of the ALT lights

I've checked the library folder; the specification of all five lights is OK. The Arrays folder does not contain any arrays but, rather a non-AFLT file named "khio_obx.bgl". So, obviously, you've placed all lights manually. Also, there's a non-AFLT file named "2-20003.mdl" in the main folder.

I am trying to replace the bi-directional end lights and also the row of uni-directional green threshold lights that are obscured by my polygon, or determine a way to display them

SO why don't you use a couple AFLT arrays. Using the sample arrays as a model, it should take you about two minutes to prepare the array definitions. Since you seem to want to cover up some stock edge-light, why not use an AFLT array for the approach lighting system and get rid of stock lights entirely? Take a look at the screenshot attached to this post. Every light you see is an AFLT light using default characteristics.

Don

 

[=rk=]

I have recorded two more images that illustrate the condition very well. It is the exact same scene recorded from two angles:

They pretty much tell the story but I'll list the details. The object lib_AF_Lights.BGL #3 is compiled as a red/green bi-directional light without a base. I used the Instant Scenery properties window to set the object elevation to 1m, then I used the Line of Objects function spaced at 1m intervals to draw a line of objects across the field of view and "under" the runway. From above, one can see that all 24 instances of lib_AF_Lights.BGL #3 were placed over the runway and only the ones that actually fell between the view point and the runway disappeared. One can also see that top-down view is not subject to the same limitations that outside view and cockpit view have.

The khio_obx is a placement .bgl for all the objects. My working folder is my actual scenery folder because at this point I am mostly replacing models. I use MCX extensively to swap individual models out of my library .bgls, like these lights or a building I neglected to texture, so I keep the paths close to my active scenery/texture folders. Sometimes I get a little messy while isolating things in folders and thanks for finding that placement .bgl, I kind of need it.
The other item, "2-20003.mdl," is a polygon representing a portion of runway 2-20. It's associated texture "_2_20.dds" is in the texture folder. You could use MCX or a placement tool to add it to a library .bgl, then use the placement tool to locate it within your own simulator to see the light absorption for yourself. These polygons were created using the Ground Polygon Wizard in ModelConverterX. Once they are compiled, I again use MCX to "rip" the models from the ground polygon .bgl, then I re-compile them into a library .bgl and use IS3 to place in sim. You could understand why I call them ground polygons.

Your solution, Don, is one of two and it means I will still have to develop an effective bi-directional effect driven light which would be about as unique as my frankensteinagon. The other solution is to give up these photographically accurate runways and use something more traditional.

 

[gadgets]

Now I know what's going on!

BGL_LIGHTS are FS8 technology. That they work at all in FSX is fortuitous. They don't work with P3Dv2.

In this case, for reasons know only to Microsoft, BGL Lights will not display against a background of this type of poly, i.e, the z-distances are ignored, priority is given to the poly.

I have observed something similar on a couple of occasions. I can fix it by adding a ZBIAS to the lights. But that solution only works in specific conditions because, then, the lights also show up even when they are behind an intervening object. That's OK for things like runway edge lights where there's unlikely to be an intervening object. But, for building obstruction lights, you see the lights through buildings. So, that solution is not suitable for a general purpose program like AFLT.

What I may be able to do is allow the user to selectively add ZBIAS. The trouble is, most users will have no idea what that is, so I need to be very careful how I do that. My other difficulty at the moment is that I'm preparing for an extended absence from my development system.

What I will do is, later today, send you a test version of the program that unconditionally adds ZBIAS to everything. This may introduce problems elsewhere but will confirm whether or not ZBIAS is a potential solution. If it does work, it likely would be the May timeframe before I could implement it with user control for specific objects. If you want to try that, please send me your e-mail address, either by posting it here or by e-mail to don at stuff4fs dot com.

Don

EDIT: The other thing you might try is not using Light-Only. The presence of the 3D model (which displays the light as an attachpoint) might fool FSX.

 

[=rk=]

I am pretty sure that the base models from my original picture in the ADE thread had attached lights and that is why I'd called attention to the light when the view angle superimposed it over the base. In other words, I placed a instance of the .bgl only light at an elevation of .29 meters and when the view panned to place the POV, base and light in line, the light showed over or on to, in front of maybe, the base.

Ok, I've sent an email; but, couldn't I, by that same reasoning, adjust the Z-bias of my polygon to conform to your (and everyone else's) lights? Without even using the ACES tools from within Gmax or 3DS Max< MCX has several Z-bias or Z related settings. Z-bias is default set to zero in a numerical field, there is Z-Test Alpha true or false, no Z-Write true or false and Z-Write Alpha true or false.

 

[gadgets]

I am pretty sure that the base models from my original picture in the ADE thread had attached lights and that is why I'd called attention to the light when the view angle superimposed it over the base. In other words, I placed a instance of the .bgl only light.

Rick, we've got to try and use the same terminology. Base Models are assigned automatically. If you check Light-Only, you get only the BGL_LIGHT, no base. If you check All In one, then you get a base file only that contains the BGL_LIGHT integrated into base model. If neither are checked (both are special purpose as described in the manual), you get two files - one for the base which contains an attachpoint and one for the light (illumination) which satisfies the attachpoint.

couldn't I, by that same reasoning, adjust the Z-bias of my polygon to conform to your (and everyone else's) lights?

Possibly, but I doubt it. The issue seems to be that FSX ignores the BGL_LIGHT z-distance when processing that ype of poly.

I'll send you a test file later today.

Don

 

[gadgets]

Your e-mail system would not accept the update as a zipped file.. So, I have posted it at http://stuff4fs.com/applications/AFLT/Downloads/aflt1002(b).zip.

Don

 

[=rk=]

Ok, got it, I'll test presently.

 

[=rk=]

I regretfully inform that the new lights behave as before..

 

[gadgets]

It was worth a try. It would appear FSX's multitude of transparency options seems to defeat BGL_LIGHTs. Have you tried using a standard ground poly as your runway? Others have, with excellent results.

Don

 

[=rk=]

Most ground polygons are textured with tiles in a repeating pattern, then layered with "dirt' to obscure the symmetry. These particular ground polygons are photographic, as if you took the photo .bgl and laid it on top of the FSX "cartoon" runway, but rendered at a much higher resolution. In my attempts with Gmax, which would probably produce an amenable Z-bias, I was unable to manipulate and render a single texture representing an entire runway to produce this kind of result:

Thank you so much for trying to make it work, though.

 

[=rk=]

Ok so, the Z-bias tweaked lights actually do work, so long as you have not edited scenery during the session. For my last couple times in FSX I had noticed a bi-directional light that must have been left over from testing; I would open Instant scenery to manipulate it, it would disappear and I'd forget about it, thinking I must have been mistaken, but this time I caught the little anomaly. Now I need to go hunt a few other instances of that light that mysteriously disappeared. It seems that the light is visible when you first call Instant Scenery, it is visible until you actually open or add to the scenery .bgl, then FSX must re-load the scenery. When that completes, the light is no longer visible and the only way to find it is if you put IS in delete mode and happen to set your cursor over the bounding box, which turns red. Pretty crazy that the visibility condition changes permanently after adjusting a scenery placement .bgl..

 

[gadgets]

I can't do anything about the idiosyncrasies of Instant Scenery. Why don't you invest a few minutes and create an array definition for AFLT - or place the lights with ADE - and try again.

Don

 

[=rk=]

Actually I am quite confident the lights will work, it is just the nuance of placing them and once I have a working plan or algorithm, it should be easy. As a test, I used the "stock" end or bi-directional lights as a place mark. I set the AFLT .bgl light exactly on the stock light, then made a line of objects through the other three, at their exact spacing interval (3m). I went back and forth three times, to get three instances of the .bgl light in the same place for each stock end light. Then, of course, I had to quit and restart FS so I could actually see the lights. As I raised and lowered my point of view, the action of the stock lights winking out was almost imperceptible behind the triple .bgl lights, which were bright but not overly so.

Now I just have to do the other end and the uni-directional green row and it should be excellent.