Potroh

Not easy to explain without proper pictures, but I do an attempt anyway... Look at these two screenshots: Max is set to 2048 on both pics. One shots depicts the a cloud of 2048x2048 and the other one is 512x512. I simply made colored blobs in place of the clouds, so one can see the scenario better. (As a cumulus01.bmp contains 16 different clouds, all are different in color in the bitmap I made.) This first one is the 2048x2048 texture. You can see that the clouds spread out finely back to the horizon and that their mipmaps are employed quite evenly. The render-engine tries to use as many variations from the same texture as possible. This is 512x512. You can see less clouds, less variation, and because the smaller mipmaps are way too small for the render-engine, they soon become transparent (due to the alpha content that being is similar for both texture sizes). One can also notice that on the clouds in the background there are no "variations" from the same texture, rather it tries to depict (draw) the higher mipmaps and then they face away, simply due to the lack of up-sampling in this case. So up-sampling happens or rather tries to happen, but sizes are too small for the purpose. Hope it's a bit clearer. Potroh

No, they will not always be up-sampled to the max value. The different AA methods do that but not according to the max value defined. (It would take just a couple of minutes or so to test the related difference if the "Application-controlled" and the "Enhance the application setting" or the "Overwrite any application setting" variables are selected in NI for AA would make any difference of how AA up-sampling reaches a max value in this case, but I've never tested that, so simply can't tell...) Potroh

Because they rightly suppose that a wise user will use the same texture size for both the clouds (runways, etc.) as per the max size defined in P3D or FSX. It's always the max value that counts, so in case the user has 2048 max texture size in P3D, then he should use 2048 cumulus coulds, which doesn't mean he can't have the cirrus clouds at a lower resolution, but never higher... Potroh

It's certainly dependent on the the AA type and level. The different AA types use different up-sampling methods, thus the final rendered size could be the result of a few down & up-samplings eventually. Max_texture_size will be the final one depicted. That's why the best is to use the texture-sizes as per the needed final and avoid the additional +- samplings as much as possible... Potroh

First the .dds is the Direct Draw Surface format that DirectX uses. The compressed .bmp is the exact same thing (regardless its header and if you can open them in different programs), they can be dxt-5. They are an inheritance from FS2004. You could make those dxt5 it was just FS9 that couldn't read them. One can read a lot of stuff on how textures are 'pumped' to the video-card, and what the shaders do there by 'clamping' the UV coordinates of the texture. There are two methods, 'sampling' or 'loading' a texture, etc. When there are no mipmaps (as in case of many "advanced" aircraft's external textures) no sampling is done and the full texture is loaded to the pipeline. (That is why un-mipmaped bitmaps - either aircraft or scenery related - can be a serious performance hog in FSX or P3D). When the textures are rightly mipmaped, a 512x512 dxt5 texture takes roughly 0.35 MBs of video memory, whereas a 4096x4096 takes 21 MBs. The 21 MB texture is getting loaded to the board, even if finally either a mipmapped or down-sampled version is displayed (rendered). So filling up the video-memory with 4096 textures is very easy. Upsampling? Usually three up-sampling methods are used: Multi-scale joint bilateral upsampling, accelerated joint bilateral filter and Detail aware texture optimization, but there are more. Whenever you use AA, MSAA, SSAA or SGSAA, etc. textures are getting up-sampled in the pipeline... If you restrict the max texture size defined in P3D, say you employ 1024 as max, but you still have some 4096 textures on the plane or scenery, they automatically get down-sampled to the max size, but ANY usage of the common anti-aliasing methods means up-sampling - at the same time. Potroh

With due respect Pete, I don't think you should compare Microsoft's, DoveTail's or LM's update policy to that of a a single-developer company. Large or larger companies need to be careful with updates, as all updates cost a lot of work for them - at or after the actual update - whereas a single developer (like yourself) can be much more flexible and actually quicker in development. If your own FSUIPC had only annual updates, I guess very few people would continue using it, if at all. If you optimistically looked ahead of an annual update in the fall, FSUIPC would be hardly P3D v2 compatible and users would avoid it as much as they could. I think the same stands for ProAtcX, it can go with its yearly updates and standing bugs, just as long as there's no serious competition. Whereas people can wish for changes or fixes in your forum and their wishes are usually fulfilled in two days, the ProATCX author does even appear in his own forum anymore and leaves the "dirty work" of defending company policy to the beta testers, which is a simple and transparent question of mentality only... Potroh

The logical "trick" is to always use the cloud-sizes EXACTLY the same as defined in P3D as the TEXTURE_MAX_LOAD=xxxx value. (If one uses 2048 as max texture size but has a lot of 4096 textures - either scenery or anything else - those bitmaps need to be down-sampled by the video-card at runtime). Soft-clouds are 512x512 in size so they need to be up-sampled if a higher max value is used. Whereas up-sampling (in some special cases) usually does not cause any performance hit, down-sampling a lot of bitmaps will definitely have its affect, as larger bitmaps take video-memory and good amounts of cycles for the sampling process. That's why it is the best to always stick with the same cloud sizes as the max texture size value being defined.

Try DXtory (http://exkode.com). It is far the best limiter available. It is not free but has a long trial period. Most "serious" gamers swear on it. It's mainly a video and screen grabber, so has neat other features too. One can configure its fps display wherever you want it on the screen and has different colors, transparency, etc.

Hi Rob, Although I've said my good-bye to you here, I write to you one last time. I guess you have read Adam Breed's words "...While this change was not exactly intentional ..." This is what I politely tried to tell you from the beginning. I think that after threatening to "cut me off" - here and elsewhere, and after all of your fuming "liar" sentences, you own me an apology. If you are the true general here, the true leader, you own me that much and to also those who did not really understood the delicacies of the problem, hence felt to be encouraged to continue bashing me and make fun of my humble and pragmatic sentences. A true leader is always strong enough to admit it if the battle was lost. I still admire your efforts towards the community, even if I sometimes do not agree with your points. I have no hard feelings towards you. I do hope it is mutual... Potroh

Well said. That's why I still have the feeling LM did not know that this change to their newer layering system will that badly affect the old one. Adam Breed posted this in the LM forum today: All, We are looking into the issue. We will provide more information shortly. Regards and thanks for the feedback, Adam This is a great news and at the same time it also shows that they were not necessarily aware of the almost global hit, so I happily accept Rob's apology... Many scenery designers would have already complied, the technical part is very easy, most of them had to chose between losing the seasons or having seasons with the old code. Those, who make their own dlls to circumvent the lack of applying conditions in the new LM code, are also aware, that each new dll for this purpose eats up VAS... I started this thread because nobody or just a very few were aware of the the global consequences - including the testers and perhaps LM itself. Potroh

The original statement mentions the SDK. So sceneries should strictly follow the SDK, whereas other products are allowed to use complementary methods? BTW, some of the products you name are only compatible with 3.3 after an update. Many sceneries will be updated too, but because of the huge quantity involved, it's a slightly different and much longer path...

Interesting statement. If PMDG, ASN, GSX, FS2Crew, A2A, ORBX, SODE and a dozen of other - innovative - companies followed JUST the FSX or P3D SDKs, you wouldn't have any of their products. Neither in the past nor today.

No Rob, I didn't miss what Beau said in their forum. What he said is perfectly understandable. Were you, as a tester, aware of this change? Were you aware of it's immediate abrogation to quite many scenery products? The answer is easy: no, you were not, just as usual you asked me to prove the existence of the problem. So if even you were not aware of the consequences, my stipulation saying that it may have been an unintentional change, and the change was not tested against older airports, is still valid. As many users expressed here and elsewhere, LM has been kind and straight forward enough towards the users on the road, so if they knew it will happen with 3.3, they would have definitely warned you, the testers and the users alike. Now that the problem is acknowledged by LM, you try to sail away from the pragmatic issue, mainly by personally attacking myself here. But I admit, this is your territory. If you are happier by not having frank and pragmatic, even speculative discussions on the topic, then let it be. good-bye Potroh

Come on Rob, yes you are a software engineer since WWII, as I'm a designer since WWI, but if I can politely ask you: don't try to teach me in scenery design please... If you know how it's done, yes, if there are five layers, then 5 numbers indeed need to be changed by five clicks. That's why I mentioned a simple "recompile" because writing a forum answer here definitely takes much more time that those 5 clicks + testing. No use to bring individual designers or companies into this discussion. All well versed designers know, that producing a P3D only version is no big deal. As far as the dropping support goes, first the FS2004 ASM compatibility was partially dropped and now the 2002 has followed. I would have understood it at 3.0 but at 3.3 it is a bit strange and doesn't sound as a well thought over decision. Too heavy consequences... It's evening for you in the US, so can't say you woke up with your left foot, so what happens with you? Who is accusing LM or Beau of anything???? Do you really think your moderator or tester status is equal to using the weight of your voice to take every word as an assault or attack, if other round sentences do not meet your expectations or do not match the agenda you try to represent? I understand that you dislike my opinion, but this is not the tone you should ever use as a moderator. You should respect differing opinions and mine have been expressed in a very polite and very pragmatic manner. Cutting me off??? Come on Rob, are you unable to bear this much of non-personal criticism towards a company decision which is not even yours? Potroh

I see Vic what is happening and I do not necessarily like it, until I also see the benefits. Right now (as a user, not as an old-timer developer) I see that my 400+ airports, carefully collected for my full cockpit, will become useless. I do like to go forward and use the polished updates from the first day. So far... But this change makes me stay with 3.2 which is not my actual choice but something being forced on me, in the form of a tiny change, which could have been done more carefully. Mind it please, it's not a major change, it doesn't AT ALL brakes the compatibility with the 2002-SDK stuff, it simply renders it useless. Why didn't LM remove the entire code-part? Because they did not intend to, as yet. They changed something ELSEWHERE and just accidentally turned out it makes a much worse change towards the old stuff. Yes, I understand the necessity to move forward, but this is not the way to do it. Of course the afterclap explanations will focus on the future, simply because something was not done carefully and not tested carefully. The average user will always take and digest the slogans and afterthought explanations aiming towards the glorious future, but myself being an old-time FS developer have seen more to be as innocent as that... So to answer your sentence, I do see what is happening but don't necessarily like it... The "little steps" concept is acceptable, understandable, but this one is anything but a little step. It's an unnecessary large move at the moment, which creates a huge gap and leaves admirable (scenery) corpses behind... It's not nice to talk about his/her future (reincarnation or resurrection) of the beloved one - in a farewell speech. Potroh

I guess nowadays you find no developer using the old code, apart from designing airports for FSX, where this is the ONLY method that works. If you can name a descent scenery that was published for P3D ONLY, I lift my hat in front of you... If you look around, nowadays each and every scenery is released for both platforms. So don't bash on the developers because they NEED to release for FSX too, so they NEED to use the old method. BTW, the old and the new methods are indentical, for P3D it just simply means to export or compile the very same thing with the P3D-SDK. Nobody really talked about developers using the old way NOW for new stuff, it was mentioned that the change renders many elderly, but rare or important sceneries useless in P3D. But: - the genuine layering method for P3D is unreliable. Working much worse than the old one used to - there will be no airport sceneries with SEASONS - there are NO possibilities based on conditional jumps, i.e there will be no safegate systems and the like

This is anything but getting rid of the old code. The old code is still there, still works, it just doesn't work as it used to. When nothing will appear in place of those 2D or 3D objects that became problematic or useless in 3.3, then the step towards a different future will be alive. At the moment we lost something but got nothing new in place of it - apart from promises that may see the limelight in a year or two. Until then this was an unnecessary change which should have been done only in a major release... Doing a small change in the code and by this move rendering hundreds of older sceneries useless, doesn't give anything positive to the user - right now. Of course we will probably see benefit in a later release, but mind it: in case the amputation is unavoidable, the entire leg should be carefully removed and not the toes - one by one... I still believe this was unintentional by LM. Now that they were informed about it, they realized it wouldn't be advisable to turn back. Sort of understandable. Had it been properly tested against the old code as well, an intermediate solution would have been very easy, and would have been a kind gesture towards those who collect airports which are not being updated anymore... Potroh

- The purpose of this thread (in this forum) is to warn those users who are willing to update immediately. They can do that of course (just as I did) but they need to face this specific problem, which renders 60-70% of their "airport-collections" almost useless. - With some 2.x version, the "rotating clouds" problem was so obvious that meant a no-go for many. I consider you being an admirable fighter defending your own truth and opinion, and I appreciate that, but I do hope you don't seriously and really want to start again an almost two years old debate... - Yes, the problem should have been checked by one of the dedicated beta testers (preferably a scenery designer) because by re-touching the layering code, there was a chance (as it's always the case with these types of tiny changes) that it may negatively influence airports based on the older code. As this small fix was NOT intended to render ALL those airports or code-type useless, and LM is aware that there thousands of users still using those airports (still being sold and advertised) so a simple look at compatibility would have been an easy and logical move. That's why I dared to mention the beta-cycle, because it was seemingly not tested. Thus it not an "accusation" towards beta-testers, specially not yourself, it is just a logical and general mention of the lack of thorough testing. - This part of the code changed when version 1.4 came out. Until then (and in FSX) layers could be numbered by any number (between 0 & 44), after the change only those numbers could be used, which were a power of 4. Designers modified their layers accordingly and in v. 3.0 it has changed back to the original numbering, once again. The core of the problem is (which can only be tested by a designer) that regardless the numbering of those layers, the problem always exists, although appears at different places if the numbers are changed. There is no solution to layer those, without getting one or two layers to disappear, depending on the reference-point of each of them. - There are many users out there, with these older sceneries, who did not notice the problem as yet, due to the fact that it is dependent on the aircraft's position, but sooner or later you will get more and more "reports" about the problem. - I think there's no use to specifically mention companies, but if you insist, I can do that: all Aerosoft sceneries (apart from the latest), all UK2000, all BluePrint, all FlyTampa, all Alphasim, all Cloud9, all EireSim, all LHSIM, all Flightbeam, all Flylogic, all FSAddon, all Japanese sceneries, all Imagesim, all Taxi2Gate, all TropicalSim - and a lot of other sceneries, should I go on? - You mention your own interpretation of the problem, which has little weight in my eyes, as you are not a scenery designer, did not see the problem, that's why you need "proof" before all. That proof is there, thousands of user see it or will see it, so there's little to debate about the very existence of the problem, which you rightfully channel towards the obsolesce of the elderly code type, but you need to understand that at this moment, at 3.3, it is most probably an unfortunate glitch by a single developer at LM, and not a step towards the glorious future. Edit: Simply forgot to mention an important thing. Namely that you mention "the 14 years old" factor, as if there were mentally retarded scenery designers, who for some unknown reason are reluctant to change their ways and stick to the 2002 method. It is definitely NOT the case, as we are actually NOT talking about anything else, but ALL AIRPORT sceneries made for FSX. In FSX there is no other method available. Neither in ESP nor in P3D 1.x So just to be precise, we should mention FSX airport methods, rather than living too high on the horse and belittle what is still the only way for FSX. Yes, P3D 2.x introduced a different and easy method, it works fine, but if you compare the very same airport with the two methods (which used to work fine until 3.3) the actual performance gain is noticeable, measurable, but marginal... Potroh

Well, yes good memories and I was the one who made the very first commercial scenery by Scam (brought out by Lago)... But Enrico has never really dealt with Scasm, his sole scenery venture (Schiratti Commander) had already used a different scenery compiler made by Maurizio Gavioli. Anyway I do agree with your comment, and LM needs to go forward, nevertheless it has nothing to do with this tiny bug which most probably unintentionally affected older sceneries. They will brake compatibility when 64 bit will be the immediate target, but not at 3.3 and not without telling anyone... Potroh

Sorry Rob but I personally will neither post videos nor screenshots about the problem. The reason is simple, it's already been mentioned by many people here, in the LM forum and elsewhere. There's no need to enter a "prove your assumptions" game - once again. Last time I participated in - an intellectually rather weak - debate like that, was back when the "rotating clouds" issue was new and came on the table. The scenario was similar, hundreds (if not thousands) of users experienced the problem, they wrote about it here and elsewhere, while yourself and some others of course tried to deny the existence of the problem, until it became obvious that it exists and LM did its best to solve it, and did that almost instantly. We also had been through the "attacking beta testers" thing with you here, alas, you seem to repeat that truly unnecessary notion of yours. Needless to mention that nobody has "ATTACKED" any beta-testers, and I myself simply mentioned my doubt by saying that "none of the beta testers could notice" this almost global problem with many airports, which is anything but an "attack" - even if you repeatedly seem to place a rather mildly expressed critical sentence like this into the "alert basket". Needless to say that a proper beta testing does NOT mean testing 40.000+ sceneries, perhaps three of them, five in the worst case, specially that it was known to the testers that something will be changed regarding the layering system. A good tester (with the help of the developers) in this case takes a few well known sceneries (even if made by older methods), and looks for potential problems. As simple as that. As I mentioned earlier, it simply should have been checked how the change affected the majority of sceneries out there, regardless the method they were made by. Of course this is valid only if LM did not intentionally want to brake compatibility by the small fix, which I seriously doubt they wished to accomplish. But with your contradictious ex cathedra comments about the move towards the future, you try to paint the picture as if the change was intentional by LM, which IMHO was definitely not. They are wise enough to at least notify or warn the majority of users about a drastic change like that, braking compatibility with hundreds of airport sceneries, regardless the if old methods were being used. Potroh

Vic, Glad to hear that! Potroh

Vic, You are right, not too many commercial users would care. But still there are quite a few out there. In my small country there are at least half a dozen of those, who use full cockpits and train pilots, so they do care, because their "base or home airport" suddenly becomes unusable and that means a lot to their daily routines. It's not as simple as asking the company or another developer to do another "Mega Airport Scenery" for them during the weekend... Some of those commercial users do "airport familiarization" courses at a given airport, where the default scenery wouldn't serve the purpose. But even more importantly: just browse through the fixes that have been made - say just for the 3.x series so far, and we can see that regardless the continued higher priority of SimDirector, many small bugs were dealt with, typically important for the non-commercial user only. So we can't really complain, though LM prioritizes the military oriented stuff, but actually cares for general aviation a lot. And BTW, these are not necessarily "old" sceneries. Not at all. Sceneries that were compatible with both FS versions and the company didn't force the developer to make a separate P3D version, simply because one bgl version was compatible with both... Potroh

Would be true and wise words (though a bit ex cathedra), but this is not the case with this present problem. This is definitely not a "step" towards some glorious future change, it is simply a bug, a modification in the layering-system, that was not tested against compatibility. The "some add-ons" in this case means ALL that have not specifically made for P3D with the P3D tools. It is surely not intentional, or a diamond to be collected on the path to the shiny future - hence no use for the pathetic approach, this time we aren't talking about 64 bits here. The devs - as you put it - can rarely do anything about it, because we are talking about sceneries that are years old. Their fixing, re-compilation and porting them to the different platform is not just a matter of will and careful development, but often it wouldn't be possible due to the other logistical factors. Mentioning those "guidelines" are perfectly valid for new sceneries and other stuff too, but right now we are talking about a simple bug, that I'm 99% certain was a glitch and nothing but UNINTENTIONAL. If it was intentional, the entire 2002SDK part would have been removed (with a proper warning), but it wasn't. Potroh

No need to test all major add-ons in a case like that. Simply a few of them and it should have become obvious that the problem was global or general. Simply because there was an announced change into the Z-bias method, it should have been checked how the change affected the majority of sceneries out there. Potroh

If it's done that way, it is wrongly done. LM's lead developers has expressed several times in different interviews how much they try to keep compatibility as long as possible. If the beta phase were done thoroughly, there should be at least one or two testers, who look for problems like this one. As it is not an intentional move to remove the 2002-SDK methods, it's just a glitch, I'm certain they will find a very simple and easy way to fix it. Nope. They've dropped the FS2004 SDK's conditional jumps and not the even older ground-layering. Potroh