Why TerreSculptor is Windows Only

I often receive emails and messages asking me “Where is the Mac version” or “Is it available for Linux”, and those are examples of the kindly worded emails and messages, you should see the nasty ones.  Well, the short answer is: TerreSculptor is Windows Only.

Why?  Because one platform had to be chosen back during initial design in 2010, and that platform was Windows simply because it has the significantly larger market-share.  Windows is ~100+ times the market size of Apple or Linux.  So it makes sense to develop for that platform if only one must be chosen.

So why the limitation of only one platform back during initial design?
Because I didn’t have some anonymous investor who had put up $1 Million to bankroll the development of the software, I paid for everything out of my own pocket.  And I only make an average income in rural northern Canada.
To hire a small team of programmers is typically $100,000 per-programmer per-year.  So $1 Million doesn’t go far for development of a major application.  So if I had only one programmer per platform that would be $300,000 per year I would require just for wages.
And cross-platform libraries like Qt, which would allow a single programmer (or a team) to develop a cross platform application, costs upwards of $8000 CAD per-year per-seat for the retail license (yes, the plan with TerreSculptor is to eventually sell it for a nominal fee, so I can’t use any open source licensed development kits).  So for the ten+ years that TerreSculptor has already been under development to get it this far, I would have had to pay out of my own pocket more than $80,000 to give everyone free software.  Now that seems like a reasonable expectation to have from an individual, no? #sarcasm

Even on the Windows platform, with more than 100,000 downloads since 2017 (to Q2 2022), I typically have 25 to 30 Patreon subscribers paying typically an even split between $1 and $5 a month.  So that should give you a ballpark idea of how much income the software gets for financial support.
Patreon basically covers my Adobe subscription for creating graphics and tutorial videos for the software, it does not cover the web hosting fees, domain fees, development tools and libraries, computer hardware, electricity, utilities, which cost me out-of-pocket a few thousand dollars a year.

So one might say “Well Blender can do it”!  Yes, but Blender gets more than $1 Million dollars a year in donations.  See pages 26 to 28 of their annual report:
If I was bringing in $1 Million a year, then I could afford to go cross-platform as well.  I could also afford to quit my day job so that I could work on the software full-time instead of working 16 to 18 hour days (8 hours at my day job then 8 hours on software programming or creating videos) plus weekends, for more than ten years, to bring everyone what is currently free software.

I don’t mean to sound upset, I don’t know whether it is simply a case of ignorance of software development costs, or hubris on their part, but the tone of the comments and emails that I get are usually quite angry that I am not meeting their cross-platform needs… for free.

Updates Everywhere…

I have partitioned the 1000+ major future updates for TerreSculptor into about 50 named “Updates”.  You may have seen me mention them previously, such as the Terrain Stack Update and the BigArray Update.

The Terrain Stack Update is going well, development is occurring quicker than expected.  I had set aside Q3/Q4 of 2022 for the Terrain Stack Update, and I already have a well functioning Alpha level build of the system, and we are just getting to the end of Q2.  This will hopefully mean that the rest of the Updates will be able to be bumped up by one or two Q’s in the development timeline.

One of the big issues that I keep bumping into is the poor design of the Microsoft Windows Imaging APIs for both subformat support and for maximum image file sizes.
Many GeoTIF images simply aren’t supported by the Windows API, and the limits to the maximum image sizes such as 32767×32767 for 16-bit grayscale is just really a joke.
So I have been looking into both libpng and libtif as a means to be able to add better functionality to the PNG and TIF Importers and Exporters.  Since these are large libraries, it is going to take some time to get these systems fully integrated into TerreSculptor with full image support.
These file format libraries will be implemented during the File Format Update, which will also see the initial build support for EXR and FBX formats.  The EXR and FBX format support will most likely be limited to just the relevant subformats that are useful for heightmaps.  For example, the EXR half-float format will most likely not be supported initially.

I have been tracking my latest YouTube video creation cycles, and I typically spend about 4 hours per finished minute in research, scripting, and editing of videos.  This means that a 10 minute video will require about 40 hours of work.
I have been aiming at one to two videos per week, which means typically sharing equal time between video creation and software development, if I work 16 to 18 hours a day plus weekends (because of the time also spent on my regular income earning job).
The push to get the YouTube channel more popular is an attempt to eventually make that an additional revenue source.  The Patreon income doesn’t quite cover the Adobe subscription, which is used for content creation.  So the other expenses such as web hosting, google drive, and software development tools still come out-of-pocket for me.  Which totals a few thousand dollars per year.  That doesn’t even account for my time spent in creating all of this.  One day we will get there…

2022 and 2023…

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.

MacOS Version

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.

2020-06-23 What’s Next?

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.


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.


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.


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…