Post your screenshots!

[ShadMOrdre]

A generic airport.

[apercy]

The moon is rising!

screenshot_20230405_195528.png (229.72 KiB) Viewed 5135 times

[Hybrid Dog]

off.jpg (394.39 KiB) Viewed 5092 times

prototype.jpg (395.42 KiB) Viewed 5092 times

[the_raven_262]

*texture sampling examples*

That is a straight upgrade for non-patterned textures imo. This approach doesn't work for patterned textures like bricks though, right?
I can't really see here but is this only using the original texture's colors? Asking because pixel art and stuff :P

Obligatory screenshot:
"variations"

[Hybrid Dog]

*texture sampling examples*

That is a straight upgrade for non-patterned textures imo. This approach doesn't work for patterned textures like bricks though, right?
I can't really see here but is this only using the original texture's colors? Asking because pixel art and stuff :P

Indeed, this stochastic texture sampling technique does not work with well with patterned textures:

bricks.png (375.77 KiB) Viewed 5050 times

It is possible to configure the scaling of the triangle grid, and for each texture a different scaling may look best. Here's an example with the lava texture.
Left: usual texture sampling; top right: Fine triangle grid; middle right: Triangle grid scaling which looks good in my opinion; bottom right: Coarse triangle grid

lava_grid_scalings.png (343.15 KiB) Viewed 5050 times

‪
‪
In the ideal case, the output uses only the original texture's colours. For a higher performance, I've implemented an approximation of the histogram transformation based on the one described in https://eheitzresearch.wordpress.com/738-2/. The disadvantage of this approximation can be seen in the lava texture example above: If you look closely, you can see some slightly green dots.
Furthermore, I've enabled linear interpolation in the lookup table texture, which may also lead to new colours.

If you want to try it yourself, here's my example implementation in a single html file using webassembly and webgl2: https://hybriddog.github.io/stochastic_ ... ling_demo/ (source code: https://github.com/HybridDog/stochastic ... ling_demo/)

[the_raven_262]

*stuff*

The top one looks the best imo, though ingame it might look too noisy, but it doesn't repeat the parts of the base texture as obviously as the middle example. Thinking that sampling scrolling textures like flowing lava will result in a noisy animation, displacing the uv of a static lava texture using some noise trough a shader would probably be a better approach to animation then. I wouldn't consider this a limitation of stochastic sampling itself for that reason.

As for the patterned textures, I'd use guided texture synthesis from https://github.com/EmbarkStudios/texture-synthesis to automatically generate huge textures using a guide pattern that would be the same for all big bricks. Then map that over multiple nodes and done. I mean by hand, of course. The bad part is that most of the time this approach doesn't work exactly as intended and that this whole idea is an ugly hack.

I tried a couple of my textures and the default coal (which normally has very noticeable repeating):

Spoiler

Had to adjust the triangle size here otherwise most of the marble veins get cut up

Cases like this coal are where this sampling shines the most imo


Also, this granite looks more ..detailed? when interpolated and sampled like this:
I don't usually interpolate pixel art but this result actually looks kind of good.

Obligatory screenshot:
"hell, but using a lua mapgen is forbidden"

[Hybrid Dog]

*snip*

Thinking about it, it could be possible to adapt the stochastic texture sampling algorithm so that it works with bricks and other textures with patterns:
By default, in the stochastic texture sampling algorithm, the patches are selected randomly by hashing the triangle grid points.
If instead patches of neighbouring grid points are selected such that when they are overlapped, the brick pattern connects, then the pattern would be preserved.
This can be achieved by enforcing a distribution for the patch coordinates instead of simply choosing them uniformly at random.
As a simple example, if I round the y component of the patch coordinates to 1/4 and use a certain grid scaling, the distribution is no longer uniform and the sampled default_wood.png looks much more like the original one.
Top: Screenshot with wood nodes and non-uniform patch coordinates; bottom: Analogous to top but with uniform distribution

wood_patch_distribution.png (104.14 KiB) Viewed 5009 times

With the brick texture, configuring a good distribution is less trivial, for example because doing the rounding in x direction does not work analogously due to the triangular shape of the grid, but it should also be possible somehow.
Maybe for the general case, a texture-specific Percent-Point Function (the inverse cumulative distribution) can be saved into a texture and used in the shader after the hashing.
The target distribution may be approximated off-line as follows: For each possible 2D offset vector o, calculate the perceptual difference between the input texture and a 50% mix of the texture without offset with the texture offset by o. The probability should then be lower for offset vectors where the perceptual difference is comparatively high.



I like that this "More Like This, Please!" texture synthesis does not use a brute-force deep learning approach.
The texture synthesis algorithm sounds very similar to Model Synthesis by Paul C. Merrell, Chapel Hill 2009 (http://graphics.stanford.edu/~pmerrell/thesis.pdf), which is, I think, what wave function collapse is based on.
In the end she explains the difference to wave function collapse and if I understand it correctly, the only difference is that wave function collapse (or at least Model Synthesis) always backtracks and thus never permits patterns which are not in the input image whereas her algorithm has an error function ("uncertainty") and problems with patterns (shown in the limitations part in the video) can happen.

[the_raven_262]

If instead patches of neighbouring grid points are selected such that when they are overlapped, the brick pattern connects, then the pattern would be preserved.

This is great for textures such as planks, for bricks though you can’t really *solve it*. Extending this, I think you can make a proper tiling such that in a single row every e.g. even triangle would fall on a brick seam and every odd one would cover most of the middle of the brick. Then you just need to snap the offsets in those triangles as to capture those elements on the source texture.

Now, the problem: in a texture with the format of minetest’s clay bricks there are 4 top-left brick corners to choose from. On a stone brick type there are two. So the tiling really can’t help with repetition here as it can only pick an element from a tiny set. No rotations/reflections allowed.

I implemented a *very* simple sampling that uses a square grid and has no interpolation between the seams. Since the small brick texture is as limiting to sample, I don’t think a more advanced approach in the same vein would yield any better results (sorry its in nodes):

Slanted grid:

Wave function collapse would do better on this example because it allows rotations and reflections of patches. Which would make the set of top left corners … bigger? They still have to point up left so not all rotation/reflection possibilities are valid.

Maybe for the general case, a texture-specific Percent-Point Function (the inverse cumulative distribution) can be saved into a texture and used in the shader after the hashing.
The target distribution may be approximated off-line as follows: For each possible 2D offset vector o, calculate the perceptual difference between the input texture and a 50% mix of the texture without offset with the texture offset by o. The probability should then be lower for offset vectors where the perceptual difference is comparatively high.

If I understand this correctly, you’re basically using a texture mask to tell the algorithm which parts of the source texture are off-limits for UV displacement. Going full procedural is cool, but I think it would be safe to assume that if you implemented this in minetest you could expect people to make these masks by hand. Currently in minetest_game all the stone bricks would share the same mask. There would be around 3 different masks in total in mtg :P (big brick, block, small brick). Of course texture packs might get into some trouble if they needed to make higher resolution masks.

I’d honestly rather define each “variation” (brick, block) in terms of texture overlays and let the base texture be hashed by stochastic sampling. This approach would require addressing the base texture’s continuity which arises across bricks/tiles, somehow.

I assume that in the resulting implementation the stochastic sampling would be enabled per texture rather than per node, thus allowing not sampling the overlays.

And lastly, I apologize for any misunderstanding on my part. A lot of the math here is going over my head. I mean you probably figured that since I use shader nodes :P

Obligatory Screenshot:
“sa(m)plings”

[Hybrid Dog]

This is great for textures such as planks, for bricks though you can’t really *solve it*. Extending this, I think you can make a proper tiling such that in a single row every e.g. even triangle would fall on a brick seam and every odd one would cover most of the middle of the brick. Then you just need to snap the offsets in those triangles as to capture those elements on the source texture.

I'm not sure if I understand you correctly here.
The stochastic texture sampling algorithm differs a lot from the texture synthesis algorithms shown in that presentation.
The patches are hexagonally shaped because each triangular grid point is connected to six triangle-shaped cells.
Each pixel in the output image lies in a cell of this triangular grid and the barycentric coordinates are the weights for the mixing/"overlapping" of the three hexagonally-shaped patches.
The patch coordinates are just a translation vector for the sampling of the input texture; thus patch offset and patch coordinate means the same.




Since the input texture is sampled with nearest-neighbour mode and the world-aligned uv coordinates are rounded to the texel size of the input texture, there is, I think, only a finite number of patch coordinates which lead to unique results (to be precise, the number of pixels in the input image). If I disable the uv coordinate rounding in the shader, you can see the overlapping texels:

patch_overlaps_no_rounding.png (91.32 KiB) Viewed 4950 times

When rounding is enabled, a patch has a leeway for movement in the size of a texel without affecting the final image.



Instead of defining a mask to permit only a subset of patch coordinates, a less general but probably more efficient restriction for the coordinates is to use two vectors which define a grid:

default_brick permitted offsets.png (22.56 KiB) Viewed 4950 times

Only coordinates with which in overlapped patches no red brick merges with the white thing between red bricks is permitted.
Here's an example visualisation.
Top: Brick texture; bottom left: Overlapping with forbidden patch coordinates; bottom right: Overlapping with permitted patch coordinates

brick_overlapping.png (4.24 KiB) Viewed 4950 times

I assume that in the resulting implementation the stochastic sampling would be enabled per texture rather than per node, thus allowing not sampling the overlays.

And lastly, I apologize for any misunderstanding on my part. A lot of the math here is going over my head. I mean you probably figured that since I use shader nodes :P

My idea for the implementation in Minetest is to let mods explicitly enable stochastic texture sampling in each tile in the node definition with a parameter for grid scaling. An additional setting to globally force-disable stochastic texture sampling should also be added for people who don't like it or don't want to sacrifice performance for it.
Unfortunately until now I don't know of a clean way to implement stochastic texture sampling in Minetest; for example, I couldn't find out how to set a shader uniform per texture with Irrlicht without hackily encoding a pointer into colour value SMaterial members.

As far as I know, nobody before has used stochastic texture sampling for small 16x16 pixel-art textures with nearest neighbour interpolation, restricted the permitted patch coordinates to make it work with patterned pixel-art textures, or used the OkLAB colour space for colour decorrelation with principal component analysis, so this being difficult to understand seems reasonable.

[TumeniNodes]

Sorry to interrupt the conversation, but in such cases as bricks, etc., wouldn't a viable option be to use a set of variable textures either individually or as a sprite, using the the random chance option to address those issues created by sampling?

I have used random textures for myself in the past, but brings with it the problem of creating a ton of new textures, and burdensome for texture creators, which is why I've never shared such texture packs.
Also because the user would need to install code patches to utilize them, which I don't think is very desirable on a large enough scale of users.

Personally, I see a chance to combine the two options to produce a nicer visual experience for users who like it.
Bricks, etc. would only require a min of maybe 4 to 5 variable textures each (even less depending on the desired amount of variation, but I think 4 to 5 is a perfect amount)

I guess the factor I may be missing is, can sampling be set up/coded to ignore specific textures?
And, if so, could it all be coded up into one smooth bundle, easy to tic on and off by the end user?

[c56]

screenshot_20230407_122405.jpg (458.51 KiB) Viewed 4924 times

screenshot_20230407_205120_1.jpg (373.96 KiB) Viewed 4924 times

screenshot_20230408_115037.jpg (291.52 KiB) Viewed 4924 times

my torch kill collection 1

[c56]

screenshot_20230407_122405.jpgscreenshot_20230407_205120_1.jpgscreenshot_20230408_115037.jpgmy torch kill collection 1

i can probably find more lets see

screenshot_20230407_120702.jpg (270.73 KiB) Viewed 4922 times

screenshot_20230407_121037.jpg (452 KiB) Viewed 4922 times

screenshot_20230311_162122.png (172.56 KiB) Viewed 4922 times

[the_raven_262]

The patches are hexagonally shaped …

I was referring to your algorithm not the wfc. I missed the fact that the patches are hexagonal, I thought they were triangles. My idea would then be: squish the hexagon so it fits exactly to cover two rows of bricks (vertically) and stretch it to cover a texture width. So this:

If instead patches of neighbouring grid points are selected such that when they are overlapped, the brick pattern connects, then the pattern would be preserved.

Had to reread that in the light of my newfound knowledge :P

And yeah I agree that there is a finite number of patches to choose from whatever the case and this is just the nature of the algorithm. So the corner argument from the previous post just describes the limitation of the algorithm as a whole.

Instead of defining a mask to permit only a subset of patch coordinates, a less general but probably more efficient restriction for the coordinates is to use two vectors which define a grid:

If I understand this correctly, it is a similar approach as what I did with the slanted grid sampling in my second example in Blender. This is way more elegant though, I like it.
I assume that there is such a grid for each tiling that can be made with equal shapes (e.g. hexagons, square tiles etc.), and since there is only a fairly small number of these shapes that can be made this approach would solve this problem.

But there are patterns that don’t really repeat and are actually confined to the same node, such as the stone block pattern type. Or these:

Sorry to interrupt the conversation, but in such cases as bricks, etc., wouldn’t a viable option be to use a set of variable textures either individually or as a sprite, using the the random chance option to address those issues created by sampling?

Making variations of a texture where all the variations need to tile amongst themselves is really hard to do. But I think that just using one of those textures that span multiple nodes and that contains a bunch of variations achieves the same result. Again as you said it requires a code patch when done in a tp and,

My idea for the implementation in Minetest is to let mods explicitly enable stochastic texture sampling in each tile in the node definition with a parameter for grid scaling.

tp’s would have to have access to the grid scaling parameter, as their textures might work better with a different grid scale. I mean, making a texture that *samples* the same way as the texture it is replacing sounds kinda hard.

While I think it would be a neat feature to have stochastic sampling as an option, if I was making a game I’d just use large textures that span multiple nodes. That way I’ve got way more control over the result.

Obligatory Screenshot (I am running out of these):
“cherry tree and patinated copper”

[Wuzzy]

ANTASY BRAWL



PS: For the love of Dog, PLEASE open a new thread for the texture algorithm talk.

[Blockhead]

Only coordinates with which in overlapped patches no red brick merges with the white thing between red bricks is permitted.

It's called grout by the way*, and I concur with Wuzzy: please make a thread in unofficial engine development.

*edit: or mortar, as used in the expression "bricks and mortar" that refers to physical shops as opposed to ecommerce.

Moon setting over the Esperance goldfields.

[the_raven_262]

It's called grout by the way, and I concur with Wuzzy: please make a thread in unofficial engine development.

I apologize, the topic was fascinating but it has taken more space in this thread than it should have had.

Obligatory screenshot:
"Modular Gas Lamps"

[sorcerykid]

Happy Easter Sunday everyone!

So far over half of the Easter eggs that Nemo has hidden around spawntown on JT2 have been found. Great sleuthing work everyone! Can you spot the hidden egg in this picture?



Also, I see that Wuzzy is offering up "high quality" cooked Easter bunny meat at the butcher shop. Uhhh xD

[ShadMOrdre]

Looks like the egg is red, and in the center column, two nodes down from the hearts.


5.7.0 and phenomenal updates to graphics.

[Wilderness]

Parkour!

[JALdMIC]

JALdMIC,

This is still in a development state, not yet released.

I can state that many "meta" nodes, like chests, furnaces, and armor stands are initialized on placement, meaning they are usable, unlike in other schem placement mods, where chests are not usable.

What I could really use are schematics for things like a harbor, rail yard, heliport / airport, factories, and anything else one might find in a city. My only requirement is that the schem fit within a mapblock - road width, so roughly 70 nodes on a side.

I don't speak English
What if you ask MCL for help you,she is doing buildings based in the soviet era and can be useful,also what i do are assets like furniture so if you need furniture for your buildings you can tell me.

[Extex]

What settings did you use for your coal and marble examples?

Edit: just realized you were using Hybrid Dog's opengl implementation in those images I thought they were by the embark texture synthesis.

Mandatory screenshot:

[ShadMOrdre]

Uncannyopolis

[rubenwardy]

ContentDB can now convert markdown to Minetest hypertext, this will be used in the future to show package information inside the Minetest client. It supports bold/italics/underline, links, headings, code blocks, bullet points, and images. Tables are not supported currently. Styling is also temporary, I'll obviously need to change link colors and such. Source code

Here's some screenshots of package descriptions inside formspecs:

[Blockhead]

How tf do I enter irc?

Honestly the easiest way is to use a Matrix client, but you can also use a client like Konversation if you're a newb. Don't listen to people who tell you you need a terminal-based client for IRC, those people have mostly been using it since the 90s and/or are massive nerds (no shade to nerds but it's the truth).

Pictured: A train departing Hillside, the middle stop on the Noah's Railyard heritage railway. Train is running to left-hand traffic.

[ShadMOrdre]

@Blockhead,

Have you figured out how to "draw" tracks yet? Cities are waiting to be rail connected....

And other assorted screenies.