Sign in to follow this  
Guest jimkeir

The Isle of Plight: LWMpoly2, LWMpoly3, and Waterbergs...

Recommended Posts

Hello again!More news from the Isle of Plight :-)Here's a report about my new(?) invention for FS9 scenery: Waterbergs!(Obviously, the summer variant of icebergs :-)) I'm reporting this partly because I still need to solve this issue, and partly because the info might perhaps be useful to other bglc users.I had made a mountaineous island for FS2002 (see an [a href=http://forums.avsim.net/dcboard.php?az=show_topic&forum=123&topic_id=18304&mesg_id=18304&page=&topic_page=1]older[/a] and a [a href=http://forums.avsim.net/dcboard.php?az=show_topic&forum=124&topic_id=2122&mesg_id=2122&page=]newer[/a] thread), and was trying to transfer that to FS9.Initially the terrain didn't work: I had either correct terrain but square coastlines, or correct coastlines but flattened terrain.This has now been solved for the island itself (thanks to the untiring support of guru Holger here).What was needed was a hack of the HP*.bgl file, equivalent to the earlier successful hack of the FS2002 hyp*.bgl.There I needed to apply "clinging water", indicated by a height value of -9999 in the LWMpoly2 statements).But then I found that with my hacked HP*.bgl, I had also enriched the seascape by waterbergs in two (LOD13) areas.89869.jpg" alt="Waterberg!"These two waterbergs were in the same LOD8 cell as my island, but quite far away, never in adjacent LOD13 areas.In fact, during my experiments, the location of these waterberged areas changed, but they were never close to the island (although always in the same cell). And neither close to each other, e.g. one was in area 7x0, and the other in area 1x16.Further analysis revealed this:[ul][li][p class=dcmessage]I had tried to transfer the hacked parts of the FS2002 hyp*.bgl to FS9.The relevant FS2002 statements were LWMpoly2, all square with only 4 points each, such as:[/li]

	LWMDataAreaDrawPolygons	1,3,1,1,16	LWMPoly2	4, 0, _Water_, -9999, 0		LWMPoint	1, 246		LWMPoint	1, 1		LWMPoint	255, 1		LWMPoint	255, 246

[li][p class=dcmessage]I moved these into the FS9 HP*.bgl source code (obtained from LWMviewer, which is marvellous, thanks Jim!),and recompiled with no trouble. But then in FS9 found the waterbergs.[/li][li][p class=dcmessage]Next, I de-compiled my hacked HP*.bgl file again, and found that all the initial LWMpoly2 statementshad in fact been replaced by LWMpoly3 statements.E.g.[/li]

	LWMDataAreaDrawPolygons	1,_Transparent_,1,1,16	LWMPoly3	4, 0, _Water_, -9999, 0, -2559, 1		LWMPoint3	1, 255, 1		LWMPoint3	255, 246, 185		LWMPoint3	128, 4, 241		LWMPoint3	216, 0, 1

[p class=dcmessage]This first one looks still reasonable (except for that -2559 value), but after that everything got totally scrambled:instead of a series of simple squares, I found long lists of complex polygons, on top of each other:[/p]

			LWMPoly3	54, 1, _Land_, -31559, 4, -9999, 0		LWMPoint3	1, 246, 1		LWMPoint3	1, 255, 1		LWMPoint3	255, 246, 249		LWMPoint3	132, 4, 241		LWMPoint3	216, 0, 1		. . .

[p class=dcmessage]and even some LWMpoly3Ex statments with even more points.[/ul][p class=dcmessage]The reason is probably simply that the parameter number of LWMpoly2 (5 param.) and LWMpoly3 (7 param.) is different.Therefore just changing all "LWMpoly2" to "LWMpoly3", without adjusting for this difference, will necessarily scramble the parameters totally. It's a miracle that this didn't completely crash the whole scenery.But it doesn't: these nonsensical polygons are really restricted to two areas only, where they just form waterbergs. Questions:[ul][li][p class=dcmessage]How can I prevent BGLC from "translating" LWMpoly2 to LWMpoly3 and thereby scramble the parameters?[/li][li][p class=dcmessage]If that is not possible: How do I do the "clinging water" trick with LWMpoly3?In LWMpoly2, the altitude has to be set to -9999. But LWMpoly3 has two altitude parameters (min and max).Can I just set them both to -9999?[/li][/ul] [p class=dcmessage]Thanks for any pointers!Cheers,Martin "Slartibartslow"

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hello Martin,could you redescribe your workflow again? What tools are used, what file goes in, what file goes out?1) I don't think bglc changes any structure from LWMPoly2 to LWMPoly3!BGLC translates asm text-code into binary bgl files.I think, that either translation back into asm-text is wrong or the "hacking" process is only valid for either LWMPoly2 or 3 structures.2) As far as I know, meshclinging water is not possible with LWMPoly3. See the answer by rhumbaflappy: http://forums.avsim.net/dcboard.php?az=sho...22497&mode=fullYou could use my cfs2confv2.zip to convert asm sources with LWMPoly3 structures into LWMPoly2 ones (search for "LWM Converter" in the avsim library) to produce mesh clinging water from LWMPoly3's.Regards,Edgar

Share this post


Link to post
Share on other sites

Hi Martin,just a quick response for now:as Step 6 you state that you disassemble your edited LWM file again (and again). Why?Instead, use the first edited version of your hacked file and make the required changes in it, then re-compile that one. That is, always edit in the same file and recompile it (I usually make a backup copy of the previous edited version in case I totally mess up something).For the odd places in C and D I'd just find the LOD13 Areas and replace the entire code of each Area with:LWMDataAreaFill1x1 0, _Water_, 1, 24, 13LWMDataAreaHeight 0, 0where "24, 13" are the X/Y coordinate of the respective Area.Hope that helps.Cheers, Holger

Share this post


Link to post
Share on other sites

Hello,I don't think, that using LWMDataAreaFill1x1 is a good idea - the flightsim would crash, if you switch to the map view. Therefor Ground2k4 switched to simple VTPPolygons for that.(see the recent thread "AreaFill in TDFMacros.inc" http://forums.avsim.net/dcboard.php?az=sho...22423&mode=full )Martin, the easiest way to check the disassembling capabilities of LWMViewer concerning LWMPoly2 is to decompile a FS2002 scenery - it works. I think, not much addon scenery uses LWMPoly3 macros - tools like Ground2k4 don't generate such code in the moment. I don't know much about other tools. But thats not a problem, because FS2004 supports LWMPoly2 very well - these polygons just lack any height information ("mesh clinging")That FS9 knows nothing about about meshclinging water, just means that FS9 default sceneries use LWMPoly3 and provide height infos, but FS9 still displays LWM2 polygons without that data.The converter could be used to transform FS8/9 LWM data (better resolution) into CFS2 compatible sceneries - simply strip off the height data. Or it could be used to strip off height data for sceneries in FS, where you have better mesh data now, which doesn't fit to the default LWM data (and their height).Unfortunately I have no solution to your problem :(. But I suggest, you double-check the step 3, where you mix the decompiled FS9 sources with decompiled/hacked FS8 source parts. That is suspicious, when source and decompilation don't match...I would like the opinion of someone else, why there might be this row of 32 LWMpoly3 in the default bgl necessary? Have no idea. Which bgl and with region is it anyway?Gru

Share this post


Link to post
Share on other sites

Regarding LWMPoly3:The LWMFileHeader needs to be changed if it's to be translated to FS2002 code. The version clues the sim, and LWMViewer, how to translate the BGL code. Here's the TDFMacros definition:LWMFileHeader Macro Version, IndexHeader, Data, End LOCAL startstart LABEL word DWORD 20 ; // Size of this header ( 20 bytes ) DWORD Version ; // Version ( 100h is CFS2 201h is FS2002 300h is FS9 ) SDWORD ( OFFSET IndexHeader ) - ( OFFSET start ) ; // Relative offset to index SDWORD ( OFFSET Data ) - ( OFFSET start ) ; // Relative offset to data SDWORD ( OFFSET End ) - ( OFFSET start ) ; // Size of all data plus headersENDMDick

Share this post


Link to post
Share on other sites

Me again:"I don't think, that using LWMDataAreaFill1x1 is a good idea - the flightsim would crash, if you switch to the map view. ..."Yes, but that thread also states that AreaFills work fine "at the default level". Most of my add-on sceneries contain hand-edited and recompiled default files (with lots of AreaFills), which I place with the add-on scenery in a local scenery/texture folder, and there are no crashes in either map or GPS view. It may not be very elegant to mix the FS8 code with the FS9 code but it obviously works okay, except for the de-compiling issue. Those "waterbergs" probably originate from that. As long as Martin works with one the same "edit version" he'll be fine. Of course, the other option is to use your (Edgar's) LWMconverter to convert the entire default HP9 file to Poly2 format, then copy and paste the content of the entire LOD8 Cell into the LWMViewer-decompiled default HP9 (i.e., with Poly3), and recompile. That's probably the fastest and most efficient method unless any LOD13 Areas in the LOD8 Cell need to be of fixed height.It's pretty typical for coastal LWM files to end - on the sea side - with rows or colums of 1x1 AreaFills; probably an artifact of the tool that originally generated those LWM files. Cheers, HolgerGruesse vom Ex-Deutschen aus Vernon, B.C., Canada ;-)P.S.: BTW, Slartibartfast can generate either LWM2 or LWM3 polys though it doesn't help with Martin's particular task.

Share this post


Link to post
Share on other sites

Good morning Holger,'... that thread also states that AreaFills work fine "at the default level". ' - sorry, I didn't noticed that. I thought, AreaFill1x1 are generally not usable any more in FS9.But what is the correct default level?Gruesse,Edgar

Share this post


Link to post
Share on other sites

Hello Dick,if I understand this right, the solution would be to change the version number in the Header to the FS2k2 constant value, right?This is quite amazing: both LWMPolyX macros start with the same value (BYTE ( Attrib * 80h ) + ( Reserved * 40h ) + PointCount), but it gets interpreted by the FS version number in the Header.That mean, you can't mix LWMPoly3 (FS9) and LWMPoly2 (FS8) macros in the same file. The decompilation (and display in FS2004 with the water spikes) failed, because the engine expected LWMPoly3 macros and LWMPoint3's with height infos - which were not in the bgl. A pure coincidence, that the scenery didnt simply crashed the sim, but displayed spikes.So my suggestion, that Martins hacking process was wrong, was also false. Sorry! The process just wasn't complete.Regards,Edgar

Share this post


Link to post
Share on other sites

Gentlemen,thanks for all your helpful responses!First off, I can report that my problem is SOLVED!, island terrain and shoreline are now ok, and the waterbergs are gone!(I'm sort of missing them already... :-))What finally worked was very simple (as always in hindsight): -- leave all those LWMpoly3 areas (0-16 to 31-16) completely alone, -- and just for the one LWMDataAreaFill8x8 covering the location of my island, set LWMDataAreaHeight to "-9999, 0" (instead of the original "0,0") .( :-grr Painful Note: I had reported just this approach in my previous message as my newest bright idea, but had thought that it made the island vanish completely. In fact, it did nothing of the kind -- I had forgotten that I had temporarily disabled the scenery in the Scenery Library, and re-activating it helped a lot with making the island visible again. D'oh, as I think the expression is -- another case of not seeing the forest because of all the trees...)Bonus question: Why does this -9999 work? Everyone seems to agree that there is no mesh-clinging water in FS9. So, could it be any other negative height as well? Anyhow, problem solved! Thanks to All! I'll still go through your comments -- it may be of general interest, and who knows: it might help someone else later on, or will bring new insights.First, the LOD8 cell we are talking about is 437x85, south of the Helsinki coast of the Baltic Sea.For easy reference: This cell (and also my island scenery) contains the point at N60:0:0 E025:0:0 .Holger wrote:> as Step 6 you state that you disassemble your edited LWM file> again (and again). Why?> > Instead, use the first edited version of your hacked file and> make the required changes in it, then re-compile that one.> That is, always edit in the same file and recompile it Yes, that is indeed what I am doing. De-compiling the already hacked BGL again was just done for checking purposes,not for further editing. I wanted to see if my changes (hack) in the original source code had actually made it intothe compiled BGL. And I knew already that this BGL had things (waterbergs) which were not in my source hack, so I wanted to see what exactly had changed (as it turned out, the LWMpoly2 didn't survive quite right). Hence the "secondary"decompilation of an already hacked BGL. > For the odd places in C and D I'd just find the LOD13 Areas> and replace the entire code of each Area with:Well, the snag was that in my first hack, these places were not special at all. Just one of a series of 32 LWMpoly3squares. Only after compiling to BGL they [em]became[/em] special, because the code garbling gave them those waterbergs(which were of course not part of my hacked source code). So I couldn't yet replace them with anything else in the initial stage. And apparently, according to Edgar, there are issues with this approach anyway (see below).Edgar wrote:> I don't think, that using LWMDataAreaFill1x1 is a good idea - the flightsim would crash, if you switch to > the map view. OK, luckily I didn't even have to try it. I notice, however, that the [em]original[/em] default FS9 scenery happily usesthem twice in cell 437-85, namely for areas 14x0 and 15x0 (the two areas adjacent to the north of the small default scenery island, see screenshot in earlier message. And no problems with map view. Or am I missing Edgar's point here?Note however, that all this is based on the decompilations obtained from LWMViewer, and assumes that these reflect the BGL code correctly. Who knows what the [em]real[/em] code in the BGLs looks like...> I would like the opinion of someone else, why there might be this row of 32 LWMpoly3 in the default bgl necessary?I wouldn't make so bold as to have an opinion in this matter :-), but I notice that this row (in the default scenery;ignoring my stuff) fills in between two different realms:-- directly adjacent to the north of this row 16, there is a realm of AreaFillNxN squares with height 0 m;-- adjacent to the south of row 16, LWMViewer (the graphical interface!) shows a mysterious realm in white, and indicates the altitude there to be -1 m; in the FS9 scenery, this is all just plain sea. What gives? We're having a lot of bluegreen algae rafts in the Baltic nowadays, could that be it? :-)In any case, this "white region" is in no form whatsoever covered by any source code for cell 437x85 in HP954100.bgl -- neither AreaFill nor LWMpoly3.Could it come from some "level" even more basic than HP*.bgl?Dick (rhumbaflappy) wrote:> The LWMFileHeader needs to be changed if it's to be translated to FS2002 code. The version clues the simYes, I see. That explains why LWMpoly2 didn't make it into an FS9 BGL. In fact, I had thought of this, too, but wasn't sure if changing the FS version marker to FS2002 wouldn't then break [em]other[/em] things which FS9 needs...Next, Holger wrote:> Of course, the other option is to use your (Edgar's) LWMconverter > to convert the entire default HP9 file to Poly2 format,> then copy and paste the content of the entire LOD8 Cell into the > LWMViewer-decompiled default HP9 (i.e., with Poly3), > and recompile. That's probably the fastest and most efficient > method unless any LOD13 Areas in the LOD8 Cell need to be > of fixed height.That sounds promising -- will try it the next time (knocks frantically on wood and makes sign against the Evil Eye).But apparently we also must make sure, in this scenario, to compile for the FS2002 version, or all the LWMpoly2 will get broken.Then, Edgar wrote:> That means, you can't mix LWMPoly3 (FS9) and LWMPoly2 (FS8) macros > in the same file. The decompilation (and display > in FS2004 with the water spikes) failed, because the engine > expected LWMPoly3 macros and LWMPoint3's with height infos - > which were not in the bgl. A pure coincidence, that the scenery > didnt simply crash the sim, but displayed spikes.Can it really be a singular coincidence? Then I must have been pretty lucky. I also noticed that after some compile runs, the waterbergs were in slightly different places (area 1x16 instead of 0x16), so there seems to be some method in the madness.From the source code it looks as if all 32 LWMpoly2 squares (from the hack) get turned into just a few huge (with about 54 or more points)LWMpoly3 polygons, almost all of them in one area (0x16 or 1x16; note that in the hack, 0x16 was the very first LWMpoly2 statement), with only one straggler (an LWMpoly3 at 7x0). Whatever it means...Finally, to sort of wrap all this up a bit, and for the entertainment of future generations (poor souls), I have attached [a href=http://forums.avsim.net/user_files/90004.zip]a ZIP file[/a] containing source code fragments from the cell in question:-- as decompiled from original HP*.bgl, -- as hacked by me (insertion of FS2002 hack code), -- and as seen after decompiling the resulting hacked BGL with the waterbergs(read the !_Readme :-)).So, if you want to go into the grisly details, you can follow the fate of those LWMpoly2 statements when compiled under an FS9 header.I wonder why this LWMpoly3 vs. LWMpoly2 issue isn't old hat already -- they are not that rare statements, after all. Could it be that these issues arise only when hacks are applied to HP*.bgl files of the original scenery, i.e. at a "basic" level -- as opposed to real add-on scenery BGLs, which are just added "on top"? Perhaps the latter are less "sensitive" to these matters, and have therefore not been causing these problems?Again, thanks for all interesting discussion and the help!From the Readme file of the attached ZIP (quoted here, too, in case no one ever reads it :-)):"Thanks to Holger ("Holger"), Edgar ("edgarone"), and Dick ("rhumbaflappy") for their untiring help with pulling my bless

Share this post


Link to post
Share on other sites

Hi Martin.Although you may be happy with the result, you are simply lucky the file doesn't cause a CTD. The coding is BAD, as LWMViewer shows. It probably does crash TMFViewer.If you want to code properly, use the guidance of the SDKs and the help from the experienced users here.Dick

Share this post


Link to post
Share on other sites

Hello Dick,point taken! Thanks for having a look.> The coding is BAD, as LWMViewer shows. You are probably referring to the file C_HackedBGLdecompiled.bgs.That is indeed bad coding -- didn't crash but created those waterbergs.Note however (just trying to save face here :-)):This is not the final result of my exertions which I am now using. I just put this (now abandoned!) bad code "on file" for future reference, to show what happens if you try to just put LWMpoly2 into an FS9 source without any other precautions (such as adjusting the version marker in your include files).What I am in fact finally using now is a BGL from a much simpler hack: all the original LWMpoly3 squares have been left completely alone, and the only remaining "hack" is to change the height for the one AreaFill8x8 of my scenery location from 0 to -9999. I don't quite understand why, but that works and is not nearly so "dirty" as the file above, and the misguided attempt to port the FS2002 hack to FS9.> If you want to code properly, use the guidance of the SDKs and the > help from the experienced users here.Absolutely! If I ever do FS9 scenery again, I'll start from scratch, and will not "port"...Cheers,Martin

Share this post


Link to post
Share on other sites

Hello Martin,concerning the mesh clinging water...There are to methods: via LWMPoly2 (for single Polygons) and via LWMDataAreaHeight (for LWMDataAreaFill...)I was talking about mesh clinging water with LWMPoly3 - which is not possible. The other way is still usable - see the FS2004 Terrain SDK document, where its mentioned.Unfortunately in your sample mesh clinging water via LWMPoly2 wasn't used, so my remark was not relevant. Sorry for any confusion!As for another issue: I believe, its extremely implausible, that bgl files are treated differently, when origin from changed default or freshly created addon sceneries.Regards,Edgar

Share this post


Link to post
Share on other sites

Hi all.LWMViewer should be OK with both version 2 and 3 (and probably 1 but I've not checked for a long time). The code that gets written is a straight interpretation of the BGL with no adjustments, so it should be accurate.The points above are right, the version of *all* the poly structures must be the same as the version indicated in the header, and as far as I know there's no way of creating mesh-cling polys in V3. That's the reason I've recommended creating V2 polys with Slarti, it's less hassle. However, it seems that AreaFills *are* still allowed to have -9999 - mesh-cling - even in V3. I suspect this is an oversight rather than a design decision, so I wouldn't recommend using this feature.LWMViewer doesn't do a whole lot of checking of the vector data, so if something unexpected ends up in there it can be made to crash. There are also a few situations where a file that shows correctly in LWMViewer will crash the sim, so don't forget to test there too!Cheers,Jim Keir

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this