• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FS2004 [Sbuilder] SCASM & LWM compilation issues

mariopilot

mariopilot

Messages
141
Country
peru
Hi All! I'm attempting to generate huge vector scenery areas from GIS data.
The process is as follows:
  1. Elaborate GIS data in QGIS
  2. IMport Shapefile in SBuiolderX
  3. Export as BLN
  4. LOad in SBuilder 2.05
  5. compile chunks of data

The results look spectacular, if it was not for some compilation issues. Take a look at the following LWM BGL:

lwm_bug.jpg


There is a HUGE square that is not supposed to be there. Also, the tiny black square near the top-left corner of said huge blue square seems to contain a lot of overlapping random polys, apparently land masks since they show up green in LWMViewer. The's no land masks in the project file at all! SCASM is having issues here. I wish I could use BGLComp instead...
Any hints?
 
Hi,

Did you check the BLN file in another tool to make sure that the mistake in not yet in your input data? Or does everything look fine after importing in sbuilder?

I don't think this is a compiler issue btw. It more sounds like a bug in sbuilder while making the scasm source code.
 
Hi mariopilot.

I've had similar experiences with SBuilder9. Why not attach the BLN file ( and maybe the SHP file set ), so we can play with it. Try attaching them to a post zipped.

Dick
 
Hi mariopilot.

It appears that you have data that is less than 4.5 meters/pixel. And that just won't compile correctly.

I do have a couple of questions. How did you split the original data to eliminate the holes? Can you zip the original un-splitted data (shp file set or whatever), and attach it to a post.

What I have in mind is to simplify the data, then split it to eliminate the holes.

Dick
 
OK,
yes, the data might contain higher resoultion than that at points, but the largest problem was:

a single LWM polygon in a LOD13 cell can not have more than 317 points, according to SCASM manual. I have found one with 350... This will not stop the compiler but it will be hogwash in the entire LOD5 cell... Im pushing the boundaries here...
To solve this I cut it in QuantumGIS, so now I have two...
how did I get rid of holes is a complicated matter:

  1. crop part of worldwide OSM vector file
  2. generate a centroinds layer
  3. make a triangle mesh out of the centroids
  4. add polygons when/if the triangle esh does not cover the vector coastlines
  5. subtract to this your ground polygons
  6. superimpose a vector grid to sectorize

This results in a line cutting through every single polygon, and TaDa, no more holes! Drawback it might generate points really close together.... It will be much simpler to use land mask polygons if I could tell FS "flatten the rest!"
I can solve minimal problems by hand... but if I apply a simplifying command in QGIS I lose all the beautiful detail I'm doing this for... (feel like giving UTE a run for their money? :duck:)
Next up is lakes and rivers (another LWM hell) then roads, railways, etc... VTP on the other hand works flawlessly and incredibly simple!
 
Thanks for sharing your hole elimination process... I thought it might involve centroid points. :)

Good detective work finding the poly with too many points in the LOD13 area.

Dick
 
Thanks a lot!
A little update:
I decided to simplify the geometry a bit, although it is now reduced to about 10m/px (0.0001 deg, as low as the QGIS function "simplify" goes)...
This reduces greatly the number of error occurrences... and I can safely use the "SNAP to LOD grid" function in SBuilder, to furtherly optimize geometry. This is the main error reducing step. It just does what I want eliminate points that are too tightly packed without generating gaping holes in the geometry, something that QGIS is excellent at doing (it is excellent for normal shapefile geometries, e.g. holes/rings, but not for polygon meshes, it will simplify the polygons and generate holes between the "contact surfaces" between the polygons) ... There is however a small bug in SBuilder that will force us to check the results and act accordingly: a point located exactly on the limit between a LOD13 cell and another will fill one of the two cells (or both) with water... to solve, nudge the point just a tad away from the cell limit. this will not alter geometry if you move it less than 4.5m away. do not reapply "snap to LOD21" or you will reset the error condition. Move with logic, so not to leave a micro-area of the polygon on one cell.
With geometries like these there may always be a topographical error somewhere you may need to fix as well.... but now I can proceed fairly fast on making large areas with a low enough error content (the ones that slip by my visual inspection with LWMViewer!)
 
You must log in or register to reply here.
Back
Top