Re: WS3.0 Philosophy and Status

Hi everyone,

Anyone interested in seeing the latest run of WS3.0 NLCD from Adak 
Alaska and a test from Panama City Florida.

https://forum.flightgear.org/viewtopic.php?f=5&t=41903&start=135

I love the shader work when you have a slope increasing in elevation on 
the coast line. We need more shader work on all boundaries as well as 
regional texturing. Clipping the coastline with OSM vector is working 
well on its own. The procedure that basically shrinks the lakes and then 
clips those with OSM water vector shapes is hit or miss on the NLCD 
depending on a few variables. But when it works it's nice. I'm 
interested in looking at the vector source James pointed to and see if 
it has any better fidelity that of OSM.

Stuart discovered the default tile size osgdem is creating is 256x256 
which we also discovered is not even as hi res as the line data (roads) 
we are draping in the scene. I am generating hi-res rasters from NLCD 
and Sentinel2 they are considerably higher res than genVPB.py 
(osgdem.py) is capable of generating at the default 256x256 tiles size. 
That is where the stair stepping is coming from on all the land class 
boundaries. Thus the need for shader work to smooth those boundaries.

Stuart also figured out that changing the default tile size to 1024x 
allowed osgdem output to realize the higher resolution of the rasters I 
am creating. Look at the bottom image in the forum post link above to 
see the difference. We both notice very little if any change in the 
rendering difficulty between the two, but the storage size of the 1024 
tiles was considerably more.

An interesting observation, when using the OSM vector data clipping for 
coastlines or lakes, it clips to the base resolution of the raster. I'm 
not sure how to explain this technically, but here is what I noticed. It 
appears that when clipping with the OSM vector data at times it will 
leave a perfectly straight edge, I assume the resolution of the vector 
data. Yet there are areas that look like they are stair stepped at the 
same resolution of the higher res raster, same as if running the high 
res raster using a 1024 tile size.  But this happens with the high res 
rasters run at the default 256 tile size. If you look carefully at the 
images of Adak you can see areas that demonstrate what I am talking 
about. That scenery is processed high res NLCD ran at the default 256 
tile size.

So I think there are at least a few options. Clipping high resolution 
rasters with higher resolution vector data works, even with the 
performance friendly 256 tile size, adding shaders to all boundaries 
with this would be ideal. I'm not convinced though that we might not 
want to bump up the default tile size. That would need some extended 
testing.

Stuart, I can't just use the --tile-image-size switch. It is failing to 
generate complete scenery and crashes when trying to load. It goes 
through the motions of creating the scenery, but looking at the data 
shows it is failing to gen some LOD level. Did you have to do anything 
else but use the --tile-image-size switch? I am wondering if I need to 
use a much smaller area and that it is memory issues?

Wayne

-------------------------------------------------------------------------------------------------------------------

On 5/28/2026 8:12 AM, James Turner wrote:
>
>
>> On 28 May 2026, at 12:20, Curtis Olson <[email protected]> wrote:
>>
>> This approach does have all the expected downsides ... no lighting, 
>> airports/taxiways get really blurry when you land/taxi, weird stuff 
>> happens around bridges and tunnels, all the shading is cooked into 
>> the sat imagery, etc. and if one of your online data sources goes 
>> away you have to scramble to find something similar …
>
> Yeah, the cooked shading / lighting is really what I find tough about 
> this solution, it’s really difficult to model any effect on the 
> terrain (weather, time of day, season) when the lighting was baked in. 
> What Stuart and I have discussed is using slippy tiles for the 
> landcover data: then we’d have something like SRTM locally but the 
> landcover (etc) encoded in tile data we could stream, especially now 
> we know the CDN impact is likely tolerable.
>
> Kind regards,
> James
>
>
>
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel