Posts by ozhomeroz

Those look like no data pixels, I just wrote a post about using the Reclassify value tool to fix no data.

Fix first no data before any thing.

Test and if spikes remain then try convert data type.

Start with a new untouched source file

Start with a small section that fits within a Level 12 grid as shown by the Aero Scenery Tool to avoids mask which this probably isnt, but to be sure its best for now till we narrow down the problem.

Fix no data before converting data types.

This is what I suggest you try.

Sweet

Sydney mesh is coming along nicely

Spikes, the bane of elevation mappers every where, well not any more.

One cause of spikes is due to elevation maps having a "no data" pixel used for areas like the ocean.

If your coast line has spikes this is the cause, but luckily its easy enough to fix.

As a elevation mapper you will need to download and install QGIS, a free and totally great tool for us, so get it.

One you have done that, Open your elevation file into QGIS and select it.

[Blocked Image: https://i.imgur.com/axSMd6Q.jpg]

To fix the "no data" pixels we have to identify which value your map uses, so double click your layer to bring up its properties.

Under "Bands" you will find your "No data value"

[Blocked Image: https://i.imgur.com/Wy4flBb.jpg]

In this case the no data value is -9999, we need to remember this for later.

Now we have to tell the game that pixels with a value -9999 is no data represented as 0/0.

So onwards.

Click on the following Menu's: SAGA then "Processing" and then "tool box"

Next select "Raster Tools" and then "Reclassify Values (Simple)" Click on the button with the three dots for "Lookup Table"

[Blocked Image: https://i.imgur.com/56SgkwU.jpg]

Click "Add Row"

Enter the No Data value form earlier, which in our case was -9999 and well will replace this with 0/0 no data as shown below.

[Blocked Image: https://i.imgur.com/UVuF9qF.jpg]

Click OK and then click run.

Next export this new layer as normal. And geoconvert without spikes caused by no data pixels. Enjoy

Spikes due to Pixel data type use the Raster > Conversion > Translate tool.

This guide is intended for users who have at the least read ans understood the elevation guides by Qwerty42 and Crispy136.

Sydney before

[Blocked Image: https://i.imgur.com/dfwUEnD.jpg]

Sydney after

[Blocked Image: https://i.imgur.com/XNcAkCG.jpg]

Well Micheal, since starting this elevation caper I gotta to admit theirs a bit to it and I'm still learning.

Till I get more mastery of the elevation process, Scotland will have to wait.

I figure that its better to get the process streamlined so that at a later date I could do Scotland proud with an greater efficiency.

Doing it now would be a slow process process, plus I'm already engaged on another project...

SYDNEY, my home town.

Let me tell you a bit about my Sydney plans and some workflow.

The Sydney master plan is to use a 30m SRMT Regional Base map (srtm_67_19.zip) converted at level 11.

Also I use higher resolution 1metre and 2 metre maps at POI and airports converted at level 12, 13 and 14.

As I get better at this I will share what I have learnt in this thread.

QGIS is awesome!

If your interested in Scotland, save me some work and tell me of resolution elevation is available for Scotland.

I would seek out SRMT maps as an level 11 base mesh, they cover a large area.

I just gotta figure out a way to deal with no data and coast lines effiecently, which BTW Sydney also has.

Yes this so much !

Cant you throw us a beta pretty please, would help with my Sydney mesh I'm building.

For Science

This new method is working splendidly for me, its very fast and best of all no spikes yet.

Here's Pictures of the same location, Canoe Creek proper using different elevation meshes

Default

[Blocked Image: https://i.imgur.com/0LoZ2jz.png]

30metre SMRT with Colo River modded by hand to stop it flowing uphill

[Blocked Image: https://i.imgur.com/IqQcmXf.png]

2m ASC elevation from ELVIS standard but converted in QGIS to 16int

[Blocked Image: https://i.imgur.com/FBWSNVu.png]

I have some back story before I tell you some cool news.

I got into elevation maps at first because the airports around Sydney, such as as Camden, Bankstown and of course Sydney were barely usable due to prop strike due to elevation issues. So I wanted to flatten taxiways and thus began my wonderfull journey onto elevation. Upon Seeing Colo River I thought, That's not right!!!

I previously wanted to map Colo River in higher elevation detail since it is sort of famous as a Wilderness Gorge with High Cliffs, so after downloading all the 1 and 2 metre files stopped that project. (Until now, but its a big job)

So until our recent discoveries just now, I used a 30metre SRMT map, which had errors that needed to be fix, by hand with GIMP as its the only way I knew at the time.

These errors mostly comprised due to my newness things as no data values, masks in coastal areas and errors inherent in the SRMT data around hilly terrain.

I was thinking about resuming my High resolution elevation Colo Project and tested to see if I could use different levels for different elevation maps and it turns out you can.

I used my 30 metre modified SRMT and geoconverted to Level 11

then I used my 2m High Res ASC and geoconverted to Level 12, 13 and 14

I placed the result of each in diferent Folders and place both in elevation\images

I could see the both the SRMT 30m and the smaller 2 metre mesh in game.

Awesome

So on to the Final Phase

May even have to built a mesh for that Sydney Cultivation I heard about.

With high res Air Races through Colo River.

I already have a hack job ready, but that Sydney cultivation looks good, may have to start a fresh mesh so its perfect.

Dudes I think I cracked it

Let me show you the results, then explain

The first four pic are all taken from exactly the same spot

The Location is Colo River, NSW, Austrailia near Syndey, close to Canoe Creek specifically, seemed like a good place to demonstrate the differnence Hi Res meshes can make.

Also demonstrates SRMT is not great around hilly areas.

https://i.imgur.com/2xnuswD.jpg

Default Mesh from IPACs

https://i.imgur.com/vpLWzM8.jpg

Seems the 30m SRMT mesh that I installed has slight difference over the default. Maybe IPACs compressed it to save space if their mesh is based on SRMT.

I heard some where IPACs uses SRMT as a base

My Guess.

https://i.imgur.com/eIP6789.jpg

Now Colo River is the most pristine Wilderness River in all NSW they say, so it can not have uphill flowing rivers I fixed that in GIMP, colour picker and pencils and some hours. Good thing elevation meshes convert fast and I love Colo River.

I have not published my mesh yet coz its not totally ready, Doh major airports are flattened, colo river is done and it includes SYDNEY.

Now the Previously Spikey 2 meter 64 bit map converted to 16 bit in QGIS

https://i.imgur.com/ySflCdj.jpg

I been to this place many times and this looks legit, 2 metre Hi res map with out spikes.

Next downside

https://i.imgur.com/FSixGqB.jpg

Where the 2 metre map meets the default map up close and personal, Mmm

https://i.imgur.com/pm8Gs5a.jpg

From up here not so bad I think.

And the solution is easy, thank goodness for my Legendary Google noob skills

SOLUTION:

1)Open your High Resolution file in QGIS which is free to download, Pro Tip search it on google.

1a)Grab the geotif to drag to into QIS

2)Select the new layer

3)At the top of your screen, find and Select RASTER, then CONVERSION and finally TRANSLATE

(Im shouting coz Im so happy! )

4) Use the "Output Data Type dropdown" to 16int

5)Dont forget to "Save as File", Run it, yes really its done!!!

Convert as Normal

* I advise against changing CRS as you will get pillars due to the image being rotated and masks and some stuff I don't fully understand.

Anyway pillars are bad and much more perceivable than a slight in-perceivable change in orientation change due to CRS

My comment on where High Resoultion mesh meets lower resolution or deafualt mesh is that you oversize till unnoticed just like othro.

Agreed, I'm far from finished, still have some issues to figure out.

OK the TLDR version.

To remove spikes from your add on elevation geotiff maps.

1) Open geotiff in QGIS, check properties and then source, if data type is not 16bit integer, that the cause of your spikes. 32/64bit Data type causes the spikes.

2) To fix open your spikey geotiff in GIMP, its free to download and use. And the instructions are simple even I could do it. Here's how.

Once opened in GIMP at the top of the screen click the following menu: Image>Precision and choose 16 bit Integer.

Then export your new 16bit game comparable geotiff by clicking the File menu and selecting "Export AS". Give it a name and your done, geo-convert as normal. Test it.

If the map is too high or low compared to the surrounding terrain adjust the brightness of your geotiff in GIMP. Brighter is higher, darker is lower in height.

3) Next you may have to match the height of the new terrian with the underlying default mesh.

Open the geotiff in gimp, Select the "COLOR" Menu, then select "Brightness-Contrast".

Adjust the brightness in small amounts, Export as like in step two and geoconvert as normal.

You may have to repeat step 3 a few times untill the height of your added mesh matches that of the surrounding terrain.

Enjoi.

More progress, at this rate I will be waiting a long time for that nap, anyhow I digress.

I have made some discoveries and need some advice .

One thing I noticed was that the edges where the two maps meet is not parallel, Mmm.

I imported the original ASC file to Qgis and changed the CRS from "EPSG:28356 GDA94/MGA 56" to "WGS84:4326" which to my knowledge the game uses.

Any one know how to change the projection angle as this info is available in a accompanying PRJ file.

Picture below shows how the map edges are not parallel.

[Blocked Image: https://i.imgur.com/VOqYE3w.png]

Also I think I have discovered the cause of the few remaining spikes. I noticed that their was a gap in places between the mesh I added and the under lying default mesh. Funny thing is the height in the gap is lower than the default mesh terrain.

[Blocked Image: https://i.imgur.com/EsXsfkk.jpg]

Only some sides of the added meshes have gaps, and this is where the few remaining spikes appear.

On sides of the mesh without gaps there are no spikes.

So I believe changing the projection angle as stated previously would remove these gaps and thus the spikes as well.

Another dirty method I will try is adjusting the extent in the FTW and mesh_conv.tmc files to remove the gaps and the spikes.

Don't know if it will work but until I discover how to change the projection angle to remove the V shaped gap between the two maps, its my only shot.

Another Picture of those gaps between added mesh and default mesh

[Blocked Image: https://i.imgur.com/ZVvCxC2.jpg]

So now I believe that the problem of spikes has been solved apart from those gaps which are due to the projection angle, as the added elevation map was of Australian CRS namely EPSG 28356 GDA94/MGA Zone: 56

I believe that if you are using a elevation map based on the same CRS as the game namely WGS84:4326, you will not have these gaps or projection angle issues. And thus have to spikes as well, Yay

Time for that nap.

Quote from Trespassers

How to stop then the mesh without causing walls ?

Darken or brighten the image in GIMP untill it matches the terrian height as described above.

Hello chaps

I have been working on that spikes issue in elevation meshes and it seems my hypothesis that grayscale colour depth May be the issue indeed.

My thinking was that the game and geoconvert only supports 16bits per pixel for height information.

Often higher resolution elevation meshes use more bits per pixel for height information.

For example 5 metre meshes I have tested use 32bits per pixel

and 1 metre meshes I have tested use 64bits per pixel.

Basically if the height information per pixel is not 16bit the game cannot interpret the height and thats when you see spikes.

To test I converted a 1 metre 64 bit per pixel mesh data of Camden airport near Sydney

The results were the usual spikes.

64 bit per pixel elevation map

https://i.imgur.com/jl5jk7w.png

Usual result SPIKES, Nothing to see here.

Next I used GIMP to change the geotiff from 64 floating point to 16 bit integer precision per pixel using the IMAGE > PRECISION menu.

With the result below clearly showing terrain rather than spikes, but still at 20,000 feet.

64 bit per pixel elevation map converted to 16bit integer in GIMP

https://i.imgur.com/3buOa2K.png

I'd say that this is progress and although clearly not the complete solution, I think its safe to say that my original hypothesis is partially correct.

The game and geoconvert only understand 16 bit per pixel for height data precision, and 32/64 bit height data found in high resolution elevation maps results in spikes.

BTW : this is two maps side by side, will test with a single map. Also maybe if I darken the colours in GIMP I can make the terrian lower to be level with the ground. Im no GIMP expert so won't bore you with the details but will update when theirs progress to report.

Maybe after my afternoon map.

PS: Why are my images blocked?

I decided to forgo my nap and instead used the Colour > Brightness menu in GIMP to darken the input elevation maps.

I darkened the left and right side maps by different amounts -.100 vs -.110 just to see the difference in height of the two maps I used.

The results, show that indeed the terrain has been lowered closer to ground level.

https://i.imgur.com/05zARtD.jpg

Those odd spikes I need to think about doh I'd say I'm making some progress on the spikes issues.

PS: Can I get my images unblocked please.

Quote from TomSimMuc

I think it is better to discuss this subject in the existing Mesh Creation Issue thread:

Mesh creation issues

Indeed

Just answering Greg's question as best I could.

My guess is its related to the number of bits per pixel used by the mesh which geoconvert needs to "convert" to make it readable by the game engine.

I have done some research using QGIS and discovered/heard that the game engine default mesh is based on SRMT mesh which use 16bit per pixel, where as many 5 metre meshes use 32bit, and 1metres meshes I have tried use 64 bits per pixel which geoconvert does not support currently.

IMO

Anyone and everyone feel free to correct me if I am wrong, especially if anyone had successfully converted a mesh with Data type 32 or 64 bits per pixel, because I want to know about it, to debunk my hypothesis on the cause of spikes.

Spikes, Its a problem, we need to find the cause so that ultimately a solution can be found. My two cents.

Thanks Nabee,l great help this software is.

I mostly use the tool for placement of trees and buildings, save and then copy the code into my own tocs.

I have more controll that way and avoid any limitations troubles saving larger files.

Yes using it very much thanks Nabeel

Reason I ask is I would like to try and use a 30 metre SRMT Level 11 Regional mesh with 5m urban and 1 metre airport meshes at higher levels say level 13 and 14.

May have to trim to avoid masks.

But what about masks where there are no adjoining areas, like an island or airport doesit matter? Masks won't interfere right?

Because level layers

For Science

Yeah Yikes, Spikes read above

Pretend the othro boats are a water reflection of the 3D boats

Kinda look like that in the picks

Hello elevation map devs guys and girls.

I have an idea of what may be causing spikes in user made elevation meshes imported into the game, and would like to share this idea to see what others though about it.

The Idea:

Aerofly has difficulty (spikes) interpreting higher resolution elevation data mesh because they are encoded using more bits per data pixel. Let me quickly explain.

First some background.

The Principal:

Much like in computer graphics where higher colour resolution/fidelity requires more bits per pixel to represent encoded colour information.

Aka:

256 Colours requires 8bits

65536 Colours requires 16bits

16.8 million Colours requires, etc

Same thing applies to height information in elevation maps,

Higher resolutions require more bits to encode to data.

I realise that resolution regarding elevation maps refers to Metres per pixel.

I thought that well, as resolution increased in terms of metre's per pixel perhaps height resolution per pixel did as well.

To test, I loaded 3 elevation maps into QGIS and checked their properties, and discovered the following:

30 Metre SRMT mesh uses Data type: Int16 - Sixteen bit signed integer.

5 Metre Sydney mesh uses Data type: Float32 - Thirty two bit floating point.

1 Metre Camden Airport mesh uses Data type: Float64 - Sixty four bit floating point

Ok so now we can confirm that elevation maps can be encoded with 16/32 or 64bits depending on height resolution

So the game uses a 16 bit height space and the 32 and 64 bit height data is outside this 16 bit space. So spikes IMO.

About the Spikes:

I read on the forum (can't link, the forum is fluid) that the default IPACs mesh is based on SRMT data, lets say 16bit/30 metre data, not sure but lets say as the principal still applies.

The spikes are due to geoconvert being unable to interept non 16bit SRMT height data such as 32 and 64 bit height data found on higher resolution elevation maps.

This maybe due to IPACS wanting to keep elevation data size smaller, as file size increases as more bits are encoded in each pixel.

Solution:

If this indeed true, cant do much till geoconvert is updated with the ability to convert/compress the 32/64 bit height data into the 16 bit height space compatible with the sim.

Edit: Or maybe this can be done in GIMP prior to geoconverting, Hint Gimp dudes hahaha

Edit 2: Mmm or use QGIS to do it. Mmm

What do you guys thinks?

Man you are awesome, so fast making them buoys

As for the Jetties, I did a search on google, and found some free ones but I'm not sure as to their suitability, https://sketchfab.com/tags/jetty

I heard about a site called 3dwarehouse.sketchup.com from these forums, where many people download free models for buildings for example.

Would that site have Jetties, Peirs or wharfs suitable.

Im not a 3D artist, more an idea's man with an IT background.

I have an idea that the stuttering is caused by the large number of boats, especially if they are .tmb and not xref due to higher over head.

To test, I suggest replace the boats with xref cars, just to test.

If the stuttering does not occur with 30 or more xref cars, then the jetty is not at fault but rather the boats are. In my opinion.

Ive read that xref objects have a much smaller memory foot print.

Just my thoughts