LAGO Honolulu updated

[Guest]

I did not add this message to the 100+ message thread we were working on a while ago:-)But I just updated version 1.10 that solved the unwanted hill under the helipad on the terminal. We had to work around the problem a bit but it should be fine now.The issue with the transparency of the waving palm trees is slightly more complex. In Gmax there is only one way to call a texture, there are no alternatives for the way we do it on an object like this. But Gmax wants it's textures to be in the DirecX compressed format where the tranparency is in a seperate Alpha channel. If the texture is NOT in this format you will have problems. Now we call a standard FS2002 texture that is in the correct texture. But we have found some addon texture sets that are NOT in this format but in the older, less complex formats. With Gmax scenery this will undoubtfully lead to problems. So if you have the problems, check there first.You can find the file on our website of course. The full download version is also updated to 1.10 and does not need to be patched.Mathijs KokLAGO

[Guest HeavyFan]

GREAT news LAGO!! GLad to hear you fixed the Hill Problem!! Now I can really enjoy my Home Airport!! keep up the great work Guy's!! MIKE-:) -:)

[Guest]

MathijsI still have the tree problem. I have tried everything. I had lennart textures and went back to the default. I have tried every fs2002 internal scenery slider,option etc. I have removed aniso and that had no impact. Any suggestions?Asus p4t 1.9 512mbVisiontek ti4600 - 5 different video drivers testedRegardsBob G

[Guest]

>I still have the tree problem. I have tried everything. I >had lennart textures and went back to the default. I have >tried every fs2002 internal scenery slider,option etc. I >have removed aniso and that had no impact. Any suggestions? Like the readme says, we did nothing on that problem because there IS nothing to fix there. Gmax simply has no options in calling textures. Still I am rather sure the problem wil not be there on a clean install of FS2002 on your machine.I did a clean install on a machine that has the same graphics card as you have and did not see the problem. So there must be some third party file that cause the problem. I will try to find out what files are involved so we can compare them.Mathijs

[Guest GerrishGray]

The tree problem is caused by using some of the alternative Autogen Tree sets available on the internet incorrectly formatted as DXT3 bitmaps instead of DXT1. The mistake doesn't show on the Autogen trees because the special Autogen code cannot display the partial transparency of a DXT3 anyway and treats it as full transparency like a DXT1. But when Lago use these textures in their scenery, the mistake shows up.Not all of the Autogen Tree textures available on the internet have this problem - my own sets, for example, use the correct DXT1 format.Apart from reverting to the appalling FS default tree textures as Mathijs suggests (even MS themselves have issued a replacement - see my MSTrees.zip download), there are two other cures available for the problem (as already published in another thread)[ol][li]Instead of accessing the default Autogen trees texture sheets direct, Lago could simply use a version/copy of their own with a different name. Many third party scenery designers have already done this. Incidentally, Mathijs, you are wrong in thinking that the approach you use at present is more memory-efficient: the normal scenery engine is unaware that the separate Autogen code already has these textures open, and opens another copy for itself anyway![/li][li]In the meantime, before Lago get around to fix 1, users can just place a copy of the default textures in the local ..texture folder of the Honolulu scenery, leaving their preferred replacement Autogen tree textures where they are in the main texture folder. The Honolulu scenery will then use the local copy of the textures in preference (see last part of fix 1 for technical expanation of why this works successfully).[/li][/ol]Kind RegardsGerrish

[Guest]

Bob,>Any suggestions? the file involved is treessu.bmp, in the main texture dir of FS2002. This is an original MS file, we simply call it.To check if it's the correct one, you can try open it with imagetool.exe that comes with FS ( Pro only ), or if you have the Std version, you can find it in the scenery SDK recently released.Check the window on the right with infos, it must read :Size 174760Width 512Height 512Format DXT1 ( very important )Alpha Colorkey ( very important )if you see something else, then it was modified by some other scenery, and it's the wrong format, that would not work with Gmax stuff.To get the original one without reinstall FS, you could extract it from FS CD1, inside the FS2002.CAB file. Winzip or Winrar should be able to open the archive.regards,

[B777ER 2,484]

Great work Mathijs. I did like you asked and sent an email to that other guy in your company asking about getting a support forum here at Avsim. His response was..we are evaluating and discussing that subject for now. So anyways's, can you give us a hint as to what will follow the fantastic PHNL? Also on a side note, I noticed in some screen shots of FSSE that the planes are shall we say, boxy looking. Almost like FS95/FS98 type planes. Before buying it I would like to know if there is a way to use FS2000 or 2002 type planes? Can we use GMAX planes that are very frame rate friendly like the king we use for AI aircraft? Thanks Mathijs. You guys rock!

[Guest]

Gerrish,>Incidentally, Mathijs, you are wrong in thinking that the >approach you use at present is more memory-efficient: the >normal scenery engine is unaware that the separate Autogen >code already has these textures open, and opens another copy >for itself anyway!Are you sure about this ? Because, even if the actual file opening process may happen twice, there could be a final optimization stage in FS that prevents the same texture to be uploaded more than once on the graphic card, in order to save VRAM and bandwidth. So, even if we could have two copies of the same file in main memory, only one will cross the bus and will be stored on VRAM. I'm not sure about this, but it would make sense as an optimization.regards,

[Guest GerrishGray]

Hi UmbertoThanks for the reply. I can confirm, from testing various examples in different circumstances, that FS treats a 'local' copy of a texture file as a separate file to a similarly-named file already loaded from the main texture folder - and hence fix 2 works.Whether the same holds true for textures accessed from the main texture folder by both Autogen and the main scenery engine is more difficult to test. However, Autogen clearly handles and renders its texture sheets differently from the main engine, as demonstrated both[ol][li]by the problem with the Honolulu palm trees[/l][li]and by the simpler shading of the Autogen trees to 'hand made' trees using the same texture, whatever format bitmap is used[/li][/ol]You could be correct about your optimisation process, but somehow it seems a bit unlikely that MS would have bothered with this just for the benefit of the fairly unusual circumstance of third party scenery wanting to access an Autogen texture sheet ... Frankly, I doubt that the idea would even have occured to them, but who knows, you could be right!What really matters here is fixing the problem, which is rather easy to do and is unlikely to make any significant difference to the performance of the superb and imaginative scenery. The claim made in the press release that the fix is beyond Lago's control is simply incorrect - and, if you don't mind me saying so, to do a "Teflon shoulders" job and try to shift the blame onto third party designers falls somewhat below Lago's usual standards of excellence and first-class support.Kind RegardsGerrish-------------------------------------P.S. There are two separate issues as well about the true cause of the problem:[ol][li]The press release is wrong in claiming that the problem textures are plain bitmaps - they are actually in DXT3 format (unnecessarily) and ought to work correctly - they appear to have a correct alpha channel that should produce full transparency of the background. From what I can see, the only significant factor is the use of a non-black background colour. It seems that the non-black background is producing less than 100% transparency, despite the 'Alpha' flag being correctly (?) set to Alpha rather than Colorkey. Do you know enough about the DXT formats to be able to throw any light on this? I thank you in anticipation of any extra information you can provide, or even point me towards![/li][li]The reference to gMax is also rather spurious: gMax is just a design tool that produces some code for compliation into a BGL file. If there is a problem with the rendering of the different format bitmaps, it probably lies either in a bug within the makemdl.exe interface provided by MS (which can be checked by examining the assembler code produced), or within FS itself.[/li][/ol]-------------------------------------

[Guest]

Gerrish,>I can confirm, from testing various examples in different >circumstances, that FS treats a 'local' copy of a texture >file as a separate file to a similarly-named file already >loaded from the main texture folder - and hence fix 2 works.I didn't object this. I was saying a different thing: it will not probably load twice a stock texture in the main texture folder.>seems a bit unlikely that MS would have bothered with this >just for the benefit of the fairly unusual circumstance of >third party scenery wanting to access an Autogen texture >sheet ... It's not a special case of Autogen! It's a general case for the main texture directory, take some stock texture like the runway ones, for example. If many sceneries are active, and all contains at least one runway, if this optimization were not in place, FS would have to load the same runwayxx.bmp several times for every scenery active. I doubt it. What's the difference with the trees ?The most probable hypothesis it's that only the texture in the main texture folder are optimized, for the simple fact they are accessible from every scenery. Because of this, a scenery that calls a stock texture, *is* saving memory comparing to using a local copy. How much, it's difficult to measure, but the trees are not the only stock texture HNL it's using, there are many others, like all those for the vehicles, for example.>The claim made in the press release that the fix is >beyond Lago's control is simply incorrect - and, if you >don't mind me saying so, to do a "Teflon shoulders" job and >try to shift the blame onto third party designers falls >somewhat below Lago's usual standards of excellence and >first-class support. It could be explained differently, but I think the blame is put where it belongs. The fact is, some add-on is replacing a stock texture without caring to at least respect the original file format.Hence the problem. If we did that, we'd probably got the blame, right ?However, this do not necessarily mean we have no intention to fix it, it depends mainly on how many people are using this replacement textures and ask for the fix.The easiest solution for a user that wants to keep the replacement textures for the autogen, and fix the palm tress at PHNL, would simply take the original MS texture from the cabinet file in CD1, and put it into the Honolulu texture folder.best regards,

[Guest GerrishGray]

Hi Umberto>It's not a special case of Autogen! It's a general case for >the main texture directory, take some stock texture like the >runway ones, for example. If many sceneries are active, and >all contains at least one runway, if this optimization were >not in place, FS would have to load the same runwayxx.bmp >several times for every scenery active. I doubt it. What's >the difference with the trees ? >I'm sorry, but it is a special case for Autogen, that's the whole point! The only scenery that will normally have opened the Autogen tree texture sheets before your Honolulu scenery does is the Autogen code, and that appears to handle its textures differently and separately to BGL stuff. The other stock textures that you refer to are used by 'stock' BGL code and are a totally different case.I regret that you are also wrong when you say that the stock textures have been replaced "without caring to at least respect the original file format". I will grant you that if the authors had used exactly the same format as the originals (DXT1 Alpha), the problem wouldn't have arisen. But within the limit of anyone's knowledge up until now, DXT3 with a correct alpha channel should have worked correctly. DXT3 was probably chosen because of problems with the nVidia code for creating mips for DXT1 with Alpha, and the choice of a non-black background in the main images (NOT the alpha channel!) is a well-known technique to alleviate problems in FS with the delineation of the edges of objects that rely on a transparent background (FS tends to draw a 'pencil line' around them in the background colour, probably as a result of the anti-aliasing process). With the greatest of respect, it would be better to get your facts right before dishing out "blame" to people who probably did do an awful lot of thinking about how to get it right!What appears to have happened here is that the inadvertant use of these textures with your scenery has revealed a problem (or feature) in FS that was previously unknown:[ul][li]Either FS itself is rendering these textures incorrectly, displaying a semi-transparent background that is marked in the alpha channel of the file as 100% transparent[/li][li]Or the fault lies with the makemdl.exe interface from gMax, which is already known to flag textures applied to building objects incorrectly as being aircraft textures. Perhaps FS deliberately has a different way of handling 'aircraft' textures to 'building' textures, and does not interpret the alpha channel in the normal, expected, way. Something to do with the alternative use of the alpha channel for reflectivity, perhaps?[/li][li]There is also the question of that Alpha flag setting that you have yourself called attention to - Colorkey or Alpha, what's the difference and is it relevant? Image Tool shows us the setting but provides no facility for changing it (and neither does Martin Wright's DXTBmp).[/li][/ul]This could all be important knowledge for those of us interested in pushing the boundaries of FS scenery design, which clearly includes you guys at Lago!!!Gerrish

[Guest]

>So anyways's, can you give us a hint as to what will follow >the fantastic PHNL? Sure, it will have runways and terminals.>Also on a side note, I noticed in some screen shots of FSSE >that the planes are shall we say, boxy looking. Almost like >FS95/FS98 type planes. Before buying it I would like to know >if there is a way to use FS2000 or 2002 type planes? Can we >use GMAX planes that are very frame rate friendly like the >king we use for AI aircraft? Thanks Mathijs. You guys rock! The aircraft are basic because they are intended to be used on aprons some way off from the main areas. We looked how users are using FSSE and most commented that they wanted AI aircraft close (and those are pretty detailed). So we concentrated on keeping the aircrafts simple and easy to display. Compared to the AI aircraft they are VERY fast in display, as far as I can see you can place 7 of them against 1 Gmax AI aircraft. But I also like the AI aircraft close by to look good! In the new Service Pack we will deliver something like 20 new liveries because most people wanted more of those. We are working on a set of GA aircraft that are detailed (like those on Emma Field) because these normally are not combined with AI traffic and you do seem them close up.Mathijs KokLAGO

[Guest]

Gerrish,>I'm sorry, but it is a special case for Autogen, >that's the whole point! The only scenery that will normally >have opened the Autogen tree texture sheets before your >Honolulu scenery does is the Autogen code, and that appears >to handle its textures differently and separately to BGL >stuff. The other stock textures that you refer to are used >by 'stock' BGL code and are a totally different case. There's a misunderstanding here. The point was if a scenery that is calling a texture from the main folder is saving memory or not, comparing to a scenery that has a local copy of the texture, and if there is or there is not an optimization that prevents ( in the only case of the main texture folder ) to a texture to be called twice. While there's proof and it's very well known ( as you said ) that a local texture with the same name of a stock one will be loaded again, there's no proof the the Autogen is not using the same general *loading* ( note here: _loading_ not displaying ) routine of the rest of FS.>I regret that you are also wrong when you say that the stock >textures have been replaced "without caring to at least >respect the original file format". I will grant you that if >the authors had used exactly the same format as the >originals (DXT1 Alpha), the problem wouldn't have arisen. That's *exactly* what I've said. If the author used the same format as MS did, ( DXT1 Colorkey, not DXT1 Alpha ), there wouldn't be any problem.>DXT3 was probably chosen because of problems >with the nVidia code for creating mips for DXT1 with Alpha, >and the choice of a non-black background in the main images But the original textures that come with FS, as supplied by MS, *are* in DXT1, and they DO work without problems on nVidia or any other card, both when called as Autogen, and when called within a scenery.The problem appears only with the replaced ones that used DXT3 instead. Anyway, if it's true DXT1 creates problems, why *you* used DXT1 in your set of replacement Autogen textures, that instead appears to be working just fine ?>is also the question of that Alpha flag setting that you >have yourself called attention to - Colorkey or Alpha, >what's the difference and is it relevant? Image Tool shows >us the setting but provides no facility for changing it Colorkey simply means an Alpha channel with only 1 bit, and Alpha means the full 8 bit Alpha. Imagetool decides automatically the format when it opens the original source image ( usually .PSD or .TGA ). If it finds multiple gray levels in the Alpha Channel, it will work in Alpha mode, if it finds only a straight black/white combination in the Alpha Channel, it will go automatically into Colorkey mode. It will also go into Colorkey mode the moment the format gets changed in DXT1, automatically.Try this for yourself: make two identical images with Alpha, one with pure black/white Alpha, and apply a blur or something to the other one in the Alpha Channel only ( in order to get gray levels on the Alpha channel ), and save it as .PSD, possibly. Imagetool will open the first one in Colorkey mode, and the second one in Alpha mode.I've just made a small test to confirm this, I've dowloaded *your* set of autogen textures and installed them.They are in Colorkey mode and are correctly saved as DXT1, just as the Microsoft originals. And they DO work perfectly in Honolulu, more crowded than the originals, of course ( as intended ), but without transparency problems.I've downloaded the other set of textures that creates the problem, those from Ed Truthan, they are in DXT3 in Alpha mode, and they do have transparency problems that appears only in the scenery, not in Autogen. I've converted them in DXT1, they revert automatically to Colorkey mode, and they work perfectly with Honolulu and Autogen! No black borders, no Mipmap problems or anything like this, on my nVidia card, with the added benefit that the file size went down from 1.3 MB to 650K. As I've said already, there's no point using DXT3 for Autogen, DXT1 works just fine, takes half of the space, there are no display problems with nVidia, I don't see any mipmap problems nor anything unusual, this is the format MS used for their own original Autogen textures, it *works*, so why arguing then ?But you can be sure we'll include a local replacement texture for the palm trees in the next patch, then everyone will be happy.best regards,

[Guest]

I have just uploaded a small hotfix to solve the transparency issue of the animated palms. In this hotfix we do not use the default textures but provide our own. You can find the file here; ftp://140.99.102.60/pub/HONO_PALMFIX_ENG.zipAlthough I maintain our point of view that as a add-on builder for FS2002 we have to assume that all files part of the original distribution of FS2002 should be available and okay (in every way), we do not want to make life hard for customers who are using non- standard files:-).Mathijs KokLAGO

[Guest GerrishGray]

Thankyou Mathijs!This was the easy way to fix the problem. As I have explained to Umberto above, the Autogen texture sheets are a rather special case because they are not part of the normal stock textures used by the default FS2002 scenery, but are actually part of the separate Autogen system which handles its textures somewhat differently. Even Microsoft themselves have issued a replacement for the original Autogen tree texture sheets, so you were somewhat mislead in your (understandable) assumption that you could rely on them!The underlying technical cause of the problem didn't lie with anything that you guys at Lago did or with the DXT3 replacement textures, which should have worked OK under normal circumstances. There is a recently-discovered fault in the gMax~makemdl.exe~FS2002 interface that makes FS2002 handle textures incorrectly in BGL files. We already knew that this fault can result in loss of texturing on objects in the middle-distance - now your Honolulu palms have made it clear that it also causes incorrect handling of the alpha transparency channel for DXT3 textures. You might want to bear this in mind yourselves when developing further scenery with gMax - the fault can be prevented by intercepting the assembler code at the makemdl.exe stage and changing the texture type setting to the correct value for BGL usage, before recompiling with BGLC.My objection was to the way that you made a press release putting blame on essentially innocent parties and were reluctant to apply the simple workaround available (although some of your users had already done it for themselves at my suggestion!). You know as well as me that this is rarely the best way of handling support issues, although we all fall into the trap sometimes ...All is now rectified!RegardsGerrish