hjwalter Posted December 2, 2020 Share Posted December 2, 2020 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 Link to comment Share on other sites More sharing options...
douga66 Posted December 2, 2020 Share Posted December 2, 2020 I have always gotten that for add-on airports, especially those with custom ground textures since using FS9. I just accepted it as "oh well got to live with it". I would definitely be interested to see if somebody has a solution for this one. To view my repaints and other stuff just click on the image below! [sIGPIC][/sIGPIC] Link to comment Share on other sites More sharing options...
Roger Wensley Posted December 3, 2020 Share Posted December 3, 2020 Custom ground textures are something that I avoid, for several reasons. The usual reason for showing badly is that they were created at a level too close to the ground underneath, which then confuses FS9 as to which scenery it is supposed to be showing. If the textures form a part of the airport where planes will taxi or park there is a great temptation to get them as close to the ground as possible as otherwise taxiing planes will look like they have flat tyres. SBuilder is the preferred programme for ground textures as it alters the existing texture instead of creating a second texture on top of the existing. Link to comment Share on other sites More sharing options...
tgibson_new Posted December 3, 2020 Share Posted December 3, 2020 Actually ground polygons are especially created to take priority over the normal ground polygons and thus do not have the flashing problem, even if they are exactly the same elevation as the ground. I have never seen a flashing issue unless the ground wasn't properly flattened at the correct elevation (which is critical). Tom Gibson CalClassic Propliner Page: http://www.calclassic.com Link to comment Share on other sites More sharing options...
hjwalter Posted December 3, 2020 Author Share Posted December 3, 2020 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 Link to comment Share on other sites More sharing options...
tgibson_new Posted December 4, 2020 Share Posted December 4, 2020 The white area is the untextured surface, I believe. Thus no mipmapping technique will help. But the answer is yes you can edit mipmaps. But you cannot control when they switch. Tom Gibson CalClassic Propliner Page: http://www.calclassic.com Link to comment Share on other sites More sharing options...
hjwalter Posted December 4, 2020 Author Share Posted December 4, 2020 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 Link to comment Share on other sites More sharing options...
gaputz Posted December 5, 2020 Share Posted December 5, 2020 I don't think the issue has anything to do with mipmapping. I suspect what you are seeing is a long load time for the ground poly textures. The textures eventually appear once your computer has cleared itself of a processing bottleneck. I know from extensive testing of my scenery that testers with older computers typically experienced untextured ground poly tiles when the sim began loading all the scenery objects. The more detailed the airport, the more likely this will happen especially on older machines with less capable CPU and graphic processors. All of the objects in my scenery are modelled with three or more LODs, or distance conditioned, and all the textures are mipped. That helps a lot with framerates but at some point the sim still has to load all those models and textures into memory so they are available when a draw call comes. That is the point when a detailed scenery puts the most strain on a computer, which coincidentally is usually about the same point the ground poly tiles first appear. If you look at the release notes of my CYWG scenery you will find a performance report of the results of all my beta testers. The testers with Core 2 Duo invariably got a texture lag on the ground poly tiles while the testers with the latest Intel CPU and GeForce graphic cards did not. That of course makes sense because the newer computers had ample processing power. And, all this is compounded by the amount of AI traffic and weather. I stand to be corrected but what I have just described has been my experience with scenery design. Greg Link to comment Share on other sites More sharing options...
hjwalter Posted December 6, 2020 Author Share Posted December 6, 2020 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 Link to comment Share on other sites More sharing options...
gaputz Posted December 7, 2020 Share Posted December 7, 2020 Hans, perhaps an explanation of the two types of photoreal terrain textures is necessary. The answer to your question depends on the type of aerial or satellite imagery applied over the default FS2004 terrain. If the imagery is applied over the default mesh using the FS2004 custom terrain textures SDK but you are limited the low resolution of the default textures (256 X 256). The advantage is that these textures follow the contours of the landscape. The problem is that at low altitudes the ground looks mushy and blurred. You should never have a texture lag problem with these textures. No need to change anything there. As you rightly point out, you never see untextured blotches on this type of terrain textures. These textures are easily identified because they must follow a FS2004 naming protocol (e.g. 000312232100200Su). Some developers place these in the Scenery/World/Texture folder and others in the airport’s Addon Scenery folder. Your problem is with textured polygons placed directly on the default terrain – normally referenced as a ground poly. These are the ones that have to be placed on a flatten because they will not follow the contours of the landscape. That limits their usefulness in FS2004 but the benefit is you can use a texture with a much higher resolution, the maximum being 1024 X 1024. This method is typically used for the area of the airport proper and maybe the approaches, where you’d like to see more resolution when you closer to the ground. If the area is large the developer probably used a great number of these higher resolution 1024 X 1024 tiles. For a detailed large airport, the size of the ground poly and the number of objects that must be rendered can put quite a strain on your computer’s processers (as explained in my previous post). First thing I’d do change any texture that does not need to be DXT3 to DXT1. There is absolutely no need to use DXT3 unless you have a transparency designed to blend into the background. I’d say that is rare in a ground poly, and when used is on the outer ring of tiles to avoid a sharp demarcation with the underlaying default ground. You could reduce the size of those terrain tile textures but then you would defeat the purpose of having the tiles in the first place. You might get away with converting the textures to 512 X 512 and still have acceptable resolution, especially if the developer also has an overlay applied (for grass maybe). If you are like my good friend Roger, and couldn’t give a hoot about photoreal ground textures, you could reduce to 256 X 256 or even lower. I’d say eliminate the ground poly altogether but the developer most likely used it as the basis for laying other features of the airport. Hopefully this explanation is of some assistance. Link to comment Share on other sites More sharing options...
Dedl Posted December 7, 2020 Share Posted December 7, 2020 Thank you Greg for sharing your knowledge... Dedl Link to comment Share on other sites More sharing options...
hjwalter Posted December 7, 2020 Author Share Posted December 7, 2020 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 Link to comment Share on other sites More sharing options...
Roger Wensley Posted December 9, 2020 Share Posted December 9, 2020 And thus ended the lesson. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now