cfs2autocoast status update

[SdC Redux]

Hi all,
As you may know I abandoned cfs2autocoast development and support over two years ago. Last week I started development again. I'll be using this post to keep you updated as to what's going on (and to help me keep on track and focussed)
The following tasks are on the roadmap for the VTP1 creator:


Routine for converting coordinate/width line data (in first instance from SBuilder SBX files) to polygons (80% Complete)
Apply UV texture mapping (50% complete)
Clip polygons at LOD13 intersections
Create ASM file for compilation by BGLC

The new LWM's from Rhumbaflappy add 2 new tasks to this list

Either use decompiled BGL's or Rhumba's sources as input for the VTP1 creator. In either case, the only problem I probably won't be able to solve is where to use "ocean shore" or "perennial shore" type textures....one size fits all...
Find new source data for roads/rivers/railways that is compatible with the new LWM and preferably passable as 1940's infrastructure. This must also be editable, preferably in SBuilder.


That is, IF I'm going forward with using Rhumba's files..... I kinda would prefer to go on with the FS2002 data from a technical point of view; the shorelines are reasonably neatly mapped out, it all kinda works together, at a level of detail that CFS2 handles very well. On the other hand, using Open Source/Public Domain data is very sensible too. Decision pending! I've only just downloaded Rhumba's files (Thank You Ickie that the files are available again!) so I still have a lot of testing and deliberating to do over this.

The end goal is to have a directory full of source files covering the planet, and a single button "BUILD WORLD"

Once I start building a repository of SBX and other assorted source files covering the whole world, I'll set up an SVN (subversion source control database) in the cloud somewhere where we can share the source files for editing; if someone needs/wants to edit/add to any part of the world, (either for terrain data or airfields, landmarks, you name it), it is available for download, and the result can then be slipstreamed into the build. End users can sync the latest changes automatically and incrementally (after testing/approval)

[rhumbaflappy]

Hi Sander.

I'd advise NOT going with the LWMs I uploaded. I've had valid complaints about them being too liberal with the water... flooding much of our familiar coastlines.

I used Slartibartfast in making the LWMs, and then converted LWMViewer-decompiled code to CFS2 LWM files. Slarti uses images and elevation data to make LWMs. This can still be done, but I used SRTM water body masks... which were a bit inaccurate. Also, a whole LOD2 size is a bit much...but I wanted to cover the world.

My vision was to use those LWMs as a default replacement, and then make accurate LOD5-sized LWMs / VTPs to detail areas. Sometimes the SRTM water body images were OK... sometimes not.

Dick

[Jean Bomber]

Hi Sander and Dick !

I think the Geotiff or swdb stay as good and very accurate sources to do an automatized process with autocoast and G2k even if some data nave some imperfections they stay the best today to basically make the land watermask and with a autocoast tool with a good curve,angle etc.. setting I'm sure you could quickly get some vtp1 coastlines basic but better than a default cfs2 background scenery because these will fit with the mesh and will be fixed at sea level without the use of any flatten alway good to take for the fps.
The recent desert scenery is only,the works that autocoast could do for the LM WM and shore.
For the roads ,I don't think that the use of any fs 8 or 9 source in the state how they are ,biaized, would be the good choice even if they were drawed surely from space Data and the vtp lines near of the existing roads etc... but there is an error.
Could it be possible to integrate in your calcul this error value this exemple tell the thing by itself , look the screenie it shows about that I've found during the Truk project I'd started to draw some islands and their coastlines from the srtm background bmp ,I've quickly stopped because in the cfs or perhaps the fs series generally in the map there is a big unedge from the position of the real world map,and this error concerne any place, the x,y values are wrong ....
could it be possible to find this error factor ,to find the right x,y ,that will give surely a constant value and use after a fs9 road system "corriged" that surely at least ,with the previous work with autocoast ,will give the coast at 0m that fit the mesh and roads that don't finish in the sea ....
Easy to say I know but that is the main issue to resolve before to start and keep a so huge project on the good way.
Truk thread:
http://www.sim-outhouse.com/sohforums/showthread.php?t=1435
here the link to get the swdb shape file these can easely be done as black and white to work with autocoast
ftp://xftp.jrc.it/pub/srtmV4/SRTM_Water_2D/
give a look also at the perry castaneda texas library
http://www.lib.utexas.edu/maps/ams/
there are a lot of scan of WWII era map

JP

[UncleTgt]

Just a newbie learning the ropes, but I have to say Richard's mesh was a revelation to me, it reaally improved the look of CFS2. It is soooo much better than the older mesh.
I haven't flown in europe, only Pacific & Indian Oceans, but my view, for what it's worth, is that it has to be worth the effort to make use of Richard's new mesh & redo the coastlines for those parts of the world that there is an interest - as there is so much to do, any progress on a method to auomate is welcome.

I think it would be a mistake to use the older FS2002 data.

Respectfully, a student of the Jean Bomber school of terrain "reworking":salute:

[rhumbaflappy]

Jean has a good point about the SRTM masks. Using Slartibartfast to make fs2004 LWM polys was the problem. If there is a set that exists as SHP files, then we could find a way to create BLN files for import to SBuilder, and make LWMs from that.

Else, we could use Slarti or a 'raster to vector' program to make them, as you did in the past.

I think restricting ourselves to LOD5 sized files might also be a good idea.

I also don't like the fs2002 or fs2004 data, as there are too many errors.

Dick

[rhumbaflappy]

Hi Sander.

The SRTM waterbody data as SHP files:

http://dds.cr.usgs.gov/srtm/version2_1/SWBD/

These are 1x1 degree files. They can be imported to SBuilderX, and then exported as BLN files for importation to SBuilder. SBuilderX has some slicing capability, that might be of use for saving BLN files as exact LOD5 areas.

Once in SBuilder, they can be processed as LWM polys.

Dick

[SdC Redux]

Hey guys,
I have done some serious thinking over your opinions and suggestions.
This is my conclusion:
I shall provide the TOOL that can read BOTH sbuilder 2.05 files (because that part is already developed in cfs2autocoast) and decompiled FS8/9 VTP2 ASM files (that part is still to be written, after I get the VTP1line.create and ASMfile.write functions completed).
The converter can be invoked both with the GUI and from the command line.
I think that should give YOU guys all you need to fight out amongst yourselves which datasets to use.

For the moment, I have to focus JUST on the most important part: VTP1line.create!!!!

[rhumbaflappy]

Hi Sander.

When looking at the default VTP1 lines, we can see they are actually polygons. There are 2 types.

All polys with an even number of points are drawn as strips. All polys with an odd number of points are drawn as fans. That's MS' default for the lines.

Strips are like ladder rungs. Fans are like traditional polys that follow the outline of the shape, with uv mapping applied.

All of these polys could be drawn as fans. I can draw thin polys as roads, for example, but the rules for the uv mapping would give us fits... that's why I think MS used mostly strips, as the UV mapping of the texture is a bit easier.

The line-polys should be relatively easy. It's the uv mapping of the textures that is goind to be hard.

Dick

[SdC Redux]

tonight I managed to get cfs2autocoast to poop out its first VTP1 ASM file containing 24000 poly's that actually compiles and shows up in LWMViewer and CFS2 without crashing. Only problem is that the textures aren't showing up yet; just the familiar "missing bmp" blank blocks.... but we're getting there!

[SdC Redux]

Rhumbaflappy tested the first cfs2autocoast generated BGL and got it to work, so: for the first time we can programatically create VTP1 scenery without using ground2k!!!!!! Champagne moment!
For the moment it's only for LOD13-sized tiles, but this is an important step towards creating lines and other shapes.

[rhumbaflappy]

Very nice! It looks like you've turned the corner on solving this.

Dick

[crashaz]

excellent news! My dream of a redone Philippines may yet still be possible! :wavey:

[SdC Redux]

excellent news! My dream of a redone Philippines may yet still be possible! :wavey:
Hey crashaz, you know what would really help is if you found some good existing fs8/fs9 freeware LWM of that region to convert.

[crashaz]

Hey crashaz, you know what would really help is if you found some good existing fs8/fs9 freeware LWM of that region to convert.


Ok will get on the lookout.

[rhumbaflappy]

Hi Sander.

Any more news on ypur progress?

Dick

[SdC Redux]

Hi Sander.

Any more news on ypur progress?

Dick
Not really news, but I am making steady progress. I'm pretty much done fooling around with the cfs1 textures; my vtp and asm classes are now strong enough to get back to the line polygon and LOD13 clipping routines. I've discovered that I can use .NET GDI+ drawing2d classes to do most of the math work for me fortunately, but even than I have to do some "fixing up" and exception handling, and it makes it more difficult to do the texture mapping...

[SdC Redux]

Not really news, but I am making steady progress. I'm pretty much done fooling around with the cfs1 textures; my vtp and asm classes are now strong enough to get back to the line polygon and LOD13 clipping routines. I've discovered that I can use .NET GDI+ drawing2d classes to do most of the math work for me fortunately, but even than I have to do some "fixing up" and exception handling, and it makes it more difficult to do the texture mapping...

The polygon-from-line creation routine is now pretty much done, with simple UV mapping. I couldn't use the .NET classes for it (graphicspath.widen) because it causes artifacts (a special funtion "widenpath" is implemented to overcome that in .NET framework 3.5 WPF, but that would be a hassle to upgrade to) and it wouldn't handle the UV mapping anyway. So I managed to do it with good old SIN, COS, TAN and PI....
Next step is transport those polygons to the ASM file. If that works for polygons that are within a single LOD13 area, I will need to enhance that routine for clipping the remaining poly's that are spread over more than LOD13 area. As soon as that is done, we have a new compiler!

I've also taken a look at SRTM SHP files and SBuilderX. Good news there! From SBuilderX these can be exported as "SBuilderX SBX file". This contains both the Water poly info and Altitude, so it will be possible to create Shorelines, Water and Flattens from those files directly! Because most oceans are at altitude 0, it is reasonable to assume any water at higher altitude is "inland", so we can make a difference between shorelines with sand and perennial.

[rhumbaflappy]

Hi Sander.

Good news. :)

The UV mapping/splitting of the line-polys is at a 1:4 width to length ratio in the defaults. MS kept each line type a constant width. Then the shores looked OK without much distortion.

We could have lines of varying widths that would present a challenge for the texture mapping and the splitting, unless you force the lines to a constant width.

Concerning the SRTM waterpolys... they have a FACC atribute that defines if the poly is a lake or ocean. Ocean = BA040 and Lake = BH080. If you have a GIS program ( SAGA is free and powerful ) then you can separate the two into different SHP files and save some work. Also, for mostly ocean tiles, you can extract the main ocean as a separate SHP file, and it islands ( holes ) will then be left. With SAGA you can merge polys, etc... And it has a very good raster to line function.

http://www.saga-gis.org/en/index.html

Dick

[SdC Redux]

Hi Sander.

Good news. :)

The UV mapping/splitting of the line-polys is at a 1:4 width to length ratio in the defaults. MS kept each line type a constant width. Then the shores looked OK without much distortion.

We could have lines of varying widths that would present a challenge for the texture mapping and the splitting, unless you force the lines to a constant width.
My routine already takes the SegmentWidth parameter, that is included in both SBX and BLN files, into account for calculating the offset to the original line, and that is easily overridable to fixed width, so we can play around to find out which works best.



Concerning the SRTM waterpolys... they have a FACC atribute that defines if the poly is a lake or ocean. Ocean = BA040 and Lake = BH080. If you have a GIS program ( SAGA is free and powerful ) then you can separate the two into different SHP files and save some work. Also, for mostly ocean tiles, you can extract the main ocean as a separate SHP file, and it islands ( holes ) will then be left. With SAGA you can merge polys, etc... And it has a very good raster to line function.

http://www.saga-gis.org/en/index.html

Dick
Good to know.
Cheers,
Sander

[SdC Redux]

The transport of the line to the ASMfile as polygons, is now in place and working, so I can now create a BGL from the original line info, and the line is exactly in the correct place with the correct width.
Next on the list is to complete the UV mapping routine so the textures show up correctly, that should not be a big deal.
Then the "clipping" routine to break up the poly's that cross the LOD13 grid. That is the final "tricky" part, that wil fill in the missing poly's as shown in the screenshot.

[SdC Redux]

This weekend was spent on a lot of plumbing in the application code. Redesigned the GUI to improve productivity.
Also discovered the Cells have to be sorted NW/SE; that's done now. Also the Boundary coordinates the BGL header needed to be set correctly, that is done now as well.
All in all, I estimate I'm about two weeks away from having a working and usable compiler....

[MaskRider]

Way to hang in there Sander. Very exciting.

[UncleTgt]

:bump:

...just wondering ...

[rhumbaflappy]

Hi Sander.

Any progress with the VTP1 lines and polys?

Dick