Hardcoded height limit found

[Wiimeiser 434]

It turns out the game has a hardcoded height limit of 2770 (no idea why that number specifically), above this height terrain tools do nothing (except lowering tools which will instantly flatten the terrain to the limit before digging down, didn't test smoothing tools, though), and networks don't work (except pipes and subways, didn't test power lines, roads flatten the height to 2770, and everything else reports that the grade is unsuitable even if the terrain is perfectly flat). The game can still render terrain above this height, it merely appears that the terrain tools and networks are hardcoded in the exe to respect an arbitrary maximum height.

(Also, this breaks down when you remember the game world was based on California to the extent that diagonal streets were disabled. I guess the game really was intended to be as abstract as SC2K, hence the lack of a way to properly terminate highways in the original game)

This is problematic with SC4Terraformer, which sets the default height to 6000 (which is way too much), unless Simmaster is willing to take a look at this then Terraformer is overdue for an update to fix this bug. (This reminds me of a music-related situation in another modding community I'm in...)

[CorinaMarie 29,566]

4 hours ago, Wiimeiser said:

It turns out the game has a hardcoded height limit of 2770

Are we certain it is hardcoded or could it be related to the MaxTerrainHeight (0x48CD7B26) in the Terrain Properties exemplar?

That is set to 2500 by default. If one adds the sea level of 250 to the terrain height (like assuming the height is above the water) it's really close to what your experiment shows. What if you increase the value to 3000 or 5000? Does it then top out at 3270 or 5270 in the same situation?

[CorinaMarie 29,566]

Me again. Here it is with the default setting:

 

And then setting it to 5000 in that exemplar:

 

So, I'm not sure where the hardcoded limit might be.

[Wiimeiser 434]

Okay, so 2770 is just the default limit, maybe my slope mod has something to do with it, too. Where is the particular exemplar you changed? Which file is it in?

Also, the hard limit is probably 32767 or something like that.

[Ganaram Inukshuk 906]

65535 is what from I recall the upper limit for the traffic query tool, so it's sensible to assume the unsigned 16-bit integer max applies in... really weird ways...

New question: is it really 65535 or 6553.5 and then rounded down to the next multiple of 1000? All sorts of games (and finance) will count by increments smaller than 1 but still use ints to get around floating-point rounding errors. (For example, Runescape uses 32-bit signed integers to save one's experience points (max of 2.147 billion exp), but counts by increments of 1/10th an experience point (max of 214.7 million), but rounds down to 200 million exp.)

[Wiimeiser 434]

So 6000 could still be the limit or close to it, as that's the highest SC4T seems to be able to go. And I think I've encountered half-heights where the ground appears flat but isn't...

[CorinaMarie 29,566]

6 hours ago, Wiimeiser said:

Where is the particular exemplar you changed? Which file is it in?

The exemplar is Type 0x6534284A. Group 0x88CD66E9, Instance 0x00000001 and the original is found in SimCity_1.dat. Note that many terrain mods include a tweaked copy of this exemplar so the 2770 you've seen is likely an override to the original Maxis one.

Here it is in Navigator of Reader 0.9.3:

 

5 hours ago, Ganaram Inukshuk said:

New question: is it really 65535 or 6553.5 and then rounded down to the next multiple of 1000?

I believe the technical limit of Float32 is the 2.147 billion number as a signed 32-bit integer. Then specific games may indeed use that with a coded 1/10 (or anything else) for actual usage. Any rounding would also be how the programmers wish to use it.

For the limit of 6000 in SC4 of the terrain creation tools, I suspect that's because any taller and the game won't let you scroll far enough to be able to see (and thus interact) with it.

[Wiimeiser 434]

It turns out the terrain mod I'm using (Missouri Breaks, I have a couple of combinations like Chihuahua with pink water, but this one is purely Missouri Breaks) does indeed have these settings, Max Terrain Height is set to 2750, and Min Terrain Height is set to 20, so I see how it adds up. Worth noting is that actually seems to be taller than in the base game...

[Propfam 2,286]

On 24/2/2020 at 6:36 AM, Wiimeiser said:

(Also, this breaks down when you remember the game world was based on California to the extent that diagonal streets were disabled. I guess the game really was intended to be as abstract as SC2K, hence the lack of a way to properly terminate highways in the original game)

I'm interested with this one. How to enable such feature? Lua scripts? Or, we need some network coding? Or, even DLL?

Thanks.

[Wiimeiser 434]

By the looks of things, even a dll won't help, and one modified the game's saving/loading system...

[Odainsaker 2,133]

There may be another type of hardcoded height limit.

I've created a scale accurate map of Mt. Fuji, real world elevation 3,776 m, that has then been vertically scaled by 133% in an experiment of visual correction such that the maximum ingame elevation with the 250 m sea level is 5,272 m.  I've used Gobias's Sudden Valley High Altitude Terrain Mod that has a MaxTerrainHeight of 5,300 m and SC4 Mapper that has a built-in limit of 6,000 m to produce the map from a 16-bit DEM.  It works, and my rendered Mt. Fuji on a region of all large tiles looks agreeable for my purposes, but there is a gap in the region view rendering in one of the tiles near the summit crater:

Entering that tile at maximum zoom out looks like this:

 

This looks identical to effects in other 3D programs where the 3D geometry has passed behind the camera.  What I think has happened here is that the camera in the isometric view is essentially a viewing plane set at some hardcoded distance and angle from the map origin, but the closest corner of the terrain geometry has an extreme elevation such that it intersects and then passes behind the angled plane of the camera.  That geometry can perhaps be thought of as being closer to the viewer than the camera, or in a virtual space in between the camera and the viewer.  A very rough estimate on my rendering suggests this camera plane intersection first occurs when the closest corner of the map has an elevation, including the 250 m of standard game sea level, of around 4,096 m.  Other areas of the map further back from this nearest corner will have different and higher intersection points.  It is theoretically possible with enough testing and measurements to calculate where the camera plane is and thus what map space falls behind it.

I can drag networks and build into this unseen area in this zoom level, but that construction also is not visible.

Another, separate issue in this maximum zoom out is that I cannot scroll up to reveal the full top of the mountain.  There may be some maximum vertical size of the plane of the camera at this zoom level.

 

The gap in geometry goes away when zooming closer, suggesting that different zoom cameras have different set distances from the origin of the ground plane.  Additionally, I can scroll much further up to reveal the full top of the mountain, suggesting that the camera plane in this zoom has a larger field of view:

 

This limit that leaves a gap in map presentation is a very special circumstance that requires certain extreme elevations at certain positions on the map when in a certain zoom, all of which is highly variable but is most likely to occur at the closest corner to the viewing plane.  It can be avoided by careful positioning elevation and/or city borders during mapmaking such that the circumstance does not occur.  In my instance, I will change the positioning of the large city tiles in the config.bmp.  The vertical scrolling bug does not seem critical to play and can be overlooked by zooming in to a different level.

There we go, the gap is gone by shifting the large city tile containing the summit crater such that the problem corner elevation is now below the camera plane cutoff and by adding some medium tiles.  I'll still have to play with the config.bmp to next minimize some of the harsher looking city tile boundaries, and, amusingly, there is a medium tile completely hidden behind the mountain that I now cannot access as there is not a visible part of the tile for the cursor to highlight and select, but those are easy fixes.  Incidentally, I found that the medium tiles have their own zoom level vertical scroll limit which is different from and shorter than the large tile vertical scroll limit, but it at least still doesn't break the gameplay.

A last note is that my mountain both is shaded and, due to its high profile, casts a huge shadow, but that shadow, created when rendering each individual tile, cannot be cast across tiles.  It may be visually useful to position city tile boundaries or manipulate elevation such that cast shadows fall fully within their own tile, or to perhaps plop dark MMP trees to better blend in any stark shadow cuts, which what I will try to do.  This is only an aesthetic constraint of how high to go before any shadowing creates visual oddities and is highly dependent on the specific geometries of your terrain.

(EDIT:  Later experimentation demonstrated that the 133% scaling initially used here is not technically correct nor visually ideal for this region view.  Indeed, no vertical scaling whatsoever on the region view seems fine.  However, it was inadvertently useful in leading me to unexpectedly encounter this camera plane issue.)

 

[Odainsaker 2,133]

Messing with another mountain got me sidetracked into this issue again so I am going to do some minor Thread Necromancy.

First up, here is a high mesa after changing the MaxTerrainHeight property exemplar in my custom terrain mod to 7000:

That is 7,000.0 meters above the seafloor, and shows that whatever limit might exist must be beyond the 6,553.5 limit that should theoretically be imposed by 16-bit computing.  This is not really surprising as SimCity 4 is a 32-bit program, and so perhaps 429,496,729.5 meters is a possible limit.

SC4 Terraformer and SC4 Mapper allows us to create 16-bit maps, with Terraformer apparently having an arbitrary 6,000 meter limit and Mapper later allowing the full 6,553.5 meters.  Leaving sea level at the default elevation level of 250 m, we have 6,303.5 meters above sea level.

I've been making a giant map that includes Anchorage and the mountain Denali, which has a peak 6,190 meters above sea level and, combined with SimCity's 250 m undersea elevation, would require 6,440 total meters of elevation to be shown in SimCity.  Fortunately, that is within the limits SC4 Mapper and 16-bit PNG DEM mapmaking.

Oooo, aaaah...

...wait, where is the top of the mountain?!?!  It's missing!  There is also a sliver of mountainside missing as well.  We can see that the mountaintop cutoff looks similar to the cutoffs that occur on the placeholder SC4 Mapper region thumbnails before they are rendered in game and with a terrain mod.

Surprise, there is a maximum viewable camera height limit in Region View, and that pixel height limit depends on the size of the city tile:

Anything above the camera height limit is simply cut off.  This limit varies with the zoom camera used.  Within a loaded city tiles, the furthest zooms have even lower limits than the Region View camera, while the closest zooms have much higher limits.  I have chosen here to focus on the Region View, as there are no alternative zooms in Region View.

As a test, I made a DEM map where all elevation was maximized to 6,553.5 meters so as to show the full volume of what can be represented in SimCity using 16-bit mapmaking tools:

Those are the maximum heights you can get from SC4 Mapper and their maximum depiction area in Region View.  Notice, however, there is a triangular hole in the large tile view.  What has happened here was discussed (2 years ago!) in my previous post above...the elevation has reached so high as to intersect with the plane of the Region View isometric camera and is now actually behind the camera.  So long as terrain and city objects stay within the depicted volume and do not intersect the triangular camera hole, that terrain and those city objects will be depicted normally.

Overlaying my rendered mountain tiles with maximum volumes depicted shows how they fit:

We can see how the mountaintops got cut off, and we can also see where some of the terrain intersects the triangular camera hole and reaches forward behind the camera, or, if you will, outside the depicted volume.  This is created the missing sliver in my mountain.

The various City View zoom cameras will also have this effect, but each beginning at different heights depending on the distance of the camera planes to the city tile:

Zooming in a bit closer:

At the closer zoom, we see that the terrain and city here still exists, they were just hidden from view.  Interestingly, it seems on this large tile the point where the intersect begins is where x=4096.0 y=4096.0 z=4096.0.  Maxis must have imagined a cubed play space, and then positioned their camera plane tangent to this corner.

For a further test, and I went ingame and used God Mode terrain tools to raise all elevations to 8,000 meters.  Here are the resulting volumes and their maximum Region View depiction:

There is not an exact elevation that can be stated as a maximum after which height be be cut off, as it can vary depending on the size of the city tile and where on the city tile we are a measuring.  The tops of some plateaus even at 7,500 m could still be seen depending on position, however, somewhere generally below 8,000 m is a variable cutoff above which nothing will be depicted in Region View.  That's it, our final limit in Region View.  Hmmm...this still gives me ideas about how to continue with a stalled map of Santiago and the mountain Aconcagua, whose 6,960.8 m summit would climb 7210.8 m from SimCity's seafloor...

I didn't fully understand why the city tile sizes were different in their cutoffs until I layered them together on center:

Ah ha, they were all centered on their map plane for the camera, and their different cutoff heights all align to some hardcoded camera cutoff.  I don't know yet why the specific pixel height of this cutoff was chosen, though I imagine that it too has some geometrical derivation involving the game space and the camera position.

Somewhere in the closest city tile zoom there will be a point where the terrain will intersect that zoom's camera plane and enter the camera hole and becoming invisible to the player.  That point will be our effective maximum height, as no other elevation increase will be apparent.  Any bored, enterprising player can max zoom onto the center of a city tile and raise terrain until they see the final 16 m x 16 m tile cross the threshold of the camera plane and disappear.

 

All of the above was actually useful in that it suggested that if I strategically changed the mix of city tile sizes in the config.bmp and also shifted where the highest elevations in my DEM were positioned inside those city tiles, I could squeeze out more depicted height in my Region View and perhaps restore the mountaintop of Denali:

Ta da!  Careful repositioning restored the mountaintop and eliminated the sliver hole.  Actually, the window where I could place the summit such that there was not any glaring cutoffs or camera holes was very tight, with shifting the DEM even 1 pixel in any direction potentially creating issues.  There are actually tiny glints of cutoff and camera hole remaining, no more than a pixel wide for each, but they are virtually imperceptible now.

The last issue to correct some bad shadow cuts.  Some of the terrain has such height and slope that it casts large shadows onto its city tiles.  However, because each tile is rendered independently, shadows cannot be cast onto or received from neighboring tiles.  This can create incongruities where mountain shadows are cut off at the tile seams.  The options for fixing this are to strategically rearrange the mix of city tiles in the config.bmp and/or shift the DEM position such that large shadows fall completely within their own tile.

Here is my config.bmp enlarged x3 to show all the puzzle adjustments made to restore the depiction of the mountaintop, avoid camera holes, and minimize shadow cuts:

I'm sure I haven't yet caught every shadow quirk, but here is my current Denali:

This Region View render uses the VIP Terrain Mod with modified MaxTerrainHeight and TemperatureRangeFactor properties to accommodate the height of Denali and the change the snowline.  Adjusting the MaxNormalYForCliff property will change the amount of rock cliff texture versus ground texture, which at this altitude effectively means the pileup of snow.  Adjusting the "Flora: elevation scale range" property will change the treeline.

The real Denali from the air:

(Photo from Sheldon Air Service Denali Grand Flightseeing Tour)

My Greater Anchorage region created using Copernicus DEM data, here reduce in image size by 25% to be uploadable to Imgur:

Eeep, my glaciers have receded!  I'll have to find some ploppable glacier texture to restore the true extent of the glaciers, though that might be futile if my fossil-fuel-gluttonous sims start developing highways in Denali National Park and Preserve.

[Odainsaker 2,133]

On 7/16/2023 at 10:37 PM, Odainsaker said:

Any bored, enterprising player can max zoom onto the center of a city tile and raise terrain until they see the final 16 m x 16 m tile cross the threshold of the camera plane and disappear.

I guess that is me, as I went ahead and did this little exercise as well.

First, I adjusted the MaxTerrainHeight exemplar property of my terrain mod from the previous 7,000 to 7,000,000.  I doubt we'll reach 7,000,000 meters high, but we'll see.

Next I zoomed in as close as possible and used the God Mod raise terrain mesa tool to raise terrain as high as it would go.  For a head start I used my previously made test cities where the highest terrain was already at 6,553.5 meters high.

Not so surprisingly, even at the closest zoom level, there are absolute maximum vertical scroll heights for the three sizes of city tiles.  While the terrain tools act as though they were continuing to function, the scroll limit means we cannot see the results nor interact with terrain that has risen beyond the vertical scroll limit.  Such terrain cannot even be queried.  While I suppose there is some 32-bit elevation field that continues to rise off camera, there is no point if we cannot even access it, and so the vertical scroll limit creates a practical, hardcoded limit.  I did not directly measure how many pixels high this scroll limit would be as it is a significant amount of scrolling.  The vertical scroll limit varies depending on position within the city tile.

In addition to the vertical scroll limit, the large and medium city tiles at even the closest zooms showed effects of the camera hole described in the previous post where the elevation crosses the plane of the camera and disappears behind the camera.  This too creates a practical limit where terrain becomes out of reach.  However, it the effect is variable depending on the position within the map.

Somewhere then on both the large and medium city map tiles is a threshold where the vertical scroll limit and the top edge of the camera hole converge, with a final sliver of terrain between them at the maximum possible elevation before it too disappears.  Through messy trial-and-error found those convergences.  Hopefully the images below are understandable, for if I cleaned up the extraneous terrain, most everything would be invisible except for the final sliver of terrain.

 

Large City Tile:

The maximum possible visible terrain elevation on a large city tile was 9,845.2 meters.

 

Medium City Tile:

The maximum possible visible terrain elevation on a medium city tile was also 9,845.2 meters.  This suggests the geometry of the closest zoom camera setup is somehow equivalent on both large and medium tiles.

 

Small City Tile:

The maximum possible visible terrain elevation was 9,071.0 meters.  The small city tile is not effected by the camera plane hole.

 

Interestingly, placing buildings or infrastructure on such high terrain can be tricky.  Roads and many landmarks would not be visible when plopped, though they could be queried.  They did become briefly visible when demolished.  Other plopped objects might have graphics glitches:

I placed a wind turbine at 9,827.1 meters, but there is something graphically strange happening at its base.  I'm sure the graphics engine isn't happy that I am looking at a bowl through a camera hole and further through the invisible inner back face of my crazy high mesa to the lower terrain beyond.

 

I seems 9,845.2 meters is the highest elevation we can realistically get, though it is certainly not practical to make anything that high.  Actually, that is lower than I might have first expected, though I am sure if we were to draw out all the geometry the results would make geometrical sense.  There isn't really a practical means to grab a screenshot of the total height without inordinate amounts of scrolling and pasting, but we can take the volume cubes I showed in the previous post and imagine extending them upwards another 1/3 or so to a final pointed cutoff.

Hopefully all this was interesting!