Basic Terrain Size Concepts

It seems that I am constantly asked this same question every week, so I thought I would make an explanatory blog post about it.

Where most people seem to fall down on terrain software, is a larger heightmap value directly equates to a larger area of land, and not to a higher detail version of the same terrain mesh.

It is a common misconception that changing the width and length resolution of the heightmap to a larger value somehow makes it shorter in altitude. It doesn’t. A larger heightmap size directly equates to a larger area of land, not a higher detail version of the same terrain mesh. That is simply an optical illusion of ratios. Basic math proves this.
What you are creating is a larger area of a constant altitude range. Many people seem to fall into this same false view of how 3D terrain worlds work. If I look at a 1024 heightmap versus a 4096 heightmap, both of them with the same height mountains on them, both of them at Zoom Extents in the editor, well of course the 4096 heightmap will visually appear to be one quarter the altitude height range, this is because I am zoomed out four times further. I am looking at four times as much width area with the 4096 heightmap, so of course the height will be one quarter as much.
If I take a digital elevation model that is 1 km by 1 km that contains mountains that are 1 km high (width:height ratio 1:1), then I take a larger piece of that same digital elevation model, say a 2 km by 2 km piece, well the mountains will still be 1 km high (ratio 2:1), the mountains will not somehow double in height just because I have taken a larger area piece of that same digital elevation model. Likewise if I go even larger, a 4 km by 4 km piece of that same digital elevation model, then I will be getting more mountains in my piece since the area is larger, but the mountains don’t become 4 times as high, the mountains with still be 1 km high (ratio 4:1). So the aspect ratio of width:height changes when I have a piece of heightmap that is getting larger in size, especially if I am Zoom Extents on all four terrains. If I Zoom Extents with differing heightmap resolutions, then the aspect will correctly change between them based on their resolution ratios. The mountains don’t somehow grow in height when the area of land mass that I am using increases. If the width:height ratio was always a constant, then when I had a 20 km by 20 km terrain, would I expect the mountains to all be 20 km high? Even Mount Everest is only 8 km in elevation, not 20 km.

This same false view also seems to get applied to the modifiers, especially the erosion modifiers. Most erosion simulation algorithms use cellular automata, where the algorithm loops over the surface of the heightmap examining 3×3 cells for altitude difference and moving water and soil down to lower elevations. The erosion cell is always a constant size, but if I look at a 1024 heightmap versus a 4096 heightmap, both at Zoom Extents, well of course the erosion on the 4096 heightmap will visually appear to be one quarter the size, this is because I am zoomed out four times further. But if I zoom up to the same heightmap feature so that it is the same size on the screen, such as walking on the terrain in a video game, then the erosion is going to be the identical size between the two heightmaps.
As another quick example, let’s look at the Rain Erosion algorithm in TerreSculptor. It uses a “brush” of a specific size to simulate a raindrop of flowing water. If I choose a 6 pixel brush, then it will be 6 pixels regardless of the size of the heightmap. But again, if I Zoom Extents on a 1024 heightmap and a 4096 heightmap, the brushes on the 4096 heightmap will look one quarter the size, this is because I am zoomed out four times further. But if I zoom up to the same heightmap feature so that it is the same size on the screen, such as walking on the terrain in a video game, then the erosion is going to be the identical size between the two heightmaps. A 6 pixel erosion brush is always a 6 pixel erosion brush, it doesn’t somehow change brush size when you change the resolution of the heightmap.

All of this discussion assumes that we are looking at a constant units per meter value for all 3D terrain meshes, which normally we are using constant values in a 3D application.
For example, the default 3D Sizing Units in TerreSculptor is 1 unit = 1 cm. This also happens to be the same in Unreal Engine.
So if I have a 1024 terrain and a 4096 terrain, the 4096 terrain is four times the total 3D world area, or four times larger in size, when both meshes are 1 unit = 1 cm.
I would have to change the 3D world Sizing Units to 1 unit = 0.25 cm for the 4096 terrain in order to render both terrains at the same 3D world area.
So if we instead look at a meter value for size measurement to make this easier, if the 1024 terrain is 1 km square in area, then the 4096 terrain is 4 km square in area.
They are not both 1 km in area unless the 4096 terrain is set to one quarter the Unit Sizing (1/4 Vertex Spacing) of the 1024 terrain.

Let’s look at Unreal Engine. It defaults to 1 grid unit = 1 cm.
The Landscape has a default Scale setting of 100.  So each terrain polygon is 1 meter.
If I import a 4096 heightmap, it will be four times the land mass area of a 1024 heightmap.
It will NOT be four times greater in detail resolution and the same land mass area.
I would have to change the mesh Scale property to one quarter the amount to reduce the mesh vertex spacing.
But the underlying heightmap will still always be four times the area.
By default the vertex spacing in a terrain mesh is always a constant amount, such as 100 in Unreal Engine, and 256 in TerreSculptor.
So changing the number of vertices in any direction increases the total area of the terrain mesh, it does not increase the detail of the mesh.
So a 4096 vertex mesh is four times the area of a 1024 vertex mesh, NOT four times the amount of detail in the same area.

And in real-world use, in engines such as Unreal Engine, you MUST leave the terrain mesh vertex Spacing value fairly close to the default value of 100.
If you tried to import an 8192 heightmap and change the terrain mesh vertex Spacing to one eighth the amount (100/8=12.5), in order to increase the terrain detail to eight times as much, then you are going to be pushing so many polygons that you will probably get less than one frame per second.
So for all intents and purposes, the 3D mesh vertex Spacing must always be a fairly large value, so therefore, increasing the number of vertices always increases the terrain mesh area, and not the terrain detail level.
As you go from lower resolutions to higher resolutions you are in fact changing from hills to mountains to continents.  Most people believe that it is an increase in detail when it is actually an increase in area.
Realistically you cannot increase the mesh detail in any 3D engine more than about half the vertex distance spatially, in other words, you can’t compress the vertexes more than about 50%, so on Unreal Engine you can adjust the Scale to 50.
You cannot go much higher in detail than that otherwise you are simply pushing too many polygons to get decent rendering performance.
And that increase in detail is not really much that you can notice (a one half meter increase).
That is why, instead of increasing vertices and polygons, you instead start using Normalmaps on the terrain textures.
Those allow you to get down to the renderer pixel/texel level of detail, which you simply cannot do with terrain polygons.

BUT to continue this lesson, we cannot confuse the 3D terrain mesh with the underlying heightmap image. They are two totally different things.
Choosing a larger heightmap ALWAYS chooses a larger “image” area, not a higher detail at the same area Sizing Units.
Sizing Units relates ONLY to the 3D mesh, it does not relate to the underlying heightmap at all.
If I am in Photoshop looking at a 1024×1024 image and a 4096×4096 image, the 4096 image is ALWAYS larger in area.  It is always more pixels.
And unfortunately we cannot simply change the Units Scale to change the effects of such modifiers as Erosion.
ALL of the modifiers treat the underlying heightmap as a floating-point grayscale image, and ALL of the modifiers work directly based on pixels and groups of pixels.
None of the modifiers know anything about the Units Scale of the 3D world, they work only on the pixels of the underlying heightmap image.
So if I use a heightmap filter that uses a 3×3 cell, it will always be a 3×3 cell on the underlying heightmap image regardless of the 3D terrain mesh settings and 3D world settings.
And if I use the Rain Erosion with a 6 pixel brush, it will always be a 6 pixel brush on the underlying heightmap image regardless of the 3D terrain mesh settings and 3D world settings.

Where most people seem to fall down on terrain software, is a larger heightmap value directly equates to a larger area of land, and not to a higher detail version of the same terrain mesh.

I hope that this enlightens some people on how heightmaps and terrain mesh rendering work.

-eof-

Release 2020-048

The TerreSculptor release 2020-048 for February 17 2020 is now available for download.  This release includes the following updates:

– Added DPI Aware functionality for high-DPI displays.
– Added ‘AllowDpiScale’ to Settings.Interface ini file.
– Added ‘Allow DPI Scale’ checkbox to Settings.Interface tab.
– Added Display group to Platform class.
– Added Display DPI X,Y to System Information dialog.
– Updated development kit to DevExpress 19.2.5.
– Increased width of the Function Panel area on the main form.
– Settings Viewport Mouse Speed and Mouse Wheel Speed range increased for faster default mouse speed.
– Settings Viewport Mouse Speed default value changed.
– Settings Viewport Mouse Wheel Speed default value changed.
– New Beach Transform tool.
– Added Feather feature to the Flatten Edges Transform tool.
– New Tile Import item on the File Menu.
– Tile Import dialog Save button allows for saving the current raw tile file for re-tiling.
– Tile Import is still under development and will have additional file format support and completed VoidFill.
– Most work completed on the Weightmap Creator.
– Fixed issues with the ESRI ASC Importer for files that contain NODATA values.
– Multiple code fixes.
– Multiple code updates.

Four additional new tutorial videos are also coming soon for the YouTube channel.

-eof-

Development Information

I often get asked questions about whether TerreSculptor is currently available on the Linux platform, and why I chose C# and DevExpress to develop with.
TerreSculptor is currently on the Windows platform only, and the choice of C# and DevExpress are rather lengthy answers that aren’t so simple.

I have actually been approached by both Autodesk and Amazon regarding them swallowing up the software into their corporations, Amazon was especially rude and pretty much swore at me for not developing the software with C++ and QT. They are simply out of touch with the reality of a solo project.
When I started development on TerreSculptor ten years ago, I looked at C++/QT to provide cross-platform builds, but QT wants $8000 CAD a year for a subscription, which I simply could not afford since this is a solo project paid for out of my own pocket.
Ten years of development cost with QT alone would have been almost $100,000 which is simply too steep for someone making only $40,000 a year and paying a mortgage. I like eating every now and then too.

So unfortunately TerreSculptor is Windows platform only at this time.
As soon as .NET Core is totally up to speed on Windows, Mac, and Linux, I will be looking into cross-platform builds using that.

My Intel-based background is in IAx86 Assembler programming, I did that for decades through the 1980’s and 1990’s.
I have also programmed extensively with C and C++.
I made the choice to develop TerreSculptor with C# for a number of reasons, including the language design and syntax, it being a managed language, it has garbage collection, and because it is a Rapid Application Development (RAD) cycle.

When I was looking for a nice User Interface Components Development Kit, I checked out all of the popular ones including DevExpress and Telerik.
I chose DevExpress mainly because I felt that they had the slight edge on the other component development kits. I prefer their set of controls and programming paradigm.

TerreSculptor is a solo project that I pay for all development costs out of my personal income.
The cost of which is currently $3000 CAD per year just for tools and hosting (Microsoft Visual Studio, DevExpress Components, Web Hosting, Google Drive, etc).
Over the current life-time of the project, that puts the cost at $30,000 to date just for tools and hosting.
A professional programmer costs typically $100,000 per year, putting the labor cost for development at $1 Million dollars.
I currently make just over $500 per year in Patreon income, so the majority of the expenses come out of my pocket, and I don’t pay myself anything.

TerreSculptor has been in release for more than seven years now, and is currently almost one million lines of source code.
There is still more than 1000 major features planned for the software, including an updated viewport renderer with many advanced features.

The Demenzun Media website gets a lot of traffic with typically 300,000+ hits each month.
My highest TerreSculptor download statistic is currently more than 500 downloads in one day.
I am going to have to look for higher bandwidth hosting soon and pay the additional charges for that convenience.
If you ever hit the site and get a time-out or just raw text, then you know the bandwidth is currently being exceeded.

If you would like to contribute to the development of this software project, consider becoming a Patreon subscriber.

Thank you for your support. And enjoy the software!

New Distribution

TerreSculptor 1.0 was available in two Editions, the “Open Use” free Standard Edition, and the low-priced Professional Edition.
With the release of TerreSculptor 2, the separate Standard Edition and Professional Edition are now replaced with a single full-feature free build.
The cost in dollars and hours to maintain two different Editions was too great and I was losing a lot of money every month.
The cost to develop a major software application like TerreSculptor is many tens-of-thousands of dollars per year, and I am paying all of that out-of-pocket.

TerreSculptor 2 is being distributed under a different method than the previous Professional Edition version 1.0 software.
The full-feature build of the software is now totally “Open Use” and free for personal, commercial, and academic use.
To recover the cost in development tools, development components, and development time, I am asking those users who can afford it to become Patreon members and support the software development with a monthly payment.

The Patreon subscription tiers start at just $1 per month ($12 per year) which should be affordable for most users of the software.
Patreon members will also be receiving extra gifts based on the subscription tier, including merchandise and beta preview builds of the software.

See the Patreon page for more details.

New Website

If you have been here before you may have noticed that the website has been updated.  The reasoning was three-fold — to update the older look, to simplify the design with less clutter, and to fix an issue with the original WordPress server installation.
Since the entire website was removed and re-engineered, all of the original blog posts were also removed.
The new website is also to coincide with the release of the new TerreSculptor version 2.0 software.  More on that in the next blog post…