Creating coastlines for CFS2

[xavierb]

Hi,

For those who know CFS2, it is a well known fact that the default scenery has only coastlines on part of the Pacific. In the rest of the world, there are no proper coastlines (no beaches or real coast, just a straight line dividing the sea and the land).

As scenery designer for this simulator, I would like to know how it could be done to add proper coastlines (CFS2 includes two default ones, one with beaches and another without it) to the coasts missing it. Until now, I have found only the methods explained at SdC's website, but they are quite difficult and time-consuming.

On the other hand, I have seen packages of mesh terrain like those of VF2Rolf or the Japan mainland scenery by Yoshi that not only add elevation terrain but also coastlines to the zones they cover. Also, there are the excellent Rhumbaflappy's coast packages that flattens the waters of all the world and make many coastal areas landable for seaplanes, although they don't add a coastline.

My intention is to know or find a way to make, as easily as possible, proper coastlines for those parts of the world that don't have it. Please does anyone can suggest a way/tool to do that? CFS2 features characteristics both of FS2000 and FS2002, so perhaps a valid technique for those flight simulators can be useful at CFS2 too.

Thank you and best regards,

Xavier

 

[rhumbaflappy]

Hi Xavier.

What you are looking for is a way to create LWM poly1 water, and the VTP1 beaches.

The only program that can do this visually is Ground2K ( NOT Ground2K4 ), by Christian Fumey. I know of no other programs to create the VTP1 poly-lines to make the beaches.

LWMViewer ( version 1 ) by Jim Keir can decompile existing LWMs of all types.

http://www.jimkeir.co.uk/FlightSim/LWMViewer.html

Edgar Knobloch's LWM Converter can convert FS2002 and FS2004 water polys to CFS2 ( LWM Poly1 ).

http://library.avsim.net/esearch.php?CatID=cfsscen&DLID=43104

++++++++++++++++++++++++++++++++++++++

It should be possible to create a program that will convert various types of ASCII files into a format that can be read by Ground2K. That would allow you to make lines in SBuilder, for example, and export them as BLN... then convert BLN to a Ground2K project file. If you'd like, yopu could even convert SHP files to Ground2K.

The only problem with this method, is Ground2K depends on a bitmap background, and that cannot exceed about 8000 x 8000 pixels, and may require you to start the program in 256 colors ( Compatibility mode ).

+++++++++++++++++++++++++++++++++++++++

You can see the problems Sander ( SDC ) was facing. His work was based on converting FS2004 lines and polys to CFS2. Sander seems to have dropped out of the CFS2 design scene... no one has heard from him since October 2006.

We never had the tools Microsoft used to create the original polys and lines, but I'm sure it was an ArcGIS script of some sort.

The actual compilation, for us, would be to use the TDFMacros, and BGLC:

http://library.avsim.net/esearch.php?CatID=fs2004sd&DLID=53313

BGLC_9 is fine for assembly.

How nice it would be to just take a list of longitudea and latitudes and have a program spit out CFS2 water polys, beaches, Area16n flattens, roads.... No one ever got that far in programming.

Dick

 

[rhumbaflappy]

Hi Xavier.

I looked at the latest build of SBuilderX ( for FSX ), and it still allows the importation and exportation of BLN files. It also has some nice features to allow the importation of SHP files and Yahoo maps ( directly from Yahoo! ). It can be used to draw shapes for water, shorelines, roads, etc., and the results output as BLN.


The OLD Sbuilder can import the BLN waterpolys, and they can be compiled... and those decompiled by LWMViewer, and that decompilation altered by Edgar's LWMConverter, recompiled, and we have water for CFS2.

If we use the new SRTM DEM mesh data, the major water is already flattened.. but some shoreline areas may need some work with Area16N flattens to touch them up.

What is left is the VTP1 polys and lines. Those can be exported as BLN, but we need a way to create a Ground2K project file, and a "dummy" bitmap to make the roads and beaches. Christian Fumey did give me a utility to use for this, but I don't know if he would allow me to distribute it. Christian sometimes visits this forum, so maybe he could help here... or maybe he has a better utility for this ( basically a SBuilder to Ground2K converter for CFS2 ).

There may be a way to program a VTP2 to VTP1 ASM converter, but the two formats are quite different. Better, would be a BLN to VTP1-ASM converter... but that is basically what Ground2K would be doing.

Dick

 

[xavierb]

Hi Richard,

Thanks a lot for your replies. The amount of info and possibilities is exciting. Anyway I am a bit confused about what the steps would be. I have opened the tools and have found the following:

- LWMViewer (v. 1.3) has export is restricted to bitmap or to the source to a format called bgs. No BLN export option as far as I can see.

- SBuilder seems to expect VTP2 polygons in VTP Bgl files. LWM files has to be those of FS9, so your old (but good) CFS2 water flattens don't work with it.

- Cfs2conv only works with .asm files.

So what can be done for the moment may be only to load the LWM bgl's from FS9 or FSX into Sbuilder. Export them as BLN files.

Then one of the following two choices has to be done:

1) request Christian the utility you have told me
2) Create the program to convert BLN to VTP1 asm conversion

Will the second method avoid to use a bitmap and the tedious and long editing work? I am familiar with programming in Visual Basic, so maybe I could accept the challenge if enough information on both formats are avalaible somewhere.

Are you familiar with Christian to request him this utility for my personal, non-profit use? If you wish, please send me a PM with Christian's e-mail in order to make him the request. Thanks in advance.

Best regards,

Xavier




2) Import

 

[rhumbaflappy]

Hi Xavier.

You can use SBuilder to make or import LWM2 water polys and compile them. Then LWMViewer can decompile them to BGS... BGS can be renamed as ASM.

Then the Cfs2conv program will make CFS2 water poly ASMs for you. Then compile them with BGLC_9.

SBuilder can import maps, and SBuilderX uses yahoo maps directly if desired.... I don't know if they are projected right.

I would use SBuilderX to make lines over a map background, and export a BLN from there.

I'll ask Christian about distributing that program. If it's NOT ok, then we could make a small converter program for BLN to G2K project format.

Dick

 

[xavierb]

Thanks for the reply, Dick. I am starting to see the light.

By the way, perhaps I am a bit too simplistic and forgive me if I tell something specially silly, but I would like to know if the following could be done (and what could be the expected/potential problems):

- Get an existing package of LWM water and export them (with LWMViewer to ASM or from SBuilder to BLN, first thing for your CFS2 coasts, SBuilder for FS9 ones, whatever be easiest).

- Create a converter that would convert the LWM polys to VTP1 ones in ASM format, ready to be compiled. End-users would have an additional scenery layer of coastlines.

Besides all the inherent problems related to the creation of the converter program, I suppose a problem would be that all polygon lines would have the same type of coast (sandy beaches even in rivers or lakes, for example).

Again, I repeat that surely I am trying to be too simplistic due to my ignorance, but sticking to existing scenery/polygon data and avoiding the bitmap drawing would save a enormous amount of time.

Thank you very much again for your expert advice.

Best regards,

Xavier

 

[rhumbaflappy]

Hi Xavier.

LWM water polys would be split into LOD13 chunks... so any converted to beach would then surround the LOD13. Not what we want for beaches.

Sander ( SDC ) had devised a method to convert FS2004 lines to vectors using Wintopo(?). He may have used LWMViewer output.

The problem is that FS2004 water polys and beaches aren't very accurate.

Luis Sa's SbuilderX has a few methods of getting Yahoo or Google, or MS Virtual earth images as backgounds for that program... but you're still relegated to tracing a map to get the data.

The whole problem with water, shorelines, roads, is the absence of free data. That's never changed since the earliest scenery development for the FS series.

We can use Google or Yahoo or MSVE for backgrounds, and we can use landsat images as well. But we still need to trace lines and polys, and that is a gruesome task for the whole world!

Another possibility would be to use Slartibartfast for water and shorelines. Even if that line output is VTP2... that could be run through SBuilder, and BLN exported. Then we might be able to convert those shorelines.

I haven't played with Slarti much, but it may be a key.

Dick

 

[xavierb]

I will try Slarti and see what can be done with it. Anyway, in the end we would need the conversion from BLN to VTP1-ASM. I hope Christian Fumey may help us if requested (I cross the fingers)

I appreciate the path SBuilderX opens with the use of the Google maps. Anyway currently I don't own FSX (in fact, I even purchased FS9 just to explore ways to convert scenery, so for me it has already had a poor Return of Investement), and I think that having a FS9-style scenery is more than good for CFS2. I don't resign to try the SBuilderX-Google maps in the future, but first I want to try with the tools I already have at hand.

I will be offline during the whole next week (at least) because I am moving to Italy, but I will start playing with SBuilder (just purchased registration yesterday) and Slartibartfast. Hope Christian may respond (positively). Again, thanks a lot.

Best regards,

Xavier

 

[SdC]

Hey guys!

Long time no see! I'm still alive and will probably start working on cfs2 again in the next few weeks.

THE biggest problem we have is that there is only one program that can create VTP1 lines: ground2k v.4. And that algorithm is buggy. Christian Fumay kindly responded to questions I had. Unfortunately he has lost the source files for that version of ground2k....
Apart from that, the VTP1 format seems to be a lot more limited in how many points we can have per cell etc. than VTP2, so straightforward conversions will probably never be possible. The "stock" FS2004 lines are very close to the limit of CFS2; I still have to simplify it sometimes.
We really don't know the exact specifications of VTP1.

" Get an existing package of LWM water and export them (with LWMViewer to ASM or from SBuilder to BLN, first thing for your CFS2 coasts, SBuilder for FS9 ones, whatever be easiest)."
>>>> My cfs2autocoast tool can convert a number of files (including SBuilder SBX/BLN, SHP) to Ground2k files. Additionally, it can make A16N flattens for LWM-water covered area's when converting FS9 LWM through SBulder SBX files.

"Create a converter that would convert the LWM polys to VTP1 ones in ASM format, ready to be compiled. End-users would have an additional scenery layer of coastlines."
>>>> the original LWM poly's are NOT the shape of the lake/sea, but a collection of squares and little poly's (max. size 1 cell) around the edge. It would be extremely difficult to deduct the continuing coastlines from this.

"Besides all the inherent problems related to the creation of the converter program, I suppose a problem would be that all polygon lines would have the same type of coast (sandy beaches even in rivers or lakes, for example)."
>>>> with my cfs2autocoast I've used a mask bitmap for this that takes about 5 minutes per LOD 5 square to make.

"Sander ( SDC ) had devised a method to convert FS2004 lines to vectors using Wintopo(?). He may have used LWMViewer output."
>>>> It turned out the ONLY mehtod I found that works from start to finish (to get good LWM with good fitting coastlines on a LOD5 square) is by using LWMViewer exported bitmaps and tracing the lines (automatically), and then manually fixing a few possible anomalies.... However, using a varietly of (topo/fs9) data is possible. In fact, I use SBuilder sbx/bln files for the roads/streams/rails). I'm not using WinTopo.

"Another possibility would be to use Slartibartfast for water and shorelines. Even if that line output is VTP2... that could be run through SBuilder, and BLN exported. Then we might be able to convert those shorelines."
>>>> and PRAY that ground2k/VTP1 swallows the same level of detail.... The cfs2autocoast-trick "enforce minimum segment length" to reduce the resolution of the source data may help a bit, but it may also break the relation between LWM water and VTP1 coastline.


"I will try Slarti and see what can be done with it."
>>>> didn't get me anywhere.

 

[rhumbaflappy]

Hi Sander.

I'm glad you're back!

Dick

 

[SdC]

Thanks! It's good to be thinking of LOD's, ASM, SCASM etc. again!

I forgot to mention a few crucial details:
Using SBX or BLN conversions of the fs9 Coastline files (HLxxxx.bgl) and importing these into ground2k gives too many errors on compilation (as I said before: ground2k v.4's VTP1 algorithm is pretty buggy). These could be corrected using a couple of tricks, but this would alter the lines too much: they won't be aligned to the water any more. So then you would need to adjust the water again, but that would be impossible to do automatically due to the nature of the fs9 coastline lines.

I also experimented a lot with the SHP files. These also did not compile properly - even if the ground2k project seems perfectly fine, and turned out to be frustrating.

The final conclusion I made last year was that the only way we can progress at all, is to program our own VTP1-asm routines (the rest is all done). I've spent many hours looking at the raw asm code, and apart from getting a headache, have made no progress.... still, it should be possible to reverse-engineer it. I'll give it one more go.

 

[rhumbaflappy]

Hi Sander.

Jim Keir's LWMViewer gives a look at the default VTP1 lines.

The Ground2K-made lines are rectangular polygon segments.

The default lines are polygon segments that have been segmented, with the segments triangulated. It appears the segments are no more than 6 points, with an even number of points in the segment using _IsStrip, and odd point-numbered segments using _IsFan... in disregard to what the FS2002 Terrain SDK describes. The texture is mapped to these triangles. All VTP1 lines are split to LOD13 Areas. I have NO idea how we determine the texture mapping. I guess I haven't stared at it long enough.

In other words, our CFS2 lines are actually triangulated polys.

The arrangement of the data in the BGL is in rows, starting in the NW LOD8 Cell, completing that row towards the East end, then going South one Cell ( at the West start-point ), continuing east...

Cell1------------------------------>
Cell2------------------------------>
Cell3------------------------------>

The LOD13 areas within the Cells is in the same arrangement.

The file sizes can be huge! The decompiled "pac7ma4p.bgl" is 43 MB, with over 1,500,000 lines of code! This produces a 4.5 MB bgl. It takes forever to compile an LOD5 full of lines.

Dick

 

[SdC]

I'm on the virge of having a solution:
using lwmviewer export as asm, using cfs2conv.exe to convert to cfs2 water (there are two versions; the latest one "does" LWM3 to LWM1). This takes about 2 minutes.
Then I use sbuilder to export the hpxxxx.bgl to sbx, then use cfs2autocoast to convert the sbx to both coastline-ground2k-vtp1 and scasm-a16n. I use the altitude parameter to determine Ocean coast (white beach) at alt=0, or Inland coast at alt>0.
There are still a few snags, but if succesful, the resulting coastline-vtp1's will fit exactly inside an lod13 square, which should circumvent ground2k's difficulty in chopping up the lines (vtp1_poly_extract and LON_8_13_decoupe errors).

 

[SdC]

Hi Sander.

......
The file sizes can be huge! The decompiled "pac7ma4p.bgl" is 43 MB, with over 1,500,000 lines of code! This produces a 4.5 MB bgl. It takes forever to compile an LOD5 full of lines.

Dick

...this I know!
For the compilation of the bulk of Europe's roads and rivers, my computer has been running many many nights unattended.....
Very frustrating if you wake up in the morning to find an error message!

Thanks for the additional vtp1 info, very helpfull!

 

[SdC]

Yep, I got the first LOD5 coastline project converted through the SBX file to ground2k and it compiled. Still with an "Abnormal lat 8 13 cut" error, but that is the next step: to increase the gaps between the lod13 squares programmatically.
There is one thing I can't fix programatically through: between some landmasses and islands, there are connecting non-horizontal/vertical lines that will need to be removed manually. I tried on a complex project (hp946110 - NE Scotland) and there were about 60 of those.... I think I could live with that, althrough it adds another 30 minutes to conversion time.

 

[SdC]

I think I have now worked out the asm syntax for the vtp1 lines.... an algorithm is forming in my head. My oh my this stuff is complicated.

It appears the segments are no more than 6 points

This does not appear to be true; the stock cfs2 files use up to about 16 points per poly. According to the fs2002 terrain sdk, it can be up to 61 points.

_IsStrip, and odd point-numbered segments using _IsFan...

It seems that when a line segment fits within an LOD13 area, it is a _IsStrip, and when it is chopped up, 2 _IsFan poly's result, otherwise the UV mapping is lost. This parameter determines how the texture mapping is done.

 

[rhumbaflappy]

Hi Sander.

The TDFMacros lists this:

; --------------------------------------------------------------------------------

VTPPolyMethod1	Macro	PointCount, IsStrip, IsUVExplicit

;	enum{ MaxNumPoints = 62, PolyEx = MaxNumPoints+1 };
;	UINT8 bPointCount:6;		// Up to 62 points, 63 means that this is an 
;	  extended poly
;	UINT8 bIsStrip:1;			// 0 = Fan, 1 = Strip
;	UINT8 bIsUVExplicit:1;		// MUST BE 1 = Points contain XYUV


	BYTE	( IsUVExplicit * 80h ) + ( IsStrip * 40h ) + PointCount

EndM

; --------------------------------------------------------------------------------




VTPPolyMethod1Ex		Macro	ExPointCount

;	enum{ MaxNumPointsEx = 63 + 127 };
;	UINT8 bExPointCount; 	 // The number of points = 63 + bExPointCount


;	BYTE	ExPointCount
	WORD	ExPointCount

EndM



; --------------------------------------------------------------------------------

There is an extended format for VTP1 lines that allows more points.

I haven't looked at all the point counts in the defaults, but it does seem that odd numbered counts are fans and even are strips. I think that makes sense as well.

I think the complication of coding the lines is why the Aces team went to VTP2 in FS2002. And the code size is much smaller with VTP2.

Dick

 

[xavierb]

Well, it seems my post has been useful to reopen the question. I am very glad of it.
Because my knowledge of asm, vtp's, etc. are limited or none, I can add little to this discussion but to encourage you, SdC, on your CFS2 autocoast project.

 

[SdC]

Thanks, and now you know I am the only one in the whole world who is still working on this for sure!

 

[rhumbaflappy]

Hi Sander.

Other than Christian Fumey, and the Aces team, you may be the only one that has ever seriously looked at algorithms to create VTP1 code!


It would be nice if the Aces dusted off the old programming code for ARCGis ( or whatever was used ) and made it available. It's not like it will ever be used again.


Dick