hjwalter

Roger,

I tried what you suggested, in VC mode with a zoom of 0.5 or less and the objects concerned do seem the pop up/disappear at greater distances but this does tend to make the whole external scenery look too far away and therefore less realistic. The same also applies when in 2D mode with the same negative zoom levels. Moreover, this is not the structural solution, if there is one, I was really looking for.

Thanks anyway for your suggestion and I will certainly keep it in mind.

Hans

Hi Guys,

Thanks for all your reactions.

I opened an example texture of one of my far too close pop-up scenery objects via the program "DXTbmp" and all looked well. The size of this particular texture without mips was 129 Kb and with mips, 171 Kb. Via the "Preview" ---> DXT1 dropdown menu I was then able to see a series of 8 mipped sub-textures, ranging from the top very detailed one, right down to the last almost invisible "pin-point" one. All very normal and technically correct.

The only conclusion I can now come come up with is that the problem lies somewhere within it's XML based model (MDL) file, which calls for and processes this correctly mipped texture. However, to be able to search for and possibly fix such a problem, I would first need to be able to disassemble MDL files into something legible and also to afterwards be able to re-compile them back to their MDL files.

Can any of you experts please advise me on this, e.g. which program(s) I would be needing ?

Regards

Hans

After a few hours of testing with XML based library objects randomly placed/positioned in one of my addon airport sceneries via the Abacus EZ program, it has turned out that the phyisical size of the objects do not make any difference. The normal sized objects and the (test) huge ones next to them, both appear and disappear at the same far too close and unrealistic distances from my taxiing or low flying aircraft.

The textures concerned were originally DXT1 but changing them to DXT3 (= larger) made no difference either.

Further ideas anyone ?

Regards

Hans

Thanks for your reply David and your theory is certainly new for me. I'm now going to do some testing and will post my findings in this thread.

However, I must also point out beforehand that I cannot really imagine that something like this could be a structural problem of FS9 itself but as you point out, it certainly does concern small addon scenery objects only but definitely not all of them, hence me suspecting the different developer programming styles within their SCASM based BGL files.

Thanks again.

Hans

Hi Guys,

In quite some of my addon airport sceneries the amongst others, (apron) objects, e.g. busses, tractors, passenger stairs, etc, only pop up and become visible at very short distances, e.g. while taxiing and/or approaching my (via ATC) assigned parking position. These distances are very variable and only seem and I repeat the word "seem", to be caused by BGL files made via the SCASM program. Disassembling such SCASM BGL files into their SCA versions is no problem nor are finding the texture files being called for but finding anything to do with possible pop-up distances within these SCA files, remains my big problem. However, I'm certainly no expert at this and need some help.

The texture files concerned are all DXT3 or DXT1, are mipped and have alpha channels.

Does anyone know where I should begin looking ?

Thanks in advance for any suggestions.

Hans

After many hours of trial and error testing there was only one option left and that was to flatten the Hierro (GCHI) afld elevation down to sea level.

Not very accurate in terms of the local real life situation but I felt that a total deletion would be just too drastic for this overall beautiful island VFR scenery. However, this only solved the coastal "water walls" at both ends of the airfield but not for the rest of the island. However, I can (learn to) live with that, at least for the time being.

The "reef" problem was solved by re-downloading/re-installing the complete CanarySim package. Problem was evidently caused by a missing file somewhere.

Thanks for all your reactions.

Hans

Greg,

Thanks for your suggestion. I'll certainly look into it tomorow first thing.

However, it must also be said that the other islands in the CanarySim archipelago, all with steep cliffs in some places, do not seem to have the water wall problem.

The big question then remains: What could the other islands have what the Hierro island dosn't seem to have, or vica versa ?

In the meantime I've also noticed that one of the other islands, Fuerteventura, has what look like offshore reefs (with ocean waves breaking on them) at varying distances from the visible land edges. These are quite obviously the correct shorelines but which seem to somehow be missing the visible coastal land reaching up to them.

In the meantime I will certainly download the CanarySim scenery again, if only to see if it contains any specific installation instructions.

Thanks again.

Hans

Roger,

I'll send you some screen shots and more technical details tomorrow but I already have the feeling that there's a structural problem at play here, a problem which cannot easily be solved, except of cause to flatten the whole island and the sea around it, to zero feet !! However, in that case deleting the island and all it's "to and from" flight plans, would then be a better but sad option.

Anyway, I'll first await your reactions to my screen shots, etc.

Regards and stay safe.

Hans

Hi Guys,

Now that we are in a corona lockdown anyway, it's become a good time to take another look at some of my older sceneries and one of those is the Hierro airfield (GCHI) on the Hierro island, which is part of the very well made Canary Island archipel, made by CanarySim quite some years ago.

The (Scasm) airfield itself is also very well made but it has a "thorn in the eye" problem with sea water climbing up the island's cliffs, not only on the sea side of the airfield at 105 feet elevation but also everywhere around the island and mostly where cliffs meet the sea. This visible anomaly, especially around the airfield itself, is so great that even trying to somehow mask it, e.g. with Abacus EZ or RWY12 scenery objects, becomes impossible.

It's most probably some kind of conflict between mesh and LC scenery, which seems especially bad because the island has a very jagged coastline. Small flattens at zero feet to remove the water walls on the sea side of the airfield do in fact work but these do not remove the water texture on the thus produced new cliff side(s).

Ideas or solutions anyone ?

Thanks in advance.

Hans

mrzippy,

Thanks.

Hans

Can you please supply a file name for "Nicks Lights Vol 2" because I cannot find it via the name you have supplied.

Thanks in advance.

Hans

Scott,

I've sent you a private message about the Halo.bmp file problem.

Hans

Thanks again Greg for your above and second expert explanation.

I went to one of my "white blotch" airports, now fully armed with my newly aquired knowledge and saw that it was in fact one of these very detailed addon ones. As now expected it had high resolution ground/apron/runway textures on top of a flattened airport terrain. Same for my next addon airport, etc.

Testing by temporarily de-activating the BGLs which call for these textures did in fact work ...... BUT ...... at the same time I also discovered that I really prefer the distant very short white blotches to the complete absence of the detailed ground textures, e.g. when on or very close to these normally very well made airports.

Masking with, e.g. trees, bushes, shrubs, etc now seems a more viable option, at least for me and especially because it was only a trivial problem to begin with. Nontheless, a very interesting subject and I learnt a lot from it.

Thanks again guys and stay safely at home.

Hans

Greg,

Your very logical (bottleneck) explanation has shot holes in my incorrect idea that such distant white ground blotches were caused by BGL calls for custom textures of which the last and least detailed mips were somehow still too far out of range to immediately be loaded/displayed. I had also assumed that while the custom ground textures were "waiting" to be loaded/displayed, the default ground polygons would pre-display instead of the white blotches.

Anyway, thanks for your lesson but now another question emerges: Is it possible, after the "processing bottleneck" has cleared itself, that the speed at which such distant ground textures are then loaded/displayed, is somehow related to their sizes ? E.g. will 43Kb DXT1 textures always load faster than the larger DXT3 or higher detailed ones ?

The reason I ask is that, e.g. mipped land class texture tiles in other areas, which all seem to be DXT1 of 43Kb, in fact never cause any temporarilly untextured blotches to appear in the distance.

Regards to all and thanks for your reactions.

Hans

Hey there Tom,

Quote: "But you cannot control when they switch".

Surely, when any third party scenery developer creates, e.g. any airport texture, then in my mind he/she just must use some kind of software process for creating the possibly standard number of mips for any such texture. These should then normally all be "switched" at fixed distances, possibly being controlled by a set FS9.cfg entry and/or even a FSUIPC one.

However, if this "distance switching" process is somehow controlled by individual developer's scenery BGL files, which have called for the mipped texture(s) concerned, then yes, the possibility exists that the "distance switching" process will never be or become a fixed entity.

Oh well, I will agree with you all that my initially posted problem is definately not a serious one but nevertheless very interesting, while on the other end of the stick, suddenly popping up Abacus EZ-scenery objects at very short distances, certainly is another one.

Comments are welcome and in the meantime, stay healthy.

Hans

Roger,

I agree with your explanation completely but I think you are referring more to the causes of an effect called ground texture "shimmering", than to a possible mipped texture problem.

Please correct me if I'm wrong but a theoretical possibility in my mind is that, e.g. the least detailed (mipped) versions of any addon airport's ground and other textures are rendered first when you are still relatively far form actually landing at that airport. As you get closer the the next more detailed texture versions are rendered and so on, until the most detailed versions are finally rendered just before landing. It's in fact a frame rate enhancing technique, which also makes life for graphics cards just that little easier.

Now my more detailed questions:

Are mipped textures ALWAYS mipped in exactly the same way with the same number of mipped versions per each texture ?

Could it be that the least detailed versions of these airport textures are blank ? Is there a way of checking/editing any texture's mipped versions, other than such textures simply being mipped or not ?

Or is it as dougu66 above says, that I just need to learn to live with this (rather trivial) problem ?

Regards.

Hans

Hi Guys,

When approaching some of my airports in clear weather, a white blotch suddenly appears on the ground in the distance and which then very unrealistically, gets filled with the related textures as one gets closer.

The most obvious way of decreasing this problem is to mask it as much as possible by decreasing the visual distance via e.g. weather, but is there any structural way of increasing the distance at which these still untextured airports appear ? E.g. in the FS9.cfg file ?

Could this problem somehow be texture mipmap related ?

Looking forward to any reactions/solutions.

Hans

O.K. guys, I've found the culprit.

The horrible looking Mooney tail light is/was caused by a texture file by the name of: "Halo.bmp" and can be found in the main FS9 texture folder.

After quite some hours of trial and error testing by deleting/restoring large groups of main FS9 texture files with testing in between, suddenly the Mooney's tail light was no longer there. This rather quickly led to the above mentioned texture file as being the culprit.

I replaced it by a very old and very different version from one of my old backups and PRESTO. Problem solved !!

The tail light is still there but it now at least looks very much more realistic.

The problem was caused by my quite recently downloaded and installed new halo lighting effects, which in fact did look quite good here and there but which evidently also had some negative side effects of which this was one of them.

I hope this helps anyone else with the same problem(s).

Happy landings.

Hans

Hey there Tom,

That's strange. My default Mooney's tail light is also very bright, white and large, completely different to the correct looking one in your screen pic. Not only that but my Mooney has no landing lights, like your's does seem to have, either.

If I temporarily de-activate all lights in my Mooney's aircraft.cfg's [Lights] section, the white tail light remains unchanged and can only be switched on/off via my keyboard "L" key and via my third party cockpit "Nav-lights" switch.

You are therefore correct in saying that this light is selected/positioned by the Mooney's model file, is not part of the aircraft.cfg [Lights] section and can therfore not be directly edited. Great pity.

However, I've been testing some other of my (addon and default) aircraft and it now seems that with quite some of them, different selections of their lights are also part of their model files but these at least all look and work normally.

Going back to the Mooney, the only thing I can now think of is that it's horrible looking tail light texture has at some time in the past automatically been edited or somehow redirected to another lights texture, most likely by an automatic installer program for another aircraft.

Can you think of any way of finding the offending lights texture itself because I must now hope that it's no longer one of those contained in the standard fx_2.bmp lights texture. However, if all fails then the only possibility as I see it now, will be to replace the Mooney's model file by the one from one of the installation CDs.

Regards

Hans

Whats wrong with your ailerons ? Is your plane unsteerable ? Yolk or stick problem maybe ? Do any other of your planes have the same problem ?

More information is needed so that I/we can help you. Your downloaded file name would be helpful as well, so that I/we can try it ourselves.

Regards

Hans

If you have installed into the default folders, which is very easy to do, you run the risk of all kinds of unpredictable problems caused by Windows security processes and your specific problem could be one of the many possibilities.

If you have in fact installed into the default folders I would want to suggest that you uninstall completely, remove any residual files/folders and then to re-install but this time into so called "custom" folders, preferrably in a partition outside that in which you Windows lives.

If you have already done that, then please supply more information as James has already asked.

Regards

Hans

Hey there Tom,

Join the SBuilder frustration club !! You can count on my vote for you to become it's first chairman !! LOL.

However, it must also be said that Roger's latest suggestion does seem to work but not in all cases and especially not where coastlines are in close proximity. These seem to have the same adverse effects on polygon edges as roads.

But anyhow, I've now created correct grassy backgrounds for six of my older addon airports/airfields but these have then created even more "problems", in that they were then just asking to be enhanced and improved even more !! Yep, SBuilder is indirectly addictive as well !! LOL.

Regards and stay healthy.

Hans

I've had this same issue a few years back on my Waikato carrier and in the end it turned out to be that the relatively small 3D geographically positioned catapult sensitive deck area (Cat zone as you call it) had somehow (been) moved.

In my Carrier Operations (COPS by Rob Barendregt) system, it remains necessary to get the nose wheel exactly in this small catapult area and only then will you get catapulted off the deck when you release the brakes.

My trapping area was also influenced but because this is much larger than the catapult sensitive area, this was not immediately noticed.

The whole problem (and many others) was caused by a "magnetic North deviation update" which I had found somewhere and had installed. Needless to say but I reverted back to the original file rather pronto.

Could something like this also be your problem ?

Good luck.

Hans

Hi there Roger,

Yes, SBuilder does have quite some strange "ifs and buts", not only in it's relations between default roads and polygons but also with LC scenery, most probably because LC scenery normally exists as a scenery layer "on top of" any SBuilder polygon(s) and which then need non_SBuilder solutions.

A fine example of conflicts between polygons and default roads is on one of my addon Greek airports, which has a default looking (maintenance) road running all around it's perimiter.

A (grass) SBuilder polygon background was also necessary here, so I made a nice big (test) one covering the whole airport and with a wide margin all along the outside of this road. The result was a correct polygon background but also a non-polygon covered margin on both sides of the road all around the airport !!

I then made a new polygon with the road itself as it's borders but even then the polygon edges kept their distance from the road all around.

My end solution in this specific case was to draw an Afcad (or ADE) road on top of the default one and to then mask the void between that and the polygon edges with shrubs, fences, etc. Problem solved.

And then, on to my next problem airport.

My initial "road problem" with which I began this thread is now also solved by covering the area concerned with forests and other objects.

However, thanks again for another of your "nudges" in the correct direction and I will certainly try this one during my now ongoing general check of all my 600+ addon airport backgrounds and especially on the older ones, where the background problems are most prevelent. The covid19 scare is keeping me inside and off the streets anyway.

Thanks again.

Hans

Roger,

No apologies necessary Roger because your instructions successfully got me going on my illusive road, which for me was now no longer a scenery issue but far more an SBuilder "find out how to" issue. Moreover, after your "nudge" and help I now at least know some basics around how this SBuilder program works, what it's limitations are and last but not least, what the differences are between "paintable" addon scenery ground tiles and the default autogen ones.

Out of pure inquisitiveness, combined with covid19 boredom, I've now dived back into SBuilder again and have successfully used my new polygon "know how" for creating missing grassy terrains on two of my addon airports.

Roads ? Huh. Who needs roads !!

Regards and thanks again for your help.

Hans

Netherlands