(My only familiarity is with some underlying maths, and what might be conceptually possible)Īs far as I see, distance field data might better enable: transition influence (e.g. AIUI Glow effects use binary morphological operators that should(?) be commonly available image processing effects, even if glow/distance field effects are not. The concept is inner/outer glow effects create distance fields from any shape segmenting regions (e.g. Just a thought (if I've read this thread correctly, and from a conceptual view of what might be of possible assistance):įound this, when looking at a way to generate distance fields from a black&white street pattern, to better light roads,intersections, and near by city blocks from space. Is the plan to have metadata stored in raster files as a type of distance fields? Jeff has implemented airport flattening already as well. I also really like the layering they do - they are also working on road flattening as we speak. Their LOD is very smooth ( some examples look like they don't create big enough skirts, though ). Here's the example ( including hardcoded local path ) I wonder if they will add that to the data repo eventually.Ĭheckout their screenshots of trees / grassy areas around September 2015: Unfortunately, none has been released yet, so I was unable to get the splat global coverage layer working. ( although photoscenery is still an option ) They seem to be moving a bit away from pure photscenery, and moving in the same direction we are for next gen scenery. I've updated my osgearth repos with Jeff Bigg's latest, and I think there's a lot to be gained by taking a closer look at what osgearth enables. I will continue this work, but I also think we should discuss osgearth some more as well: I've been working a bit more on this, and I now have the ability to use different scenery paths for custom scenery ( or the ability to test small scenery updates without modifying the main terrasync dir ).
Scenery generation would consist of re-rasterizing the affected bounding box. Save in vector format, which could then be merged into the official postGIS database.
Scenery editing would be reduced to editing shapefiles in QGIS, and setting each shapefile feature to the correct landclass ID, and smoothing, etc. I also want to multthread the operation, because as it stands, rasterizing actually takes longer than ogr-decode / tgconstruct from terragear. gdal_rasterize in particular, is not very efficient.
Once we get some test area complete, I will probably create an executable instead of the script. it's just a script calling GDAL executables. It can also encode a landclass ID, and smoothing parameter. For each landclass, it encodes 3 channels - red, green, and blue, so I can test without a shader, first. Yes, I'll post my test script that generated the raster images on the wiki this week.
0 kommentar(er)
