River flattens...any cure yet?

[Guest PaulL01]

Hi all,Just curious if there has been any break throughs that I missed as I have been "away" for a while and last I knew the only way to remove a @#$% river flatten in a given area was to remove the river flatten from the whole planet...Ugh!I have a great mesh for my local area but the default river data is so bad!Thanks for any help.P.S.I guess I also should ask...any news on removing coast/lake flattens?

[rhumbaflappy 113]

Hi Paul.By rivers, I assume you mean the VTP2 streams? They are the ST*.bgl files.Their flattens wouldn't be bad, except they are all in the wrong location, and excluding them won't exclude the flattens.The default BGLs are arranged in sizes that are approximately LOD5 in size. LWMViewer can detect and load the appropriate files... and the ST*.bgl is for the VTP2 streams.The actual rivers are LWM polys, and they have elevation assigned to all verticies in FS9. They are also in LOD5 chunks.The best cure for all the flattening is to rewrite the data for the whole LOD5 area, and replace the ST ( streams ), HP ( water/land polys ), HL ( shorelines ). There has been a scheme proposed to replace only relevant parts of the default LOD5 bgls, but then you are combining good data with bad... and may have competition with other designers for the same parts. My process depends on large amounts of data, and is somewhat automated... so a single LOD5-sized area is no more trouble than a single LOD8 cell.The addition of the commercial USARoads means I don't need to add them to my sceneries.I'm actually getting pretty good at converting the US TIGER data, and can convert an entire LOD5 area in about 2 weeks. My water is mesh-clinging, but with a good mesh, it's not too bad. Some water will climb the lake banks. I use Ground2K4, and could enter elevations for lakes, if I had the patience. Streams and shorelines line up pretty well.The problem here is that I'd need about 4 years to convert the entire US! Something I'd rather not get into.For the rest of the world, good data for free ( or cheap ) does not exist. :(Dick

[Guest PaulL01]

Dick,Thanks for the info, I guess what I need might be "easy" since I am going to cover a 1400 sq-ml area with custom texures and expose the water via the alpha channel I just want to remove everything that is having any effect on the custom Lod10 mesh ie: river & poly flattening/coastlines, so I dont really need to re-right most of the data, just remove it? Or will the extent of my photoreal boundries cause a problem?Lastly, can I use Ground2k4 to remove what is needed?your help as always appreciated.

[rhumbaflappy 113]

Hi Paul.The ST* bgls could be VTP-excluded with DefAreaV2.0 ( defarea20.zip ) or Ground2K4, both by Christian Fumey. Or the terrain.cfg file could be altered to change the stream textures from "offset=-10" to "offset=flat" ( my actual recommendation ). If the mesh is good, there is no sense in making the streams -10 meters!Or you could delete or rename the extension of the offending ST* bgls.The HP* water polys could be altered by the process described earlier ( altering the original files ).Or you could alter the original offending HP*.bgls by processing their code through Edgar Knobloch's "cfs2conv2.zip". That changes the code to mesh-clinging water. Their shape and location are still wrong, but they don't flatten, so your photoreal should show fine. The rest of those HP* area will look odd, but they are odd to begin with. :)Or you could try to rework the water polys to their actual shape and location. That would not be easy unless you were well versed in Ground2K4, and had access to the data. AutoASM, by Chris Wright was going to make this process easier, but he hasn't released his program, yet. Slartibartfast, by Jim Keir was also going to automate the creation of water polys, but his program is also in testing stage.----------------------------------------------------To recap: the ST* bgls can be brought under control by the terrain.cfg change, and there's no reason all simmers couldn't make that change. Dropping the streams -10 meters was a bad idea, and only an attempt to cover up MS' use of poor data.The HP* bgls are harder to solve, and the easiest solution would be to simply rename their extension to deactivate them as needed. They are wrong, anyways. Perhaps another brave soul will be able to fix them if you gave the bounds of the scenery. Or perhaps you'd like to replace them with the code from Edgar Knoblock's "cfs2conv2.zip". ( That would require the use of Jim Keir's LWMViewer to disassemble the code, then use Edgar's converter, then reassemble with BGLC and the needed tdfmacros ).Dick

[Guest PaulL01]

Thanks for the reply Dick,>Hi Paul.>>The ST* bgls could be VTP-excluded with DefAreaV2.0 (>defarea20.zip ) or Ground2K4, both by Christian Fumey. Or the>terrain.cfg file could be altered to change the stream>textures from "offset=-10" to "offset=flat" ( my actual>recommendation ). If the mesh is good, there is no sense in>making the streams -10 meters!>>Or you could delete or rename the extension of the offending>ST* bgls.OK, sorry what do the ST*bgls do? Do the also flatten?>The HP* water polys could be altered by the process described>earlier ( altering the original files ).>>Or you could alter the original offending HP*.bgls by>processing their code through Edgar Knobloch's>"cfs2conv2.zip". That changes the code to mesh-clinging water.>Their shape and location are still wrong, but they don't>flatten, so your photoreal should show fine. The rest of those>HP* area will look odd, but they are odd to begin with. :)Not familiar with the term "mesh-clinging water" but my mind is drawing pictures... and could you just describe a bit about the "rest..area will look odd" part please?>Or you could try to rework the water polys to their actual>shape and location. That would not be easy unless you were>well versed in Ground2K4, and had access to the data.I have HY.SDTS and Dem.SDTS data...would that do?>AutoASM, by Chris Wright was going to make this process>easier, but he hasn't released his program, yet.>Slartibartfast, by Jim Keir was also going to automate the>creation of water polys, but his program is also in testing>stage.>>---------------------------------------------------->>To recap: >>the ST* bgls can be brought under control by the terrain.cfg>change, and there's no reason all simmers couldn't make that>change. Dropping the streams -10 meters was a bad idea, and>only an attempt to cover up MS' use of poor data.>>>>The HP* bgls are harder to solve, and the easiest solution>would be to simply rename their extension to deactivate them>as needed. They are wrong, anyways. >>Perhaps another brave soul will be able to fix them if you>gave the bounds of the scenery. >>Or perhaps you'd like to replace them with the code from Edgar>Knoblock's "cfs2conv2.zip". ( That would require the use of>Jim Keir's LWMViewer to disassemble the code, then use Edgar's>converter, then reassemble with BGLC and the needed tdfmacros>).>>DickPlease Dick, if you dont mind give me a brief rundown of what each BGL types does/does not do...PaulP.S. I am willing to pay $$$ to have this done...it is a 1200 sq mile area...For what its worth...