Extended heightmaps
Moderator: OpenTTD Developers
Extended heightmaps
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.
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.
Spanish translation of OpenTTD
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Re: Extended heightmaps
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.
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)
Junctioneer (a traffic intersection simulator)
Re: Extended heightmaps
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
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
Re: Extended heightmaps
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.
That way you can combine the height, water and canal layers. This spares some files.
Re: Extended heightmaps
Sure, but it breaks human readability/editability.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.
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).
Re: Extended heightmaps
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?
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?
Spanish translation of OpenTTD
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Re: Extended heightmaps
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?
Maybe it's possible to use different colours/colour indexes to encode different types of road bits in the file?
Certainly a good idea. It would be weird not to, as I suppose any other game file has a version number.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?
Re: Extended heightmaps
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.
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.
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Extended heightmaps
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.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.
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: Extended heightmaps
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.
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.
Spanish translation of OpenTTD
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Re: Extended heightmaps
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!
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?
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 had a screenshot thread.
Linux user (XMonad DWM/KDE, Arch), IRC obsessive and rail enthusiast. No longer building robots; now I ring church bells.
Author of an incredibly boring stickied post about NewGRFs.
Linux user (XMonad DWM/KDE, Arch), IRC obsessive and rail enthusiast. No longer building robots; now I ring church bells.
Author of an incredibly boring stickied post about NewGRFs.
Re: Extended heightmaps
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.
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.
Spanish translation of OpenTTD
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Re: Extended heightmaps
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.
Re: Extended heightmaps
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 .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.
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Extended heightmaps
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.broodje wrote: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 .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.
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: Extended heightmaps
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.
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.
Re: Extended heightmaps
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]
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]
Re: Extended heightmaps
@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.
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.
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Re: Extended heightmaps
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 )
I don't remember seeing one.
Zuu may want it ( http://www.tt-forums.net/viewtopic.php?f=32&t=61151 )
Re: Extended heightmaps
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.
and then i possibly didn't understand the use of max_height and desired_max_height... that needs more clarification.
Who is online
Users browsing this forum: No registered users and 3 guests