• 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.

Bulk Process Night light Ground Splash Texture

Messages
596
Country
us-california
I figured out a cool technique for bulk processing Night light Ground Splash Texture
It requires some manual work; but well worth the effort
As you will get lights to align perfectly to roads

The key is to sample gray scale road map, using FSET


Chris Bell

here are some examples






 
Last edited:
Hi Chris!

Are u able to give us an idea about production time per 1000 sq.km using your technique?

My opinion about the final result... I am not crazy for all those bright dots and also I don't like the highways so bright. Highways should be darker than the urban roads/streets.

I separate the urban roads/streets from interstates and highways before producing my night textures.
 
hello Gabriele and thank you for your kind words

the time it would take you to make 1k is really up to you and road density
the pics you see above have taken me no more than 3 min to splash
(i have 8 tiles covering all Israel, in the view is one test tile)

this is more a prof of concept than a refined view
i started playing with this well over a year ago
i ended up leaving this method and investing time in 3D lighting

you could use FSET's nights script as a base for more refined work

produce the gray tile, isolate the white roads with magic wand
at this point you could color your white into gray
and let FSET have a go at it as a first round of splatter
there are so many ways you could go about it
the idea is the same, gray base map and isolating colors

my hopes with posting this is we all refine this together to achieve perfection

i must agree with your initial impression
im somewhat happy with residential area splatter
not so mach with the main roads yet; but its a start

the pics above are a hybrid of scenproc lights production + new ground splash
two different processes and elements that are unrelated to each other


Chris
 
Last edited:
Hi,

If you can grab some road vector data from openstreetmap it should also be possible to do something like this. And that makes it much easier to differentiate between different types of roads.

With gdal_rasterize you can turn the vector data into a raster and then use it for the generation of night imagery. That's basically what we did for the nl2000 night scenery as well.

You could also use the same idea with polygons that represent urban areas, so that so can scatter some lights there in your night texture.
 
Thank you Arno, great idea i will experiment

if somehow we could utilize the xml output we produce with lights
it would be perfectly aligned


Chris
 
2 layers in Photoshop: roads (black) on white background (rasterized from vector - OSM or others) + aerial 1mt/pixel

Production speed: 400,000 sq.km in 48 hours

It's basically what Arno is suggesting to you.
 

Attachments

  • portland-vancouver-night-04.jpg
    portland-vancouver-night-04.jpg
    97.5 KB · Views: 631
  • portland-vancouver-night-07.jpg
    portland-vancouver-night-07.jpg
    100.6 KB · Views: 717
  • portland-vancouver-night-05.jpg
    portland-vancouver-night-05.jpg
    94.5 KB · Views: 732
Hi,

Just did some more thinking, now that I can read the raster images into scenproc for the feature detection I could probably also make a step that creates a night version of a photo using vector data as additional input.

I'll put this on the wishlist, would be a nice feature to distract me from other things already planned :)
 
lol, ;)

that would be amazing if we could use scenproc to complete the lights set

Go Arno! :wizard:


Chris
 
Last edited:
Hi,

Just did some more thinking, now that I can read the raster images into scenproc for the feature detection I could probably also make a step that creates a night version of a photo using vector data as additional input.

I'll put this on the wishlist, would be a nice feature to distract me from other things already planned :)

That would be an nice feature!

Especially if we could feed in additional images to blend together where each street light is placed as an example. Even if the output is a greyscale image would suffice. Can always tweak colors and such in PS.

Thank you for your tools and tutorials by the way!
 
just to report back, i experimented little with the suggestions above
i was able to produce a negative night image with OSM road data
i still ended up manually splashing the color with PS

the end result who'd have looked great if only i could align the night tile
not sure what i was doing wrong, everything aligns perfect in QGIS
placed raster on top of google maps layer; added roads.shp; all aligned perfect
when i compile with resample, it come out off by few hundred feet


Chris
 
Last edited:
1) check that the 2 images (raster exported from your GIS software) are the same size in pixels.
2) if not, make sure you export in ARC DEGREES both the aerial imagery and the roads. Make sure you have the same exact settings for both export.
I use global mapper and that stuff happened to me when I first started. It came out that the sh.. occurred when trying to export tiles in WGS84 but using meters as a mesurament unit. It needs ARC DEGREES.
 
ooh the little things that could some time drive you nutz ;)
TYVM Gabriele, i will try Arc Degrees now

Best regards

Chris
 
so the past two days ive been trying to get a negative image from QGIS using roads.shp from geofabric

im able to extract and apply the splash effect manually
but... i cannot get it to align properly in FSX
due to the size of roads.shp i opted to clip main roads.shp to small parts
this presented an issue since ogr2ogr doesn't know lat/long
it uses x_min x_max y_min y_max for coordinates
for those i also need to provide the Z axis (alt) which i don't know

long story short, the idea is great in concept; little tricky to achieve

i will continue experimenting with this until we achieve success

ive installed global mapper, where i was able to grab x,y coords in file property
but still no joy as the tile came out off coords




Chris
 
Last edited:
Chris is your data using pixel is (center) point or pixel is corner? Basically pixels can either have the upper left corner as the LAT/LON data starting point or the center point of the pixel as the LAT/LON data starting point.

A good example of this type of error is in FSX where the default 90m SRTM elevation data for Australia is displaced approx 45m South East. When the data was rendered the setting must have been wrong and it was rendered as pixel is corner rather than pixel is point, thus shifting all elevation features 45m south east.

I would suggest if the alignment issue is uniform distance across the dataset then it's a pixel is point/corner issue, if there's drift then it's a pixel aspect issue.

Geotiffs are much easier to work with and don't need x_min x_max y_min y_max listed in the .inf to generate the imagery as it's all contained in the header tags (i.e. TFW data that is in the header of the TIFF image).

It sounds like far too many steps to achieve something that could possibly be achieved very easily in Global Mapper.
 
Last edited:
Thx Dean
it is a uniformed distance issue from what i see
im using two corners lat/long or x,y min max


here's my FSET ini data for my test night texture tile
Code:
[Destination]
DestDir	            = D:\work\
DestBaseFileName     = Tile_3
BuildSeasons 		= 0
UseSourceDimensions 	= 1
CompressionQuality   = 100
LOD = Auto,13

[Source]
Season	  = LightMap
Variation  = LightMap
Type	      = BMP
Layer	  = Imagery
SourceDir  = D:\work\
SourceFile = AreaNight_Lp4_SnapOff_N032273576_N031275584_E034102767_E035040611.bmp
Lon               = 34.1743469238281       ;for top left and bottom right is: 35.068416595459
Lat               = 32.4599647521973       ;for top left and bottom right is: 31.4654874801636
NumOfCellsPerLine = 15625       ;Pixel is not used in FSX
NumOfLines        = 23173       ;Pixel is not used in FSX
xDim = 5.7220458984375E-05
yDim = 4.29153442382813E-05
PixelIsPoint      = 0
SamplingMethod    = Point

im new to global mapper, downloaded it yesterday to see if raster comes out different
didn't find my way around it just yet

once my shape file is loaded, what are the steps with global mapper?

i can produce a raster with GM, but i have to zoom in and clip each area manually to get a decent resolution
i concluded the above after compiling my entire shape file into raster
which obviously came out at a very low res

i didn't test a raster with a closer zoom (i will though in a moment)
as it seems too tidies of a job which defeats the merit of this thread

just to point the difference (other than quality)
i was able to divide my iCVFR Project (Israel) into 8 tiles @LOD10/Zoom-4
once FSET finished rendering these tiles (less than an hour)
i was able to simply open these in PS, isolate colors with magic wand
and create my negative very easily, once i finished editing the tile
i just reuse the ini file, dump it to resample; and process completed for all the country


Kind regards


Chris
 
Last edited:
after some frustration these were made with OSM data
i realized the issue was raster image getting clipped at the last data point
instead of my required tile specification / needs
i ended up changing the raster size file
than making up the difference in PS










it doesn't matter how mach we manually edit
if Arno can get this to work with our light xml output or roads shape directly
we can prob match colors under each light and place each accurately
the result will be much different then what we can produce manually


Chris
 
Last edited:
Hi Chris,

In global mapper you can export vectors as rasters, you can also specify a line to render as a fixed width so you don't need to zoom in and out to get the widths correct. I believe that feature was introduced in GM12.

In terms of your offset try:

PixelIsPoint = 1

in your source section and see if that fixes the offset.

In terms of simplifying your life here's what a geotiff.inf would look like for your same dataset (if you rendered as geotiff)

Code:
[Destination]
DestDir	            = D:\work\
DestBaseFileName     = Tile_3
CompressionQuality   = 100
LOD = Auto,13

[Source]
Season	  = LightMap
Variation  = LightMap
Type	      = GeoTIFF
Layer	  = Imagery
SourceDir  = D:\work\
SourceFile = AreaNight_Lp4_SnapOff_N032273576_N031275584_E034102767_E035040611.tiff

Working with BMP is far far far too much work. GeoTIFF's are a lot easier to work with as all that extraneous data is held in the GeoTIFF header.

Also a GeoTiff with Alpha Channel 1 for water and Alpha Channel 2 for Blend saves a lot of time on having to manually tell resample.exe about every single detail about your image.
 
Thx Hollywood
btw i live in Hollywood ;)
anyways; tested working with tiff, i must say that was a cool test, loved it
the only issue is i cannot edit my negative, as soon as i save it in PS
the header loses something and resample will not compile it :confused:


Chris
 
Back
Top