Stochastic Texture Sampling

[Hybrid Dog]

Currently textures in Minetest are repeating, for example here all cobblestone nodes are visually made up of the same small stones positioned in the same way everywhere:

stochastic_texture_sampling_off.jpg (114.41 KiB) Viewed 5713 times

With stochastic texture sampling, it is possible to re-use only high frequency details of textures, which makes nodes look more natural, adds visual variety, and prevents artifacts which are visible when a wall of the same node is watched from far away.
Here is the same image with stochastic texture sampling used for all nodes:

stochastic_texture_sampling_on.jpg (117.86 KiB) Viewed 5713 times

Whether stochastic texture sampling looks good depends on the texture, some parameters and opinion. In this case, it looks bad for the mese lamp (in my opinion) because the mese lamp texture should repeat.

I partly implemented stochastic texture sampling in Minetest some time ago and didn't continue because I don't know if it's worth the code complexity.

More screenshots: https://forum.minetest.net/viewtopic.ph ... 24#p423224

The code can be found on this branch in my Minetest fork: https://github.com/HybridDog/minetest/t ... e_sampling

In addition to stochastic texture sampling in Minetest, I have implemented a demonstration program in a single HTML page: https://hybriddog.github.io/stochastic_ ... ling_demo/
(source: https://github.com/HybridDog/stochastic ... ling_demo/)
It allows testing the algorithm with any SDR texture, for example default_stone.png:

stonet.png (63.04 KiB) Viewed 5713 times

It is also possible to implement the algorithm with SVG filters, which I have tried at https://codeberg.org/HybridDog/sts-svg

[Kazooo]

Looks cool! I know there is also seed related textures, called global textures, but MTG doesn't use them.

[Hybrid Dog]

Here is an example SVG image which makes the browser apply the algorithm:

It works with Firefox but may show vertical line artifacts with Chromium and I haven't tested it with other browsers. The whole SVG is tileable.
The stochastic texture sampled image is default_stone.png from drummyfish's Hand Painted Pack texture pack, licensed under CC0-1.0.

[Blockhead]

Here is an example SVG image which makes the browser apply the algorithm:

It works with Firefox but may show vertical line artifacts with Chromium and I haven't tested it with other browsers. The whole SVG is tileable.
The stochastic texture sampled image is default_stone.png from drummyfish's Hand Painted Pack texture pack, licensed under CC0-1.0.

Wow, that's an interesting use of SVG. Not to place multiple instances of a vector graphic, but rearrange parts of a raster image.

[Linuxdirk]

Just imagine, how good a grass texture would look like using this technique. Grass plains would actually look like grass plains and not like bathroom floors.

This should definitely make it into the engine!

[TumeniNodes]

Just imagine, how good a grass texture would look like using this technique. Grass plains would actually look like grass plains and not like bathroom floors.

This should definitely make it into the engine!

Just adding 3 additional texture variants for grass, dirt, stone, etc. and adding the code as for "default:grass_1" so they distribute nicely during map generation would be a great visual improvement ..
each of these 1 thru 4 was done by simply rotating the texture 90 degrees for each variant, which is easy to due using the rotation modifier in the code (but I find it easier to just rotate in Gimp or something)
of course for textures like brick/block etc, requires an individual texture made for each due to the highlighting and shading for the brick/block itself, meaning using a base texture to rotate each time, and then adding the overlay, then flattening the image before exporting..
This isn't to take away from Hybrid Dog's work/experimenting here

[TumeniNodes]

also taking my granite texture above and coloring it for grass,

[Linuxdirk]

Just adding 3 additional texture variants for grass, dirt, stone, etc. and adding the code as for "default:grass_1" so they distribute nicely during map generation would be a great visual improvement ..

You mean, like for sounds? That would actually quite awesome and pretty much enough for a lot of use cases.

I once played with rotating nodes randomly on world generation. That was horribly laggy, slowed world generation down, and polluted the whole world with tons of metadata. Nowadays I’d likely use param2 rotations, which would be as slow, but at least it wouldn’t spam meta data all over the place :)

This isn't to take away from Hybrid Dog's work/experimenting here

Absolutely. This is would be the most awesome visual improvement since the introduction of volumetric light.

[Wuzzy]

I like this a lot.

I think a poor man's version of Stochastic Texture Sampling could be to just pick a portion of the output with the size equal to a multiple M of the original texture size and use that as a texture for a world-aligned texture with scale=M.

In other words, create a large texture out of the original, then make it span over multiple nodes. So it technically still repeats but it is much less noticable. It is very simple and doesn't need special code, just the node defintion and a texture you basically "extended" once using that algorithm.

I think a scale of 4 (for example: original texture is 16×16, so you make 64×64 out of it and make it span over 4 nodes) already gives so much variety that the repetition is much less obvious.

[TumeniNodes]

I like this a lot.

I think a poor man's version of Stochastic Texture Sampling could be to just pick a portion of the output with the size equal to a multiple M of the original texture size and use that as a texture for a world-aligned texture with scale=M.

In other words, create a large texture out of the original, then make it span over multiple nodes. So it technically still repeats but it is much less noticable. It is very simple and doesn't need special code, just the node defintion and a texture you basically "extended" once using that algorithm.

I think a scale of 4 (for example: original texture is 16×16, so you make 64×64 out of it and make it span over 4 nodes) already gives so much variety that the repetition is much less obvious.

I've tried that method in the past (krock had actually made me aware of the method), it's "ok" I guess but it creates large noticeable patches in open areas.
I still think work should be done on allowing nodes to call from multiple texture variants on a random basis, but without creating an entirely new, separate node for each texture