News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

[Eyecandy] Painting ground texture

Started by Leartin, March 15, 2016, 10:11:52 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

See also: http://forum.simutrans.com/index.php?topic=11529.0

Double heights gave us the ability to paint ground textures in the form of climates. This allows for something like shown in this old screenshot:

But climates are limited. Their amount is hardcoded, they have a fixed order, and they influence what can spawn on them, how much trees etc.
Also, while the creator would only need to add one more texture, this texture must be very simple since the tiles don't tessellate, and internal each additonal climate would warrant thousends of images (each slope with blends with one and two other climates, for each climate combination)

So I'd like to propose something similar, but slightly different.
But first, the obligatory "is this needed/what can you do with this"-check
* It's purely eye-candy and non-functional. So it does not influence the game balance at all, but could be argued to be unnecessary.
* You can put gravel texture under rails. Thus, the gravel of parallel rails can be combined.
* Similarly, the ground between two roads can be altered to asphalt
* Googeling "grass texture" should give you an impression on how much variety there can be for that alone
* In combination with ground object offset (http://forum.simutrans.com/index.php?topic=15298.msg150830#msg150830) and an option to place stuff, you might rival RCT2 in design possibilities.
* Might be used to replace sidewalks


Okay, so how do I think it should work? I'd say let's start to view it as if it was a way first - For each tile, there are 16 possible ways in which it can connect to other tiles. Just like ways, parallel nonconnecting grounds should be possible. Other than ways, ground textures should work on any kind of slope. Since there are 65 slopes, you could have 1040 images if used to the fullest. However, many ground textures would not use that. Eg. gravel would only need flat and straight slope if it's purpose is to be placed under rails, all other images would not be defined. That's 16*5=80 images. A Cobblestone Texture could fill the whole tile in any case, thus requiring only 65 images (or even less if it's not supposed to work on steep slopes)
Even if 1040 images are used though, it would not be too bad. One additional climate would require 3250 tiles, after all, and each subsequent climate needs even more.

About drawing order: These paintable ground textures should be placed above ground, under ways. They should allow for offset to the south and east - this is so you can create a fuzzy edge that fits perfectly together, thus allowing a kind of fuzzy edge even without using 16 "connections" and saving images (not sure if that works out with current drawing order)

About placement: rectangular area placement like climates, with shift-click to make it round like trees.


So much to my thoughts. I wonder what others think about it.
By the way: Yes, I want Simutrans to be a graphical design game, similar to RCT and citybuilding simulators (Simcity, Anno, Skylines,...) - I don't think that aspect collides with the strategic gameplay in any way.

prissi

I fail to see the connections between climates and gravel under way. The way, the climates are precalculated and stored has little in common with the request of gravel below tracks. This is rather the "autojoinign" feature also discussed for wayobjs, and would reuse the same calculations. It would be a gravel graphics with for each way and additional left right or both side gravel extensions. Climates would not enter here at all.

Leartin

Well, replace the sand texture in a pakset with gravel and use that climate on tiles with tracks on them, and I'm sure you will see that this works to achieve the desired visuals.
Of course you can't use climates, because the same would not work if you replaced the rocky climate (climate order) you don't want a gravel desert, and you are very limited anyway.

Of course you can also alter ways or way objects to get a similar effect.  In addition, doing it with ways allows for more options on the pak designers end, probably not for tracks but for roads. So I don't oppose that. However, using ground textures gives more options to the player, one of which is whether to use them at all.

I suspect you are not a 'model railway' type of player, it's not only about having the pretty stuff in the game, but also about being able to place them and make decisions about them as the player. Actually, Dwarf Fortress proves it does not even have to look too pretty to spark the designers mind, it just needs to have the options to create.

prissi

I have not played simutrans for almost four years now, apart from short test games. But when I play, I like to watch a miniture world evolve on its own and just do what absolutely is neccessary. So I am rather anti modeller here.

kierongreen

More climates and more textures means a lot more images.... Each texture variant would need 65 images (if you could reuse existing transitions, otherwise would be same as a new climate), a new climate needs 65*14=910 images. For pak128 that means approximately 8mb per climate, or 0.5mb per texture variant. For keeping 8 climates but having 4 variants that means an extra 12mb over present. Add 4 new climates with variants and that's an extra 36mb.

climates operate with bitfields, which is why they are limited to 8 climates (3 bit). To add more climates, and add variants for each you could add 1 byte to each point on the map (for a 4096x4096 map this means another 16mb - though it could well push the structure over a limit for another 4 bytes, so on same size map could even be 64mb for this alone). This would give you, say up to 256 climates each with 8 variants.

So, overall say an extra 64mb for 4 extra climates, all climates having variants, on a 4096x4096 map, maybe 112mb if alignment doesn't work out for data structures. Significant? Well, that depends on your system, on mine Simutrans can sometimes fail to start if I've got too many internet browser windows open already. In general though I'm not really convinced it would add enough to be worthwhile. I understand the attraction from adding variety to graphics, but the impact it has on resource usage seems too high.

Leartin

First of all, I'll quote myself:
QuoteBut climates are limited. [...] So I'd like to propose something similar, but slightly different.
Just so it does not get lost in talking about climates, which are only the inspiration.


Quote from: kierongreen on March 17, 2016, 12:49:07 AM
a new climate needs 65*14=910 images.
Why would a new climate need only 910 images? That confuses me. 65 comes from the slopes, but why 14 instead of 16 (1111 in binary)?
Furthermore, how do the transistions work? Since they are blends, I was under the impression that all of them were pre-created, which would mean you would have 65*16 transistions for each climate you want to blend to. And there are tiles with 3 climates on them as well. I'd understand if the 'lower' climate would just fill the tile and the 'upper' climate be blended over it, but that would require blending - transparency - something said not possible in Simutrans?

Quote from: kierongreen on March 17, 2016, 12:49:07 AMFor pak128 that means approximately 8mb per climate, or 0.5mb per texture variant. For keeping 8 climates but having 4 variants that means an extra 12mb over present. Add 4 new climates with variants and that's an extra 36mb.
Yes, and it would be even bigger in pak192. Which is a problem if we are talking about more hardcoded climates which demand graphics in every pakset and have an actual effect (if only which kinds of buildings can be placed). But what I suggest is purely optional and has no gameplay effect, other than looking nice. Essentially, if you find out they slow your game, just delete the paks and your game should not functionally change at all.
Furthermore, you only need that much space if all possible graphics are used. More about that later.

Quote from: kierongreen on March 17, 2016, 12:49:07 AMclimates operate with bitfields, which is why they are limited to 8 climates (3 bit).
I'll stop here to reiterate: It's not about additional climates, which I understand is bad, but rather an additional "ground texture" type of object which is placed above the ground texture. Thus, you do not need to add additional bits in the climate definitions.

The request is for a new object type with the following features:

1) can be placed on slopes
2) can be placed beneath any other object
3) can replace and be replaced by other objects of the same type
4) when placed, dragging creates a rectangular area with beginning and end tile as the corners
5) Is not displayed under buildings unless "needs_ground=1"
6) has access to the ribi-system
7) if no image is defined, gets destroyed on creation/cannot be placed (no warning)


How much additional space would that need? I am no programmer, I can't say, but I can logically deduce some things which might be completely wrong:

There already is a way to indicate that an object is positioned on a tile - that much is obvious. There is virtually no limit on how many objects there are in the game, since new ones can always be added to the pakset.

There can be multiple objects in one space. That is, there can be multiple trees in addition to a ground object, a way can be combined with a wayobject, station, and signals - with trams, you can even have road and tram, road-way-object and tram-way-object on the same tile.

Therefore, each "ground texture" tile should just be another object like any other, and indicating its existence on a tile should not take more space than any other object.

The object itself does not need a whole lot of space.
First, look at a tree: Never saw a tree older than 64, so I assume you have 6bits for age alone? Then, they have offset - no idea how exact that offset is, let's say 5bit per direction? 16bit in total per tree, about 3 trees per tile in a forest, thus each forst tile consuming 48bit? Is that a good guess?
a ground texture would only need to store it's ribis, which are 4bit. Sure, if you have a 4096*4096 map and every tile has such a ground texture placed on it, that would still be 8mb. So if space is a concern, don't do that. You wouldn't spawn tons of trees in such a scenario either, but that does not mean they have no place in the game :)


About the storage space the graphics need - number 7 of my list already indicates that not every slope needs a graphic. For example, gravel only needs those where rails could be, so you would only need 16*9 images.
But for the most part, pakset creators should probably be careful not to add too many such ground textures to the pakset and rather provide them as addon for those who want them. After all, "model railway" players are those who download a terabyte of mods and addons before starting cities skylines, so they can be expected to download addons to get what they want.

kierongreen

Ooops made mistake there with the 14... shouldn't be 15 either, is infact just 1, this is the problem with dipping in and out of the code as I do!

Simutrans does have alpha blending for images, and they are used for climates..... The alpha maps for each tile slope are pregenerated from the transition textures (requiring 15*65 images total). The climates themselves actually only need 65 images each. Better than I remembered :)

Now, before you ask about using the alpha code elsewhere... a) yes it would be possible) b) it would still impact performance c) it would need a little work on the pak writing and reading to get the alphamaps defined and loaded. Curiously about an evenings work I reckon (would roll up sleeves at this point but already have a short sleeved shirt on).

Leartin

Quote from: kierongreen on March 17, 2016, 06:15:39 PM
Now, before you ask about using the alpha code elsewhere...

I am not that predictable, am I?  :o ;D