Add support for tilesets

[iisu]

Tilesets are commonly used in games when there are many small textures. The basic concept is that instead you should use bigger files each containing a grid of textures called tiles. When you load the tileset, you then split it into the tiles in the program. The purpose for this technique is to optimize loading textures: it takes less time to load a single file and perform some simple operations on it than to load many small files separately. Mod API should provide an easy way to load tilesets and cut them according to given parameters.

[texmex]

I get you argument, but it would probably be a pain for texture pack maintainers.

[sorcerykid]

This is not a bad idea. It's not much different than the way that textures for player models in Minetest are stored.

I imagine the tileset storage method would be of particular benefit for remote hosting of media. I don't know if Minetest supports HTTP keep-alive sessions, but no doubt there is still going to be less overhead transferring a single large image file for each node than hundreds of small image files for every node face.

[iisu]

I thought more of one or a couple tilesets for entire mod but your point is also valid. We do this with player skins already afterall.
I wonder if it would noticeably affect the gameplay if merged default mod's textures in a single image file and also gave it a proper compression.

An external utility to convert a tileset to a series of single textures and back for texture pack maintainers who still want to work on single files should be relatively easy to write but working on a single tileset file also has benefits for a designer: you could see how all textures look together and it's generally easier to maintain a consistent style when you have everything on one sheet so you don't need to jump between files to check if you're not screwing some important details. Also it's easier to chose one color palette and stick to it which will make your texture pack look more consistent and professional.

[sorcerykid]

I agree with your points. According to this video by octacian, tilesets (or more aptly sprite sheets) were added in 0.4.16. I haven't had a chance to scan through the recent changelogs, but it's undoubtedly mentioned somewhere.

https://www.youtube.com/watch?v=sieIpZoR_Mg

[kaadmy]

Yeah, you can use tilesheets via something like ^[sheet;x,y I think.

[sorcerykid]

I'm curious if this is indeed a new feature? Or is it supported by client versions prior to 0.4.16?

[webdesigner97]

I think we used to have something like this in earlier versions (correct me if I'm wrong). It was called Texture Atlas and caused a lot of problems...

[Wuzzy]

Texture sheets will be a nightmare for texture pack makers, however. If you want to change the texture of a single block only, you have to overwrite a big file with maybe 256 textures/tiles. There is a good reason why we have 1 file per texture.

I don't like this idea. If you want to optimize servers, the server could automatically do this texture sheet thing, but only as an internal measure. In general, I think any optimization should be made in a way that they are totally transparent to texture pack makers. If this is not possible, discard the idea, think of a better one. :P

[sorcerykid]

Texture sheets will be a nightmare for texture pack makers, however. If you want to change the texture of a single block only, you have to

overwrite a big file with maybe 256 textures/tiles. There is a good reason why we have 1 file per texture.

I agree Wuzzy, the tilesets could easily be generated on the fly during server startup. It seems unduly complex for mod authors to have to manually splice together the textures particularly since the engine already has access to libraries necessary for manipulating images internally, so it could be easily automated.

[rubenwardy]

Texture sheets will be a nightmare for texture pack makers, however. If you want to change the texture of a single block only, you have to overwrite a big file with maybe 256 textures/tiles. There is a good reason why we have 1 file per texture.

Texture overrides would help with nodes, but not other things

[Linuxdirk]

I don't like this idea. If you want to optimize servers, the server could automatically do this texture sheet thing, but only as an internal measure.

It is undeniably utter nonsense to have mod makers or texture artists care about tilesets by themselves. 1 node = 1 file is the best solution for everyone.

But I wonder if it’s faster to have the server create a tileset load it as a whole and then split the tileset as needed in RAM or load the same amount than tiles as individual files.

[iisu]

I wonder if it’s faster to have the server create a tileset load it as a whole and then split the tileset as needed in RAM or load the same amount than tiles as individual files.

Arithmetic operations are faster than I/O operations.

It is undeniably utter nonsense to have mod makers or texture artists care about tilesets by themselves. 1 node = 1 file is the best solution for everyone.

I didn't say tileset format should be required from texture artists to use but it is sometimes easier to use (e.g. when you care about consistent design, as I said in my second post). Ideally, the server would check if the tileset file exists when starting; if it does, load it, if it doesn't, generate it from existing individual files. This resolves both of your concerns.

[voxelproof]

I didn't say tileset format should be required from texture artists to use but it is sometimes easier to use (e.g. when you care about consistent design, as I said in my second post).

That depends on the style of creation. If you want to make a simple 8px lego-like TP with no more artistically ambitious goals, it's true. But if you want to work out a more detailed TP, say 32px, with a view of enhancing immersiveness of virtual worlds display, you have to check different visual interactions of textures in action, not just by looking at the tableau of textures. You have to watch how they perform in different lighting conditions, with smooth lighting on, off, different sets of shaders, in different biomes etc. I have some (well, maybe more than 'some') experience with making textures and only once there was a situation when this kind of arrangement of texture pack would be useful - when I wanted to change shade of dry grasses (there're several hights of them) - even was thinking about merging them into a single file and then perform edition. But except this single case I suppose I wouldn't find this useful.

Simply speaking, such arrangement says very little, if anything at all, how the textures will perform, because it is strongly dependent both on the surroundings of their display, and on the shapes these textures are put on.

Ideally, the server would check if the tileset file exists when starting; if it does, load it, if it doesn't, generate it from existing individual files. This resolves both of your concerns.

I think such solution (although of course easily achievable) would provide some benefit not for TP creators and maintainers, but for users who don't have time, skills or patience to go into details of each and every one texture, and rather want to make all of them at once lighter, darker, more greenish etc. But this has little to do with truly professional graphic design of a game.

[iisu]

Ideally, the server would check if the tileset file exists when starting; if it does, load it, if it doesn't, generate it from existing individual files. This resolves both of your concerns.

I think such solution (although of course easily achievable) would provide some benefit not for TP creators and maintainers, but for users who don't have time, skills or patience to go into details of each and every one texture, and rather want to make all of them at once lighter, darker, more greenish etc. But this has little to do with truly professional graphic design of a game.

Such solution would enable the optimization I talked about earlier, regardless of whether the textures have been created as a single tileset manually or generated by the the server from separate files in a previous boot.

Anyways, I don't think this is so important. The optimization probably wouldn't be even noticeable. Minetest has many problems that are more relevant.

[voxelproof]

Anyways, I don't think this is so important. The optimization probably wouldn't be even noticeable. Minetest has many problems that are more relevant.

[/quote][/quote]

My point of view is the one of a designer :) If an optimization was to make the game run noticeably faster, of course making one tileset either manually or by program itself would be very welcome.

And I agree that Minetest has more serious issues - imho one of the more serious are lighting problems inside large areas of woods. But all in all it is a very good engine - I truly hope that the coming upgrade won't kill majority of mods designed for previous versions.