Author: dgreen

Over the next six to twelve months, which are Q3/Q4 2022 and Q1/Q2 2023, the following items are planned for development in TerreSculptor 3.0.
These are all Build Updates which will be completely free for all licensed users of the 3.0 software.
To see the list of build updates for each current build release, see the Release Notes text file, available on the software’s Help menu.

1. The Multi-Thread Update.

Somewhere around 20% of the modifiers are currently multi-threaded. That leaves 80% as currently single-threaded.

The threading system in TerreSculptor supports virtually unlimited core-count and thread-count, although it is currently limited to 1024 maximum threads in easily-extendable code.
It will be a while before we start to see 512-Core HyperThread mainstream consumer processors and computers.

Many of the modifiers execute in less than one second even on large 16k+ heightmaps.
However, I would still prefer that every modifier possible be threaded, simply because now with the Terrain Stack, modifier performance can start to impact Stack build times.

With currently 98 Devices, and about 80% of them requiring multi-threading, even if it only required 10 hours per Device to update the code, that is still about 800 hours of development time.
So the multi-thread update will consume a large portion of the next few quarters.

Some of the Filter Functions will be difficult to multi-thread, so expect probably 5% of the Devices to not have multi-threading.
I have some tricks up my sleeve for working on threading such difficult Devices as the Rain Erosion, I still have to test my code hypothesis to see if it is functional.

2. Auto-Material.

I have been lightly researching the addition of an Auto-Material to the current Terrain Material set.

This Auto-Material would support two elevation values and two slope values.
This would allow for beach/snow for elevation, and shallow/steep slope for grass and rock variance.
The terrain coloring would of course be something such as sand for beach, grass for shallow-slope, rock for steep-slope, and snow.

The Auto-Material would provide similar terrain coloring to what the Splatmap system typically supports, but with an easier to use interface and no splatmap bitplane extraction required.

3. Biome Extraction.

One of the features that I have been working on for some time is an automated Biome Extraction and Splatmap Creation system.

Additional work will be performed on this feature over the next few quarters.

4. Digital Elevation Model File Header Parsing.

One of the features that I would like to see in TerreSculptor, is better handling of the Header Information for Digital Elevation Model files.
With the ability to automatically scale the terrain mesh to the file information.

I have still been working out exactly how I am going to manage this, without being obtrusive, and performing the sizing logically.
TerreSculptor is not GIS software, and is not in that market segment at all, but I would like to see more DEM support features over the next few quarters.

5. Pathspec Persistence.

You may have noticed (or not) that many of the drive and folder paths are persisted between sessions in TerreSculptor.
This is a feature that I have had since the early builds.
Nothing is more frustrating than having to constantly re-navigate back through drives and folders to re-load some image file.

A few additional Pathspec Persistence settings are required, such as for the Alpha Brush path for the Brush Modifier.
It gets irritating to have to constantly re-navigate back to that folder if it changes with another software operation that shares that current persisted path.

So the new Brush Pathspec Persistence code plus a few others will be implemented over the coming weeks.

6. Odds and Ends.

My documentation file that contains the list of future features contains well over 1200 entries of major features plus a few minor features and updates.
This is a compact list of a short description of each future feature that I want in the software.

At the top of this list is always the highest priority or most recent minor items that require the quickest attention for code development and updates.
This section of the list is usually at least 30 or 40 items that should be completed within the next quarter or two.

So these “odds and ends” will also be showing up in the next few builds over the next few quarters.

-eof-

TerreSculptor has been increased to Version 3.0 with this latest build release.
This is due to the large number of changes in the software:

– It is now retail, which was a tough decision.
– The new Terrain Stack, which is a major milestone feature.
– The new Brush Modifier, which is a powerful feature.

The Terrain Stack was in the original design documentation from the beginning, to provide an Autodesk 3DS Max or Blender 3D style of Modifier Stack, with more features such as Device Item Masks.  The Stack has now been completed to its first release iteration, with additional features planned for the future.

The Brush Modifier is a new concept and feature, employing Unreal Engine 4/5 style Landscape Alpha Brushes in a new Modifier.  This feature works well up to terrain sizes of 8192 and possibly even 16384, although the preview starts to get a little small by that resolution.  Future design considerations may include 3D Widgets for Location, Scale, and Rotation in the main viewport when a Brush is selected in the Terrain Stack — we’ll see how that goes.

I decided to take this new version to retail.  This choice was made because Patreon Support didn’t come anywhere near covering development expenses, and I gave it a few years to see if people would step up.
With more than 100,000+ downloads, there are only about 30 Patreon subscribers, with most paying $1 per month ($12 per year).  That is only 0.03% of the people who downloaded the software decided to help support it.  Or about 1 person out of every 3400.  And since going with Patreon I have brought in just under $3000 in total support income.  That doesn’t even cover one of my software development yearly subscriptions for the years that I was on Patreon.
Over the past few years I have gone into debt by almost $40,000 for development tools and development software, to provide the TerreSculptor software for free to the terrain design community.  I decided that I couldn’t continue on that trajectory, since I am a single individual making only average income in northern Canada.
So the choice was made to make TerreSculptor 3.0 now retail software.  However, a low price was chosen so that the software is still obtainable by people in countries with low income.  The price of $99 CAD or about $77 US was chosen, which puts TerreSculptor significantly less expensive than any of the competing terrain software, and even less than their Indie versions which have significant limitations.  You get the full TerreSculptor for the low price.

There are many new and powerful features still under development for the software.  The plan is to release new versions every 12 to 18 months for resale that will include major feature updates, such as the File Format Update and the BigArray Update.  And build updates every month or two that are free updates for those who have purchased a copy of the software.  The free updates will include such features as bug fixes, performance enhancements, multi-threading of devices, and other minor features and improvements.

For anyone who downloads the version 3.0 builds and tries to run them without a registration key, the software will run in Demo Mode for about three minutes.  TerreSculptor 2.0 is still freely available to anyone who wants to use it.

-eof-

Alpha Brushes are a feature that Unreal Engine 4/5 uses with the Landscape actor to interactively create terrain layouts from terrain shape brushes, such as various mountain shapes that can be stamped onto the terrain.
These Alpha Brushes can be positioned, scaled, and rotated, anywhere on the Landscape actor.
Alpha Brushes are often real-world terrain details.

https://docs.unrealengine.com/4.27/en-US/BuildingWorlds/Landscape/Editing/Brushes/

TerreSculptor now includes support for these same Alpha Brushes with the Brush Modifier.  The Brush Modifier allows for interactively stamping alpha brushes onto the current heightmap.  The Brush Modifier supports the blending of one alpha brush file, and can be used iteratively on the menus
When used in conjunction with the now-functional Terrain Stack, multiple Brush Modifiers can be placed onto the stack, iterated and edited, and a final complex brush layout can be achieved, such as complete mountain ranges, areas filled with various size craters, and special terrain features such as volcanoes, all with non-destructive editing.
The TerreSculptor Brush Modifier supports multiple Blend Modes and a fully interactive user interface.

The Brush Modifier should ship in the same build as the Terrain Stack later this year.

TerreSculptor Terrain Stack Update
This major Update should be publicly available in Q3/Q4 2022.

Q. What is the Terrain Stack in TerreSculptor?
A. The Terrain Stack is a highly interactive device operation layer system that allows for non-destructive workflow of terrain creation.

Each of the items on the Generate, Noisemap, Weightmap, Adjust, Modify, Transform, and Erosion menus are available as ‘Devices’ that can be added to the Terrain Stack, so that they can be edited and executed in any logical order, and re-edited and iterated.
This allows for a flexible terrain design system that can be edited over and over again, until the desired final terrain look is achieved.
An example Stack may include the following Items in descending order: Gradient Noisemap, Altitude, Altitude Center, Displace, Rain Erosion, Hydraulic Erosion, FloodLevel, Normalize, Datamap Save.
This Stack of Items can then be built and the device properties iterated over and over until the final desired terrain design is realized.
The Terrain Stack can be saved to a file, so that a library of common terrain design systems can be created.
The Terrain Stack can be thought of as similar to the Layer system in Photoshop, but more accurately to the Modifier Stack in Autodesk Max or Blender 3D.

Q. When is it available?
A. The initial Terrain Stack is already in beta testing with the Patreon subscribers.

There is still a lot of work to be completed on the Terrain Stack before it is ready for public access.
There will also be Feature Updates to the Terrain Stack over the next few years.
So while the Terrain Stack is currently functional, it won’t be released in a public build for a few months still.

Q. What is remaining to be completed?
A. Some of the current features that are pending on the Terrain Stack include: Variable Size Stack, Modifier Stack Pointers, and Unique Item GUIDs.

The Variable Size Stack allows for such Modifiers as Resample and Rotate Custom, where the dimensions of the Stack can be changed on a per-Device level.
The Modifier Stack Pointers will allow specific Modifiers such as Blend, Combine, and Shaper, to reference a Stack Item as a secondary Heightmap or Mask.  For example, the Blend Modifier blends two heightmaps together, and the Modifier Stack Pointers will allow it to use a Stack Item reference instead of having to reference an external file on disk.
The Unique Item GUIDs will allow the Modifier Stack Pointers to track changes to the Stack Item order and “fix up” pointer references automatically.

Q. What advanced features will it include?
A. The Terrain Stack will eventually include a per-Item Mask, and it will eventually be used for the 2D Terrain Paint and Brush system, and the future 3D Spline Road River and FaultLine systems.

The Item Masks will allow for such things as complex biomes, by allowing for masking out regions that the Modifiers operate on.  For example, Terraces can be applied to one region of the terrain, while FloodLevel is applied to another region.
The future Paint and Brush systems will allow for using paint tools to modify the terrain elevations, or terrain brushes to ‘stamp’ a terrain shape such as a mountain range onto the heightmap.
The future 3D spline modifiers will include a spline in the main viewport that can be manipulated to modify the heightmap.

Q. What else is coming soon?
A. Coding will also begin in Q3/Q4 on the ‘CLI’ Command Line Interface Update, the File Format Update, and the Project Update.

The CLI Update will allow for automation of TerreSculptor functions through the command prompt and through batch files.  Initial CLI functionality will be such things as heightmap file format conversion.
The File Format Update will be bringing EXR image file format and FBX mesh file format to TerreSculptor, in addition to supporting libpng and libtif to improve the total supported PNG and TIF file formats.
The Project Update will be adding the newer Modifiers and the Terrain Stack to the TerreSculptor Project file format, so that these items can be saved and loaded with a Project file.

I don’t get much time to make blog posts, most of my time is spent developing the TerreSculptor software and creating tutorial videos for the YouTube channel.  I work a full-time job in the tech sector for 30 to 40 hours each week, and then spend every waking hour outside of that writing code or working on tutorial videos.  I typically get in another 40+ hours of programming each week, and each video usually requires about 1 hour per finished-minute of work (typically 12 hours work to create a 10 minute video, not including the research time).

Here is what is upcoming for TerreSculptor in the near future:
– During Q3-2022 additional code changes are being made to accommodate the upcoming BigArray Update.  BigArray is a near-future update that will see the current 46k x 46k maximum heightmap limitation removed, and the new maximum dimensions will be 2 Billion x 2 Billion.
– Q3/Q4-2022 will see the initial Terrain Stack Update release.  The Terrain Stack allows for non-destructive editing of heightmaps using a layered stack system, where modifiers can be added and adjusted over and over.  The Stack will eventually also support a per-item Mask, so that Modifiers can be applied to a masked region of the terrain, allowing for multi-biome work.
– Q1/Q2/Q3-2023 will see the Multi-Thread Update where most devices in the software will be threaded for greater performance, which is a requirement once the BigArray update is released.  This will also benefit build times of the Terrain Stack.
– Q3/Q4-2023 will see the BigArray Update release.
– Somewhere in between all of this will be one of the File Format Updates, which will see the initial EXR image file format added, which is required for large heightmaps, since the Windows API for BMP,GIF,JPG,PNG,TIF is really limited.  Plus also some initial FBX file format code added.
– The future beyond that still has more than 1000 major features to be completed in the software, including multiple 3D Engine Updates that will add new features to the main editor viewport and other render functions.  These include terrain sculpting, terrain brushes, 3D splines, and 3D mesh scene objects.

To always get the latest information on what is happening with the TerreSculptor software, be sure to follow me on Twitter, as I usually make daily tweets, or check out the Facebook Group (link is on the software’s Help menu or the web site’s Media page).  And always consider becoming a Patreon subscriber.  For as little as $1 a month you can help make this software better.  I have continual subscriptions for the web site and development tools that require payment, so I appreciate any and all financial support.

I sometimes get asked whether I will be developing a MacOS version of TerreSculptor.  Or a Linux OS build.
Although it would be nice to fully support all desktop platforms, the simple answer is unfortunately: No.
The cold, hard facts of software development costs simply don’t allow for it.

TerreSculptor is a solo project.  I am the only person developing it, performing the programming, creating the videos, managing the social media pages, and responding to support emails and messages.
I work on TerreSculptor after my full-time job.  As of this month the software is about 800,000 lines of source code.

For me to develop cross-platform would require that I utilize a developer framework such as Qt.  The yearly cost for a Qt license varies depending on who is managing it, as it changes hands, but as of the time of this blog post writing, Qt is $3950 US per seat per year ($5250 CAD for me plus taxes).

TerreSculptor has been in development for approximately 10 years, so that would be a cost for Qt alone of about $55,000.
To date TerreSculptor has brought in about $400 total in Patreon income.

TerreSculptor for the past 11 months, has had about two dozen Patreon patrons, typically paying $1 a month, and a couple of patrons are at $5 or $10.  This Patreon income just covers minor business expenses such as my yearly web site domain, web hosting costs,  my Google Drive, monthly business banking account costs, etc.
That is two dozen paying patrons from 75,000 downloads of the software.

I develop the software with zero pay to myself.
If I had to hire a programmer to develop the software, that would typically be $100,000 per year to them in wages.  For 10 years of development costs that would be $1 Million dollars in wages just to get the software to where it is today.
And that doesn’t include ongoing costs of future builds and updates.

The bottom line is that TerreSculptor generates virtually no income, and I cannot pay for Qt out-of-pocket, I am a single guy making an average yearly wage.  I simply don’t make enough money to be able to afford to put $5500+ a year into cross-platform frameworks plus minor business expenses, so that I can provide free software to the community at my personal expense.
If more people financially supported the software, then the results may be a different story, and features such as cross-platform support may have been possible.

Here is what is coming next in TerreSculptor 2.0.

The next build of TerreSculptor will probably take a bit longer than the usual time between releases.
What I am working on right now is a rewrite to about 35% of the file load and file save methods that manage binary and text heightmap files.
This includes the Digital Elevation Model file formats of ESRI ASC, USGS BIL, GridFloat FLT, SRTM HGT, and GeoTIFF.
The first purpose of this rewrite and update is to support Void Fill on these DEM formats. Many online repositories of DEM data contain files that include voids in the dataset.  The Void Fill functions in TerreSculptor provide multiple methods for dealing with these voids of missing altitude data.
The second purpose of this rewrite is to support all DEM formats on the Tile Import dialog.  The Tile Import dialog additional file format support is an important feature to have as it allows for proper loading of Digital Elevation Model tiles. For larger terrain sizes, including UE4 and UE5 World Composition, having support for massive DEM terrains sourced from DEM tiles is a must.

On a related side note, one of the upcoming features for TerreSculptor is Big Array support. This will allow for better massive size terrain support limited only by computer system memory.
Currently most computers are limited in terrain size due to memory fragmentation which often causes an allocation fail at larger than 24576×24576.
Big Array will get around this fragmentation issue and allow for using large chunks of non-contiguous system memory.
This does not mean that a person can necessarily create vastly massive terrains as there are still limits in most video game engines.
UE4, and I would expect UE5, is still limited to an 8129×8129 Landscape.
TerreSculptor’s default current maximum terrain is 65536×65536.
For examples of massive terrains, a 131072×131072 World Composition in UE4/UE5 will require 34GB in 16-bit heightmap data.  And a 262144×262144 World Composition in UE4/UE5 will require 137GB in 16-bit heightmap data.
Most current typical computer systems simply don’t have the memory for terrains of that size.

-eof-

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-