Extended heightmaps

Got an idea for OpenTTD? Post it here!

Moderator: OpenTTD Developers

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

Extended heightmaps

Post by Terkhen » 29 May 2012 18:49

As most of you know, creating and maintaining scenarios is nearly impossible when you want to include and update NewGRFs, or to make the same scenario available with different NewGRF presets. The best explanation for this issue can be found in this post by Alberth. If you want some examples of the problems caused by changing NewGRFs you can check this list by Arie-.

We have been discussing a solution for the scenario problem for a while already. We considered a new format unhindered by NewGRF problems as the best option and after many discussions about the details you can check the first draft of the spec here:

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

I'm interested in getting more feedback for the extended heightmap format, before deciding on a final format and starting implementation. The industries issue has been deliberately left behind because they are completely NewGRF dependent. We have some vague ideas about the best way to create industry definitions that don't rely on NewGRF data, but because of their difficulty IMO it's best to let them rest until all other parts of the extended heightmap format have been decided and implemented.

Finally, note that this thread is NOT about NewGRFs, but about creating scenarios in a way that are independent from them. If you want to discuss about changing NewGRFs ingame, please take the discussion here.

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

Re: Extended heightmaps

Post by Zuu » 29 May 2012 19:10

For road layer, will you not need additional states to store oneway-ness of road?

You might also need to store the road bits in order to handle more complicated things at hilly terrain correctly. Also two parallell flat roads may not be intended to be connected at every tile. However, if the road bits are not stored, you have to connect all road tiles that are adjacent as you don't have any information on when to connect and when to not.


Great to see some proposal though to get beyond discussions. :-)
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 » 29 May 2012 19:44

Also, what about halftile roads?
And allow me to open the can of worms called 'roadtypes'...

I see the benefit of the png format (edit a scenario in a graphics editor), but I'm a bit surprized as to why it's chosen over a simple text array of coordinates with different properties attached to them.

But then again, I can only applaud the effort, as the game would really benefit from a decent scenario format :D

User avatar
Expresso
Tycoon
Tycoon
Posts: 1725
Joined: 09 Aug 2004 00:14
Location: Gouda, the Netherlands

Re: Extended heightmaps

Post by Expresso » 29 May 2012 20:09

To my collection, png files can be 32bpp. So, why not take a look at what openttd does for tiles and do the same a bit scaled down to the png image.

That way you can combine the height, water and canal layers. This spares some files.

Alberth
OpenTTD Developer
OpenTTD Developer
Posts: 4731
Joined: 09 Sep 2007 05:03
Location: home

Re: Extended heightmaps

Post by Alberth » 29 May 2012 20:20

Expresso wrote:To my collection, png files can be 32bpp. So, why not take a look at what openttd does for tiles and do the same a bit scaled down to the png image.

That way you can combine the height, water and canal layers. This spares some files.
Sure, but it breaks human readability/editability.
A decent bitmap editor has overlays nowadays, so you can stack the various files into overlays, and edit them manually and still understand what you are doing (at least somewhat).

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

Re: Extended heightmaps

Post by Terkhen » 29 May 2012 20:28

Zuu: You are completely right, the road layer was forgotten in this version of the draft :)

In previous discussions we achieved the conclusion of assigning a different colour to each roadbit combination. I have corrected it to reflect all of those combinations. My first idea to deal with oneway-ness is to add even more colours, but I'm going to delay that in case someone else has a better idea.

Foobar: The first idea was to use a text array for roads, but it would be the only game data requiring one. Since I don't think that a single layer deserves a specific format and we have plenty of colours available in paletted PNG files anyways, IMO a PNG image is enough for them.

Roadtypes are a big can of worms indeed, but smaller than industries. Ideally, each road type would get its own layer (except those that are company-owned only). The road layer would get an extra property (or properties) in its metadata section, indicating things that would help in identificating a similar roadtype to use for that layer. If no roadtype can be found, that layer would be ignored. As I mentioned in the industry case, anything NewGRF related is hellish, but since we plan to cross that bridge for industries in the future anyways, a similar solution could be adapted for roadtypes. I think that probably these solutions will require additions to the NewGRF format itself.

This reminds me that I forgot to add a "version" metadata property for extended heightmaps. It would work in a similar way than OpenTTD savegame version. Good idea or not?

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

Re: Extended heightmaps

Post by FooBar » 29 May 2012 20:43

Thanks for explaining. If it's indeed the only layer that is different from the rest, I would also keep is as similar as the rest as possible.
Maybe it's possible to use different colours/colour indexes to encode different types of road bits in the file?
Terkhen wrote:This reminds me that I forgot to add a "version" metadata property for extended heightmaps. It would work in a similar way than OpenTTD savegame version. Good idea or not?
Certainly a good idea. It would be weird not to, as I suppose any other game file has a version number.

broodje
Director
Director
Posts: 615
Joined: 13 Jul 2003 12:47
Location: Alphen aan den Rijn
Contact:

Re: Extended heightmaps

Post by broodje » 29 May 2012 21:47

Terkhen, I really like the fact that scenario's are finally getting some attention, but for me this is only the beginning... I hope I understand it correctly that this layered map-system can be expanded in the future?
One of the things I'm missing at the moment is specifying a date at which something is created (power stations did not exist before 1878), or even removed from the map. Whilst I understand you do not want to talk about GRFs (which I understand) I hope your suggestion makes it possible to define 'possible future founding locations' when some more love is given to the scenario system.

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9282
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Extended heightmaps

Post by planetmaker » 30 May 2012 05:53

broodje wrote:One of the things I'm missing at the moment is specifying a date at which something is created (power stations did not exist before 1878), or even removed from the map. Whilst I understand you do not want to talk about GRFs (which I understand) I hope your suggestion makes it possible to define 'possible future founding locations' when some more love is given to the scenario system.
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.

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

Re: Extended heightmaps

Post by Terkhen » 30 May 2012 19:08

After additional reviews from frosch and Rubidium, the format has undertaken many changes. The most noticeable ones are a complete revamp of how height scaling works and a new format for the road layer. Before anyone else mentions it, I know that the new road layer format wastes a lot of space, but we consider readability to be more important. That said, the road layer format might need some improvement, as everything else do.

The other somewhat big addition is the addition of the max_speed property to bridges. This represents our planned approach for NewGRF changes; guessing from values, either real properties or some kind of labels.

User avatar
FLHerne
Tycoon
Tycoon
Posts: 1536
Joined: 12 Jul 2011 12:09
Location: St Ives, Cambs, UK

Re: Extended heightmaps

Post by FLHerne » 30 May 2012 19:18

Better scenarios will be amazing! I've always wanted to be able to use my own choice of NewGRFs, so thanks for working on it! :bow:

How do trams work, though? Another road layer? Three sets of colours for [road]/[road+tram]/[tram only]? Did I just miss that bit of the wiki page?
Temporary Permanent signature filling text. Content coming soon delayed indefinitely! Oh, and I have a screenshot thread now...
Linux user (XMonad DWM/KDE, Arch), IRC obsessive and rail enthusiast. No longer buiding robots.
Author of an incredibly boring stickied post about NewGRFs.

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

Re: Extended heightmaps

Post by Terkhen » 30 May 2012 19:39

You are welcome ;)

You can't have town-owned trams or trams without an owner; they only appear as company property. Because of that, they will never appear in the new format.

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

Re: Extended heightmaps

Post by Eddi » 30 May 2012 19:55

IMHO you should prepare a layer for company property (rails, roads, trams, etc.). even though the current scenario editor can't do that, it should be possible in the future.
You might not exactly be interested in Ferion, but if you are, have fun :)

broodje
Director
Director
Posts: 615
Joined: 13 Jul 2003 12:47
Location: Alphen aan den Rijn
Contact:

Re: Extended heightmaps

Post by broodje » 30 May 2012 20:47

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 :(.

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9282
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Extended heightmaps

Post by planetmaker » 30 May 2012 21:44

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 :(.
The scenario format as discussed here describes the map state. The evolution of the game state is defined by OpenTTD itself, NewGRFs chosen, game script and AI and player input. Simple as that. You likely can recommend a game script for a map in the scenario, even write one dedicated to a particular map.

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 06:11

Allow me to get back to the road layer...

Since you're using an indexed palette, wouldn't be more useful to give different meanings to different palette entries rather than using 9 pixels for each tile?

So for instance:
- index 0: no road on tile
- index 1: x axis full road
- index 2: y axis full road
- index 3-9: one-way and no-entry roads
- index 10-13: T-junctions
- index 14: full junction
- and just continue if I missed something

Or use the colour index as a bitmask:
- 00000001: top right halftile
- 00000010: top left halftile
- 00000100: bottom right halftile
- 00001000: bottom left halftile
- 00010000: oneway towards north
- 00100000: oneway towards south
- 00110000: no-entry
Simply add the values and that gives the colour index number to be used. Obviously some combinations do not make sense, these can be interpreted as "no road".

The actual colours of the palette entries do not matter, so one could use a palette with all pink colours that is useless outside the game, or some more decent colours that are usable in a graphics editor. I don't think this format is less editable outside of the game than the 9-pixel format.

You could even put road tunnels and bridges in the same file.
And using this method of indices, you could also combine the water, canal and aquaduct layers into one.

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

Re: Extended heightmaps

Post by Eddi » 31 May 2012 07:44

after some review i have an issue with this.

the setting "min_desired_height" is a misnomer. i got the totally wrong impression from the name. it should be renamed to "desired_min_height".

furthermore, i think you should prepare support for more height levels, as i expect that to be included sooner or later. a possibility for that is to turn "desired_min/max_height" into a mapping like "flat:6,hilly:10,mountaneous:15" [and clamp all larger values to 15 for now]
You might not exactly be interested in Ferion, but if you are, have fun :)

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

Re: Extended heightmaps

Post by frosch » 31 May 2012 10:27

@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)

@Eddi: The format is well prepared for any number of heightlevels (< 256). That's what "max_height" is meant for.
In this scenario format you have to distinguish scaleable and not-scaleable information. You can scale a heightmap in height, but you cannot do that when roads or canals are involved. The "desired_height" properties (if I got this right) are fixed if the scenario is not scaleable in total, and are only recommendations if the scenario is scaleable.
So this format even allows you to use the same scenario using different max-height levels if all layers are scaleable.
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁

Alberth
OpenTTD Developer
OpenTTD Developer
Posts: 4731
Joined: 09 Sep 2007 05:03
Location: home

Re: Extended heightmaps

Post by Alberth » 31 May 2012 10:38

Should a "signs layer" get added?
I don't remember seeing one.

Zuu may want it :) ( http://www.tt-forums.net/viewtopic.php?f=32&t=61151 )

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

Re: Extended heightmaps

Post by Eddi » 31 May 2012 10:40

i understand why it doesn't make sense to scale the X/Y dimensions when a road layer is present, but why would that prevent height scaling? that sounds somewhat too restrictive.

and then i possibly didn't understand the use of max_height and desired_max_height... that needs more clarification.
You might not exactly be interested in Ferion, but if you are, have fun :)

Post Reply

Return to “OpenTTD Suggestions”

Who is online

Users browsing this forum: No registered users and 3 guests