Extended heightmaps

Got an idea for OpenTTD? Post it here!

Moderator: OpenTTD Developers

User avatar
FooBar
Tycoon
Tycoon
Posts: 6559
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Extended heightmaps

Post by FooBar » 31 May 2012 11:18

frosch wrote:@FooBar: Seriously, isn't the method using 3x3 pixels for one roadtile far simpler than using different colours?
Keep in mind that this scenario format is not only about loading and saving it with OpenTTD. The most common usecase of todays heightmaps is reallife-data generated using various tools. What tool do you expect to easily generate colour codes for road tiles? Using multiple pixels is a lot easier to put into a converter. (if you even need a converted, maybe you can just use the raw image and it will work reasonably well)
From what I understood, the 3x3 pixels format also uses at least three different colours. So you already need a tool that can work with that. Python for instance seems to handle paletted images just fine, judging from Andy's work.

Besides, a road layer is only editable outside the game to a limited extent, because it heavily depends on the terrain if a road can be built or not. If you go trough all the trouble of writing an external tool that validates road placement with the terrain, I think it's just a small step to have it use different colour indices.

But then again, it's just an idea, posted in the hope that it would be useful. If you guys decide to go for the 3x3 pixels, that is fine with me. Just saying that I would have done it differently (if I was able to implement something like this to begin with) :D

Terkhen
OpenTTD Developer
OpenTTD Developer
Posts: 1034
Joined: 11 Sep 2008 07:32
Location: Spain

Re: Extended heightmaps

Post by Terkhen » 31 May 2012 17:31

broodje wrote:
planetmaker wrote: That's out-of-scope. You can and need to write a game script for that end. The scenario format is about the state of the game on game start.
I respectfully disagree with that. As far as I know you can't set any location for (for example) a power station to appear around 1950. You can make an existing power station disappear though. But apart for the abilities of a game script... Why does it have to be so complicated :(.
Since the extended heightmap loading code would be executed once at map creation, we could force industry date creation/destruction in two ways. The new scenario format could add a new property to built industries to make them appear and dissapear in a given interval. But that's what NewGRFs do; redefining how industries work.

The other option would be initializing an ancillary code that would take care of when industries are built and destroyed. But that's what game scripts do.

As you can see, we have already two tools that do the same thing. Adding a third one would only increase the mess with little benefit.

Foobar: Your proposal is more efficient in storing the road layer information, but as mentioned we prefer readability and easeness of use over efficiency. The same applies for uniting multiple layers in a single one; having each type of information in a different object file / layer makes thing simpler and more clear. It is true that it would still need a specific tool to be edited, but at least you can check the road layout with a glance. I'm not happy with the current colour scheme for the road layout. It would be perfect if it only had to use two colours. If anyone has a better idea for oneway-ness, it would be welcome :)

Alberth: Frosch suggested a scalable sign object file yesterday, but I forgot to add it. I'll add it later today.

Eddi: You are right, how scaling works needs more clarification. The "not scalable" property of some layers and object files only applies to "size scaling", not to "height scaling". Height scaling is always applied. I'll try to rewrite my explanation.

User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Re: Extended heightmaps

Post by Zuu » 31 May 2012 18:23

Terkhen wrote:Foobar: Your proposal is more efficient in storing the road layer information, but as mentioned we prefer readability and easeness of use over efficiency. The same applies for uniting multiple layers in a single one; having each type of information in a different object file / layer makes thing simpler and more clear. It is true that it would still need a specific tool to be edited, but at least you can check the road layout with a glance. I'm not happy with the current colour scheme for the road layout. It would be perfect if it only had to use two colours. If anyone has a better idea for oneway-ness, it would be welcome :)
If the pixel to the right of the road-pixel into to the center is marked => oneway? It could symbolize a one-way sign sitting to the right of the road in a drive-on-the-right country. If the pixel on the other hand is the passive color, the road is not oneway.

A straight road going from bottom to top (which might correspond to SW to NE (?))

Code: Select all

010
010
010
Now if it looks like this instead:

Code: Select all

010
010
011
There is a no entry sign on the right side for those coming from the bottom/SW. Thus the road is one-way when going from top/NE.


It might not be very pretty if you view it, but maybe not as bad as using multiple colours?
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

User avatar
FooBar
Tycoon
Tycoon
Posts: 6559
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Extended heightmaps

Post by FooBar » 31 May 2012 21:04

Terkhen wrote:...
Alright, I understand. Thanks for your clarification.

I kinda like Zuu's idea. But maybe instead of just one corner pixel, mark two to indicate one-way roads and mark all four corner pixels for closed roads.

E.g. one-way towards the bottom:

Code: Select all

0 1 0
0 1 0
1 1 1
One-way towards top:

Code: Select all

1 1 1
0 1 0
0 1 0
Blocked:

Code: Select all

1 1 1
0 1 0
1 1 1
You could even go as far as to allow both versions. E.g. if there's only one corner pixel on either side of the road, still mark it as one-way. If one corner pixel at the start and one at the end is marked, still make it closed.
E.g. the following would also be a blocked road:

Code: Select all

0 1 1
0 1 0
1 1 0

Transportman
Tycoon
Tycoon
Posts: 2694
Joined: 22 Feb 2011 18:34

Re: Extended heightmaps

Post by Transportman » 01 Jun 2012 05:46

But what if you have:

Code: Select all

1 1 0
0 1 1
0 1 1
?

That would stand for a no entry road with a junction (impossible combination). Should it then make the no entry road or the junction? Now you can assume that it should be the no entry road because of the one way 1 at both sides, but what if the first 1 is a zero, marking a one way road? Then the game can't know what it should be, unless it looks at the neighbouring tile to see if that road junction continues there.

And what if diagonal roads gets implemented in some form? Then the place used for the no entry sign should be used for the diagonal roads to be consistent.

I do like the proposed idea for more extended heightmaps.
Coder of the Dutch Trackset | Development support for the Dutch Trainset | Coder of the 2cc TrainsInNML

User avatar
FooBar
Tycoon
Tycoon
Posts: 6559
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Extended heightmaps

Post by FooBar » 01 Jun 2012 07:19

In case of impossible combinations the actual road piece directions can take precendence, and as such the corner pixels ignored. It's just a matter of defining a rule here, so the game knows that it needs to do.

Diagonal roads is a good point though. It might be good to account for those.

frosch
OpenTTD Developer
OpenTTD Developer
Posts: 979
Joined: 20 Dec 2006 13:31
Location: Aschaffenburg

Re: Extended heightmaps

Post by frosch » 01 Jun 2012 10:16

Heightlevel scaling:
I think I had some misconception of this: I thought that scaling few heightlevels to more heightlevels would break road and canal layers by adding additional sloped tiles, and thus scaling height needs to be disabled when road- or canallayers are used.
Now that I thought more about the scaling, I noticed that scaling few heightlevels to more makes no sense. The map would look like a staircase all over the place... unless you add some fancy smoothening algorithm.
So, now I think:
  • Scaling many heightlevels to fewers works fine for roads and canals. It might break tunnels and maybe also bridges.
  • Scaling few heightlevels to more makes no sense without smoothening. Smoothening will probably break everything unpredictably.

Road layer, One Way, Junctions:
I prefer using different colours for one way roads. I think the "magic pixel patterns" are a PITA in the long run, I would rather reserve the corner pixels for diagonal roads or similiar things. Also I still hope that it would reasonably work to just import arbitrary pictures as road layers, if
  • pixels in the corners are treated as the road pieces on both edges,
  • dead ends on junction tiles are suppressed on import when a special flag in the metadata is set.
So if you have an image of roads with a linewidth of 1 and 9 times bigger than the heightmap, you can directly use it as road layer with reasonable success (I hope).

Wrt. one way roads: I don't think that one way roads are likely to be generated from external data, so I would consider this mainly a scenario editor thingie. Esp. since external data would probably mark every tile on the road as one way, which is IMHO one of the ugliest things to do to roads in OTTD :s (way worse than placing a signal on every tile)

As alternative to colouring single pixels to mark the direction, there could be individual colours for every oneway-direction (none, blocked, NW, NE, SW, SE) which are used for all pixels of a tile. Then you could "draw" a coloured line in the layer to create a oneway road without tuning of single pixels. Though you have to change the colour in turns (and thus also for diagonal-ish roads).
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁

Terkhen
OpenTTD Developer
OpenTTD Developer
Posts: 1034
Joined: 11 Sep 2008 07:32
Location: Spain

Re: Extended heightmaps

Post by Terkhen » 04 Jun 2012 18:50

With regard to scaling height to fewer levels, in my opinion it should not be recommended if the map contains tunnel, bridge or aqueduct object files. It could display a warning, but IMO it is not a fatal error to miss some bridges, tunnels or aqueducts.

For conversions to more levels, I don't think that we should use a smoothening algorithm. It would probably break more than it would fix.

I guess that the only valid case for height scaling is scaling an extended heightmap that does not contain tunnel, bridge, aqueduct or similar files to fewer levels. I don't know if we should change the height scaling properties to take this into account, though.

With regard to one way roads, I agree with frosch. The extra pixels might cause problems if we want to update the format in the future. Also, I think that might hurt the readability of the road layer. What about adding yet another layer for oneway-ness? That way, you could just use the default road layer for "real data" roads. OpenTTD would add the one way layer if it is needed.

Eddi
Tycoon
Tycoon
Posts: 7415
Joined: 17 Jan 2007 00:14

Re: Extended heightmaps

Post by Eddi » 04 Jun 2012 22:22

"height scaling" is already done for all greyscale heightmaps (scaled from 256 to 16 levels). it would be REALLY STUPID to remove that.
You might not exactly be interested in Ferion, but if you are, have fun :)

Terkhen
OpenTTD Developer
OpenTTD Developer
Posts: 1034
Joined: 11 Sep 2008 07:32
Location: Spain

Re: Extended heightmaps

Post by Terkhen » 05 Jun 2012 00:12

As I mentioned, height scaling to fewer levels is the case in which height scaling makes sense. That includes scaling from 256 height levels to 16 for extended heightmaps that only include a height layer, which should be equivalent to the case you mention. I'm not sure of what you mean.

warman45
Engineer
Engineer
Posts: 34
Joined: 29 Sep 2008 11:17

Re: Extended heightmaps

Post by warman45 » 30 Jun 2012 04:12

i haven't used heightmaps recently, but felt i should provide some sort of reminder as to the presence of water and rivers as an overlay.

Terkhen
OpenTTD Developer
OpenTTD Developer
Posts: 1034
Joined: 11 Sep 2008 07:32
Location: Spain

Re: Extended heightmaps

Post by Terkhen » 30 Jun 2012 07:51

The water layer is included in the scenario format specs since the first version. You can check it here:

http://wiki.openttd.org/Terkhen/Scenario_format

Terkhen
OpenTTD Developer
OpenTTD Developer
Posts: 1034
Joined: 11 Sep 2008 07:32
Location: Spain

Re: Extended heightmaps

Post by Terkhen » 25 Aug 2012 08:42

I have updated the scenario format with a few minor corrections and name changes for the sake of clarity. A few months ago someone at the irc channel (sorry, I don't remember who) pointed that with the current road layer, it is not possible to overlay all different layers using graphics edition programs. Since this is the only layer that presents a overlaying problem, I wonder if we should sacrifice "human readability" in this specific case.

Eddi
Tycoon
Tycoon
Posts: 7415
Joined: 17 Jan 2007 00:14

Re: Extended heightmaps

Post by Eddi » 25 Aug 2012 09:57

IMHO you should sacrifice the explicit road bits, and only have them implicitly by adjacency, possibly with some magic to handle two parallel roads. then you can go without the 3x scaling. if someone really wants control over the road bits, then there could be colour-coding for special instances, but the 2-colour mode should "do The Right Thing (tm)" in 99% of the cases.
You might not exactly be interested in Ferion, but if you are, have fun :)

MarkSheppard
Engineer
Engineer
Posts: 58
Joined: 08 Nov 2004 12:56
Contact:

Re: Extended heightmaps

Post by MarkSheppard » 28 Nov 2012 02:30

Is this concept still being worked on?

I've been working on my own scenario/heightmap for my home state of Maryland for Open TTD, and one of the problems is that placing everything by hand intelligently is so frustrating/tedious.

May I offer a few suggestions for enhanced heightmaps?

Could it be possible to design a sort of semi-intelligent auto-generation system for towns and industries so that things are placed according to some rules you define?

You could have a Industry Layer which is Industry.png -- see the attached mockup.
Industry-Heightmap_Mockup.png
Industry-Heightmap_Mockup.png (156.41 KiB) Viewed 1973 times
In the mockup, you can see a brown and green area, along with a light blue and dark blue area.

I could define that brown area with the following pseudocode:

{
R: Brown Code
G: Brown Code
B: Brown Code

Iron_Mine, 95
Ore_Mine, 95
Lime_Pit, 95
Farm, 10
}

Basically in the brown area, randomly generate a whole bunch of mines and earth resource extraction industries, leavened with a small amount of mountain farms.

Then I repeat the same pseudocode for the green area, except reversing the random generated coverage; with the majority of industries being generated being farms, with a few resource extraction industries.

Light blue area is basically fishing grounds and dredging sites; while the dark blue area is fishing grounds and oil rigs.

Basically, something to represent the fact that specific industry types tend to cluster in specific areas -- you're not going to find a coal mine for example in Maryland's Eastern Shore, but you will in Western Maryland.

Also, it'd be nice if we could get town generation tied into industry generation as well -- hand place a couple of major centers of industry in the town.txt file like posited on the wiki:

Code: Select all

[town1]
name=Baltimore
posx=Whatever
posy=Whatever
buildings=32
city=true
layout=random
steel_mills=lots
glass_mills=lots
So that our 'core' industry centers get generated with a lot of factories around them to consume goods.

Then we move on to generating the smaller towns according to some basic rules:

Suburb Towns: Basically, these are near/around the aformentioned 'core' industry centers we placed by hand at x/y points. They feed population into the centers and have smaller industries.

Resource Towns: Just what it means. Somewhere, John Guggers finds a particularly rich ore vein, and he forms the Guggers Mining Company to exploit it; and because he's the richest guy around, he becomes the Postmaster, and thus we have the formation of Guggersville.

Industry Towns: Generally, how these got started was that someone saw that there was a resource nearby that was worth adding value to; like for example in farm country, someone saw there was a market for milled flour or corn, and so built a mill along a stream. Development then concentrated around the mill.

You can do this presently by hand with the FIRS Industry Replacement set by placing a Fishing Ground, then a Fishing Harbor and small town next to it to represent that organic growth...but it becomes very tedious to do this on anything but a smaller map -- automating this process would be nice.

Sorry if I went on for a little too long. Maybe my ideas can be of use.

Terkhen
OpenTTD Developer
OpenTTD Developer
Posts: 1034
Joined: 11 Sep 2008 07:32
Location: Spain

Re: Extended heightmaps

Post by Terkhen » 03 Jan 2013 13:18

MarkSheppard: I'm sorry, I must have missed your post :(

The new scenario format is being actively worked on. My current code still needs many improvements and a reorganization (right now it qualifies better as a "hack" than as code) but it is slowly coming along.

Defining rules for map generation is outside of this feature scope. You have only two options when load an extended heightmap; either loading a specific layer or object file (in this case, all of the data that it represents gets placed in the map in the specific places and with the specific properties defined by the layer or object file) or not using the data in that file (in this case, OpenTTD will use the default rules for random generation for this kind of data).

It could be possible to define new randomizable data files in the scenario format that are incompatible with the normal ones. For example, a "random town" object file could define positions in the map where towns are more frequent and positions in which they are not. With regard to OpenTTD, this change would mean rewriting the random town generation in a way that allows for both the default town generation method and customized methods available via text files. Although in the town case this change may be somewhat feasible, it would barely be in the industry case. As mentioned previously in this thread and in the scenario format definition, a "industry object file" that just defines the position and the industry type of an industry in a way that works with all possible industry NewGRFs is an ugly can of worms that we decided to not open until the rest of the format is complete. A "randomized industry generation" layer would also require big changes in OpenTTD's already overcomplicated industry generation code, and they would have to be done in a NewGRF agnostic way that would create conflict since NewGRFs are able to define how they want industries to be placed too. Also note that OpenTTD has no precise way to know how to generate industries that meet concepts such as "organic growth" or "expensive resource". These concepts are obvious to the players but in most cases they are not strictly defined in the code anywhere. Adding such changes would require additions to the NewGRF specs that in turn would have to be implemented by industry NewGRF set authors in their respective sets.

One of the goals of the scenario format is to allow external tools to generate scenarios. In my opinion, for doing what you need it would be far simpler to create an external tool that is able to generate extended heightmaps with towns and industries placed by following the rules that you require. Then, OpenTTD would just load the generated extended heightmap and use it to create a game.

Everyone interested: As I mentioned, the implementation of this feature has advanced a bit lately. It has reached the point in which I need to start implementing the specs described in the Scenario format wiki page. For now I have decided to keep the road layer frozen along with the industry object file until everything else is done. The rest of the items are going to be implemented, and their definition is going to be fixed when I'm done. Therefore, if anyone wants to check if the format does what it should be doing, this is the last window for reviewing that does not force me to change code :P

User avatar
kyosuke1989
Transport Coordinator
Transport Coordinator
Posts: 270
Joined: 24 Mar 2008 13:04
Location: Finland

Re: Extended heightmaps

Post by kyosuke1989 » 30 Apr 2013 18:13

Thumbs up for this! When i was developing Finnish scenario with heightmap, i found out the same problem that MarkSheppard had, the water placement over sea level (rivers and lakes). Very frustating to do this kind of sceneries with lots of lakes without automation which Extended Heightmaps provides when it's developed, as far as i understand correctly? :)

ZxBiohazardZx
Tycoon
Tycoon
Posts: 1534
Joined: 14 Mar 2006 12:46
Location: Netherlands
Contact:

Re: Extended heightmaps

Post by ZxBiohazardZx » 03 May 2013 20:10

was just wondering, isnt it easier to store roads in a single bitmask number (and thus 1 int per tile) instead of a 3x3 bool?

there are only limited combinations that should fit in there

Zanman777
Engineer
Engineer
Posts: 32
Joined: 02 Feb 2012 00:09

Re: Extended heightmaps

Post by Zanman777 » 11 Oct 2013 21:38

Hey, is this extended heightmap already available in any build? (Trunk, nightly, patch pack, TPPP...?)

If not, is the "project" dead?

User avatar
YNM
Tycoon
Tycoon
Posts: 3545
Joined: 22 Mar 2012 11:10
Location: West Java

Re: Extended heightmaps

Post by YNM » 12 Oct 2013 02:22

Most probably that the main developer is being not-so-active at the time...

No, nobody had implemented this in a patchpack as far as I know. PMing the OP might help...
YNM = yoursNotMine - Don't get it ?
「ヨーッスノットマイン」も合うでしょう。

Post Reply

Return to “OpenTTD Suggestions”

Who is online

Users browsing this forum: No registered users and 3 guests