Ambient light and server control for it #14343

Andrey2470T · 2024-02-03T20:13:22Z

This PR allows to add ambient light for environment per player that exists independently from the natural and artificial light sources. It is controlled by the new property ambient_light = <ColorSpec> of player:set_lighting. It makes possible to adjust brightness and color of poorly eliminated places e.g. caves, nether biome and any other closed spaces.

Youtube Demo Video
https://m.youtube.com/watch?v=Lfk4XTqnZEU

Some old screenshots

ambient_light_test.mp4

{luminance = 8, color = "green"}

{luminance = 5, color = "yellow"}

{luminance = 3, color = "red"}

This PR is Ready for Review.

How to test

Enable shaders in the settings.
Select devtest game and start the world.
Enter /set_lighting command that will show the menu with scrollbars adjusting some lighting parameters.
Adjust the red, green, blue channels of the ambient light.

nauta-turbidus

I feel like the names of the forceUpdateMapblockMeshes() function and the m_update_mapblock_meshes member variable flag aren't descriptive enough. In the same time, they're quite long already and I don't have any better ideas.

Aside of that, the code generally looks fine and seems to uphold existing conventions.

Haven't tested yet.

Another thing I would like to know, while I am not really concerned about it, how expensive is the forced mapblock meshes update?

src/client/clientenvironment.cpp

Andrey2470T · 2024-02-05T17:25:54Z

I feel like the names of the forceUpdateMapblockMeshes() function and the m_update_mapblock_meshes member variable flag aren't descriptive enough. In the same time, they're quite long already and I don't have any better ideas.

I think they sound fine. What this method does is enable that flag notifying in such way updateDrawList() about the need of adding the mesh update tasks (addUpdateMeshTask()) for the most actual m_drawlist. The same happens but only the one mapblock mesh is updated when e.g. a player made cracks on nodes.

Another thing I would like to know, while I am not really concerned about it, how expensive is the forced mapblock meshes update?

That causes a slight delays within a few seconds since as I said above it updates meshes of all currently loaded mapblocks.

HybridDog · 2024-02-06T21:27:02Z

Adding a fullbright mode where everything is visible without torches is a thing which should be done right away since 5.4.2013 or since even before that date. I think a configurable ambient light makes a fullbright mode possible.

https://dev.minetest.net/TODO#Other
#6509
#6844

client/shaders/nodes_shader/opengl_fragment.glsl

appgurueu

Thanks for the PR. Also thanks to the people who took a closer look at this before I did.
The way ambient light is applied seems to be correct.

It does not seem to be gamma-correct, but I have to agree with HybridDog that this is out of the scope for this PR to fix (simply because Minetest is gamma-incorrect pretty much everywhere, it seems?).

Rudimentary testing (RGB): Works.

src/client/game.cpp

src/client/mapblock_mesh.cpp

doc/lua_api.md

src/network/clientpackethandler.cpp

src/server.cpp

src/client/clientmap.cpp

src/client/mapblock_mesh.cpp

client/shaders/nodes_shader/opengl_fragment.glsl

appgurueu · 2024-03-04T19:47:02Z

This does not seem to look the same with shaders enabled / disabled:

Enabled:

Disabled:

I don't know what we can do about that / if we can do something about that.

We could make this a shader-only feature (like other lighting parameters). Then we could also stop caring about the performance of this if shaders aren't available.

Minetest might eventually want to require shaders (but that would require knowing what the extent of breakages would be).

I'm also starting to doubt whether min(x, 1) is the correct thing to do... This effectively means that "light" is capped at "full intensity" on all channels (as opposed to capping the "reflected" light). This enables fullbright (by setting ambient light to full white) and "reduces tint", which is why I think it's good.

We could add a second color after multiplying with texture color for said "tint".

@HybridDog should the light color be clamped after or before multiplying with the texture color, or something else entirely?

HybridDog · 2024-03-05T19:50:14Z

We could make this a shader-only feature (like other lighting parameters). Then we could also stop caring about the performance of this if shaders aren't available.

I don't know exactly how the mapblock meshes, i.e. the vertex buffers, are generated; I assume they are not generated every frame and a change in ambient lighting would need a regeneration of all mapblock meshes for the change to take effect if the ambient light cannot be configured with a shader uniform. Perhaps Irrlicht has an option to set the ambient light in the fixed function pipeline, which would be faster than regenerating mapblock meshes.

@HybridDog should the light color be clamped after or before multiplying with the texture color, or something else entirely?

It should not be clamped if the shader outputs colours as float values and post processing is enabled since the second stage shaders already clamps the colour. If it outputs 8-bit colours, which can happen if floating point textures are unsupported by the GPU I think, or if post processing is disabled, it should clamp the colour at the end before storing it in gl_FragData[0].

Clamping RGB values directly gives bad results, as explained at https://bottosson.github.io/posts/gamutclipping/.
I think clipping colours in the OKLab colour space or a similar colour space could give good results but may be difficult to implement. hdr-toys implements some gamut mapping algorithms.
A simpler approach, which may also give better results than a simple RGB clamping (I haven't tested it thoroughly), is clamping the saturation in the YCbCr colour space and then the RGB values:

// Clamp the saturation in YCbCr before a clamp in RGB for a better colour
// preservation
vec3 clamp_saturation(vec3 color)
{
	vec3 yuv = rgb_to_ycbcr(color.rgb);
	yuv.yz = clamp(yuv.yz, vec2(-0.5), vec2(0.5));
	return ycbcr_to_rgb(yuv);
}

color.rgb = clamp_saturation(color.rgb);
color.rgb = clamp(color.rgb, vec3(0.), vec3(1.));

appgurueu · 2024-03-06T15:49:59Z

Thanks for the reply.

I don't know exactly how the mapblock meshes, i.e. the vertex buffers, are generated; I assume they are not generated every frame and a change in ambient lighting would need a regeneration of all mapblock meshes for the change to take effect if the ambient light cannot be configured with a shader uniform.

Yes. (It does not need a full regeneration of the meshes, though: Just updating the vertex colors should be enough.)

Perhaps Irrlicht has an option to set the ambient light in the fixed function pipeline, which would be faster than regenerating mapblock meshes.

It seems I gave up on looking for this too quickly: There is indeed a setAmbientLight function. Just calling this seems to do nothing, though; we might also have to enable lighting, or to install a dummy light source with only ambient color.

I'm also not sure whether this does what we want, though.
The problem is that we set vertex colors to emulate light in the fixed function pipeline. These vertex colors would be multiplied with the ambient light if I'm not mistaken, when we would really want them to be added to the light, then multiplied with the texture color. If something is pitch black, it will stay pitch black, for example.

It should not be clamped if the shader outputs colours as float values and post processing is enabled since the second stage shaders already clamps the colour.

That seems reasonable. However, I'm confused by what our shader is currently doing:

It's clamping the RGB (which you shouldn't do)?
It's clamping before applying tonemapping? Does this not defeat the purpose of tonemapping?
It's applying linear RGB -> sRGB conversion, but were the colors we're working with ever converted from sRGB -> linear RGB in the first place? (Should we convert ambient light from sRGB to linear RGB?)

If it outputs 8-bit colours, which can happen if floating point textures are unsupported by the GPU I think, or if post processing is disabled, it should clamp the colour at the end before storing it in gl_FragData[0].

Ick. Fair enough.

Clamping RGB values directly gives bad results, as explained at https://bottosson.github.io/posts/gamutclipping/. I think clipping colours in the OKLab colour space or a similar colour space could give good results but may be difficult to implement. hdr-toys implements some gamut mapping algorithms. A simpler approach, which may also give better results than a simple RGB clamping (I haven't tested it thoroughly), is clamping the saturation in the YCbCr colour space and then the RGB values: [...]

Thanks for the suggestion, I'll give this a try.

Side note: If we don't do RGB clamping, then this feature can not be used to implement fullbright, but that's probably how it should be; ambient light simply does not work like that. The implementation of fullbright would be very similar, though.

@nauta-turbidus thoughts?

HybridDog · 2024-03-07T16:38:29Z

I'm also not sure whether this does what we want, though.
The problem is that we set vertex colors to emulate light in the fixed function pipeline. These vertex colors would be multiplied with the ambient light if I'm not mistaken, when we would really want them to be added to the light, then multiplied with the texture color. If something is pitch black, it will stay pitch black, for example.

It sounds wrong to me, too. The vertex colour should be added to and not multiplied by the ambient colour.

[The second stage shader is] clamping the RGB (which you shouldn't do)?

As far as I know, Minetest currently uses only colours with values in $[0,1]$ (i.e. SDR), so the clamping may be redundant. Perhaps it was added there.

It's clamping before applying tonemapping? Does this not defeat the purpose of tonemapping?

"tonemapping" in Minetest is just a visual effect and does not map HDR values to SDR since the input is already SDR. Before this commit the clamping happened after the tonemapping; I don't know why the order is changed now.

It's applying linear RGB -> sRGB conversion, but were the colors we're working with ever converted from sRGB -> linear RGB in the first place? (Should we convert ambient light from sRGB to linear RGB?)

It's converted from sRGB (approximated by 2.2 gamma) to linear RGB and later back to sRGB, so only bloom and the exposure adjustment are done in linear RGB.

Andrey2470T · 2024-03-08T14:13:19Z

I've rebased the branch and deleted the ambient light calculation for the vertex buffers of the mapblock meshes by such way allowing to calculate it only in the shaders. The reason of that is animate() behaves undefinitely. It can update the ambient light, but can not do it on some mapblocks. I struggled to find out it today, but unfortunately I failed. Besides, I think it should be a "shader feature", so needing users to enable shaders to run it.

As to clamping the output colors, I can confirm what it is even not just recommended, it is even necessary. Because without that, it provides a such result:

With that:

nauta-turbidus · 2024-03-24T23:37:54Z

Work well for nodes and objects, quite intuitive API (aside of alpha, but more on that later). It however doesn't work for the particles. As you can see, despite a fullbright (255, 255, 255) ambient light, particles are rendered as black when no other source of light (like the sun) is present.

Now to the alpha... I guess throwing an error is fine, and leaving it as a field that can be expected to be there and yet does nothing would be even worse, but I still find it funny that modder has to provide a specific value, as any other errors out. Again though, I have no better idea than that, and this is quite foolproof I think.

appgurueu · 2024-03-31T00:16:17Z

Now to the alpha... I guess throwing an error is fine, and leaving it as a field that can be expected to be there and yet does nothing would be even worse, but I still find it funny that modder has to provide a specific value, as any other errors out. Again though, I have no better idea than that, and this is quite foolproof I think.

You are right that this is a bit of a hack. It stems from the fact that our "colorspecs" and Irrlicht's SColor support alpha, but we don't need or want alpha here. Hence we enforce that the alpha be "unused" / that colors be opaque.

The proper solution would be to have "RGB-only" colorspecs / SColor, of which our current colorspecs and SColor would be extensions, but I think that is out of scope for this PR.

It should be noted that in practice, the modder does not "need to provide a specific value" - opaque colors are the default for colorspecs. If you pass {r = r, g = g, b = b}, a will default to 255, as it should, and you will be fine. If you pass "green" or "#00FF00", you will also get an opaque color. If you pass "green#42", expecting the #42 (alpha) to do something special, you will get an error, as you should. (The only case where there isn't (and can't be) a default, and which hence is slightly ugly, is when you use colorspec integer form: 0x00FF00 will throw an error, since alpha is 0. You would have to use 0xFF00FF00.)

As for the particles, I think one option would be to add a particle shader. (This might be a good idea for performance-related reasons anyways.) I might make a PR for it.

@Andrey2470T excepting the particles, the only thing I'm unsure about concerning this PR is when to do the clamping. I think I have to agree with HybridDog that if we want to have somewhat physically realistic light, we need to do the clamping after applying the ambient light, rather than clamping the light color. The upside is that strongly colored ambient light remains strongly colored, even in full brightness. (Whereas when clamping the light, you get the somewhat "weird" effect of colors only "shining through" the darker a place is.)
The downsides are that clamping after applying the light to the texture (1) makes using this for proper fullbright impossible (2) modders may prefer the "physically incorrect" behavior.

I hence propose what I think may be an interesting "middle ground":

Ambient light is physically accurate. It is not clamped before being applied. The final colors are already clamped.
We add another "clamped light" color, which is added to the light color, the result of which is clamped before being applied. The ambient light is added after this.
(Of course this would need to be documented properly.)

Thoughts?

nauta-turbidus · 2024-03-31T00:29:48Z

@appgurueu In my opinion, ambient light is inherently "physically inaccurate". There's no such thing in real world.

The main thing that we should want about ambient light is that it

is flexible and
doesn't break other (actual) light sources

This PR feels like it fulfills both these, but I'm not 100% sure about (2), and I don't really understand how would your proposed middle ground work, how would it look, and how it would be better than what we have now in this PR.

appgurueu · 2024-03-31T01:10:54Z

@appgurueu In my opinion, ambient light is inherently "physically inaccurate". There's no such thing in real world.

Indeed ambient light is intended as an approximation of "scattered" light. I think it also makes sense to choose the "better" approximation among two approximations.

Still, it is a well-defined term in computer graphics, and we probably don't want to diverge from the established light models when we use the same terms.

I don't really understand how would your proposed middle ground work, how would it look, and how it would be better than what we have now in this PR.

My proposed middle ground is to extend the API to support two colors, say ambient_light and clamped_light.

The color of a fragment would then (very roughly) be calculated as (min(light + clamped_light, 1) + ambient_light) * texture_color. That is, clamped light is added to normal light, then clamped; ambient light is just added and not clamped.

The final color is clamped (much later) anyways.

As "special cases", my proposal supports:

Fullbright as clamped light = (1, 1, 1), ambient light = (0, 0, 0).
Arbitrary "clamped light" (what this PR currently implements) by setting clamped light = (0, 0, 0).
Arbitrary ambient light, by setting clamped light = (0, 0, 0).

In general, my proposal would support a mix of clamped light (which "complements" existing light sources so to speak) and ambient light, which is unconditionally added on top.

For an example of what the difference between "ambient" and "clamped" light may look like, see Andrey's comment here. In particular, see how the "tint" of the ambient light (in this case full red) goes away in broad daylight:

This may or may not be what modders want. My proposal would give them more flexibility, at the risk of being more confusing and slightly more complex.

nauta-turbidus · 2024-03-31T01:19:24Z

@appgurueu OK, I'm almost convinced.

What would be the result of setting clamped_light = {1,1,1} and ambient_light = {1,1,1}?

appgurueu · 2024-03-31T01:25:54Z

What would be the result of setting clamped_light = {1,1,1} and ambient_light = {1,1,1}?

(min(light + clamped_light, 1) + ambient_light) * texture_color = (1 + ambient_light) * texture_color = 2 * texture_color - it would double the RGB components for the texture color. (If we want to give some advice in the docs: It's probably usually not desirable to have ambient light + clamped light > 1 for any component.)

nauta-turbidus · 2024-03-31T01:28:47Z

What would be the result of setting clamped_light = {1,1,1} and ambient_light = {1,1,1}?

(min(light + clamped_light, 1) + ambient_light) * texture_color = (1 + ambient_light) * texture_color = 2 * texture_color - it would double the RGB components for the texture color. (If we want to give some advice in the docs: It's probably usually not desirable to have ambient light + clamped light > 1 for any component.)

Since clamped_light is added to light from other sources, it is very easy to exceed 1 on the sum by adding the ambient_light and "overbrighten" the texture_color anyway...

client/shaders/nodes_shader/opengl_fragment.glsl

client/shaders/nodes_shader/opengl_vertex.glsl

src/client/mapblock_mesh.cpp

grorp · 2024-10-13T15:34:52Z

Did a quick test. This PR currently breaks node lighting. https://github.com/minetest/minetest/pull/14343/files#r1795490828

screenshot on the master branch (e3aa79c)

screenshot with this PR (plain MTG) (20a1abb, as of now the latest commit)

nauta-turbidus · 2024-10-13T15:35:58Z

Did a quick test. This PR currently breaks node lighting. https://github.com/minetest/minetest/pull/14343/files#r1795490828

With this: Andrey2470T#3 it doesn't.

nauta-turbidus · 2024-10-13T15:36:09Z

Andrey tried too hard to make the unit tests not fail.

nauta-turbidus · 2024-10-13T15:43:27Z

Those unit tests are really broken...

nauta-turbidus · 2024-10-13T15:43:46Z

It seems some of them are still failing for some reason.

grorp · 2024-10-13T15:46:57Z

Still looks noticeably worse than on master:

master

Andrey2470T#3

Another scene. Also noticeable difference, but looks less bad:

master

Andrey2470T#3

Apply review, fix stuff

Andrey2470T · 2024-10-13T16:09:22Z

@grorp "noticeably" ? I don't see absolutely any difference between your showed screenshots. On the first screenshot I can see, but Herowl has fixed now.

sfan5 · 2024-10-13T16:31:29Z

Precision issues demonstrated with smooth lighting off:

(I think you can guess which was taken with this PR)

wsor4035 · 2024-10-13T16:34:03Z

per sfan5 request, uploaded the two sand images

https://slow.pics/s/GnOotN01

unsubscribing

Wbjitscool · 2024-10-14T01:52:02Z

yeah I see the differences in the screenshots but I wonder what is causing it

Wbjitscool · 2024-10-14T01:53:17Z

it looks like it sort of shrinks the torches lighting a little too

nauta-turbidus · 2024-10-14T05:37:11Z

yeah I see the differences in the screenshots but I wonder what is causing it

I decreased the light precision to fit all the data in the few bytes we have, to allow ambient light to work with hardware coloring (grass color etc.)., see grass desaturation screenshots way above.

To not cause issues like that, we'll have to make more space for all the data, and it's not trivial.

Wbjitscool · 2024-10-17T05:33:40Z

yeah okay

Zughy · 2024-11-18T01:08:03Z

@Andrey2470T updates? I'm not closing it only because it's in the next milestone

Andrey2470T · 2024-11-18T16:44:19Z

@Zughy After the PR had failed to come in the master branch for 5.10.0 release to be honest I did lose any motivation of continuing of the developing it and also a hope of it would get merged finally. I will close it not to hang out here open.

SmallJoker · 2024-11-24T19:15:44Z

Discussed in today's meeting, starting from here: https://irc.minetest.net/minetest-dev/2024-11-24#i_6222271

Wbjitscool · 2024-11-28T06:34:48Z

... aw man i was hoping for something like this to come into luanti

cosin15 · 2024-12-27T21:09:20Z

@Wbjitscool me too. Not having this feature is very annoying.

wsor4035 added @ Script API @ Client rendering labels Feb 3, 2024

nauta-turbidus reviewed Feb 3, 2024

View reviewed changes

src/client/clientenvironment.cpp Outdated Show resolved Hide resolved

Zughy added Feature ✨ PRs that add or enhance a feature Roadmap The change matches an item on the current roadmap labels Feb 3, 2024

HybridDog reviewed Feb 6, 2024

View reviewed changes

client/shaders/nodes_shader/opengl_fragment.glsl Outdated Show resolved Hide resolved

HybridDog reviewed Feb 6, 2024

View reviewed changes

client/shaders/nodes_shader/opengl_fragment.glsl Outdated Show resolved Hide resolved

Andrey2470T force-pushed the ambient_light branch 2 times, most recently from 6daa777 to fe0a1a3 Compare February 24, 2024 15:15

appgurueu requested changes Mar 3, 2024

View reviewed changes

appgurueu added the Action / change needed Code still needs changes (PR) / more information requested (Issues) label Mar 3, 2024

Zughy removed the Action / change needed Code still needs changes (PR) / more information requested (Issues) label Mar 4, 2024

appgurueu force-pushed the ambient_light branch from 13b41b1 to d0d6775 Compare March 4, 2024 19:30

Andrey2470T force-pushed the ambient_light branch 2 times, most recently from 1aea0c9 to 5d889cc Compare March 8, 2024 14:04

Andrey2470T requested a review from appgurueu March 9, 2024 17:58

appgurueu reviewed Oct 13, 2024

View reviewed changes

client/shaders/nodes_shader/opengl_fragment.glsl Outdated Show resolved Hide resolved

appgurueu reviewed Oct 13, 2024

View reviewed changes

client/shaders/nodes_shader/opengl_vertex.glsl Outdated Show resolved Hide resolved

appgurueu reviewed Oct 13, 2024

View reviewed changes

src/client/mapblock_mesh.cpp Outdated Show resolved Hide resolved

nauta-turbidus reviewed Oct 13, 2024

View reviewed changes

src/client/mapblock_mesh.cpp Show resolved Hide resolved

src/client/mapblock_mesh.cpp Outdated Show resolved Hide resolved

nauta-turbidus added 2 commits October 13, 2024 17:13

Apply review, fix stuff

8254f5e

Make meshgen unit tests ignore vertex colors

b68d829

Zughy modified the milestones: 5.10.0, 5.11.0 Oct 13, 2024

Merge pull request #3 from nauta-turbidus/al_pr_14343

973b7d4

Apply review, fix stuff

grorp added the Action / change needed Code still needs changes (PR) / more information requested (Issues) label Oct 13, 2024

sfan5 mentioned this pull request Nov 2, 2024

Drop fixed pipeline support code #15370

Closed

Andrey2470T closed this Nov 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ambient light and server control for it #14343

Ambient light and server control for it #14343

Andrey2470T commented Feb 3, 2024 •

edited

Loading

nauta-turbidus left a comment

Andrey2470T commented Feb 5, 2024

HybridDog commented Feb 6, 2024

appgurueu left a comment •

edited

Loading

appgurueu commented Mar 4, 2024 •

edited

Loading

HybridDog commented Mar 5, 2024

appgurueu commented Mar 6, 2024 •

edited

Loading

HybridDog commented Mar 7, 2024

Andrey2470T commented Mar 8, 2024 •

edited

Loading

nauta-turbidus commented Mar 24, 2024

appgurueu commented Mar 31, 2024 •

edited

Loading

nauta-turbidus commented Mar 31, 2024 •

edited

Loading

appgurueu commented Mar 31, 2024 •

edited

Loading

nauta-turbidus commented Mar 31, 2024

appgurueu commented Mar 31, 2024

nauta-turbidus commented Mar 31, 2024

grorp commented Oct 13, 2024 •

edited

Loading

nauta-turbidus commented Oct 13, 2024 •

edited

Loading

nauta-turbidus commented Oct 13, 2024

nauta-turbidus commented Oct 13, 2024

nauta-turbidus commented Oct 13, 2024

grorp commented Oct 13, 2024 •

edited

Loading

Andrey2470T commented Oct 13, 2024

sfan5 commented Oct 13, 2024

wsor4035 commented Oct 13, 2024

Wbjitscool commented Oct 14, 2024

Wbjitscool commented Oct 14, 2024

nauta-turbidus commented Oct 14, 2024

Wbjitscool commented Oct 17, 2024

Zughy commented Nov 18, 2024 •

edited

Loading

Andrey2470T commented Nov 18, 2024

SmallJoker commented Nov 24, 2024

Wbjitscool commented Nov 28, 2024

cosin15 commented Dec 27, 2024

Ambient light and server control for it #14343

Ambient light and server control for it #14343

Conversation

Andrey2470T commented Feb 3, 2024 • edited Loading

How to test

nauta-turbidus left a comment

Choose a reason for hiding this comment

Andrey2470T commented Feb 5, 2024

HybridDog commented Feb 6, 2024

appgurueu left a comment • edited Loading

Choose a reason for hiding this comment

appgurueu commented Mar 4, 2024 • edited Loading

HybridDog commented Mar 5, 2024

appgurueu commented Mar 6, 2024 • edited Loading

HybridDog commented Mar 7, 2024

Andrey2470T commented Mar 8, 2024 • edited Loading

nauta-turbidus commented Mar 24, 2024

appgurueu commented Mar 31, 2024 • edited Loading

nauta-turbidus commented Mar 31, 2024 • edited Loading

appgurueu commented Mar 31, 2024 • edited Loading

nauta-turbidus commented Mar 31, 2024

appgurueu commented Mar 31, 2024

nauta-turbidus commented Mar 31, 2024

grorp commented Oct 13, 2024 • edited Loading

nauta-turbidus commented Oct 13, 2024 • edited Loading

nauta-turbidus commented Oct 13, 2024

nauta-turbidus commented Oct 13, 2024

nauta-turbidus commented Oct 13, 2024

grorp commented Oct 13, 2024 • edited Loading

Andrey2470T commented Oct 13, 2024

sfan5 commented Oct 13, 2024

wsor4035 commented Oct 13, 2024

Wbjitscool commented Oct 14, 2024

Wbjitscool commented Oct 14, 2024

nauta-turbidus commented Oct 14, 2024

Wbjitscool commented Oct 17, 2024

Zughy commented Nov 18, 2024 • edited Loading

Andrey2470T commented Nov 18, 2024

SmallJoker commented Nov 24, 2024

Wbjitscool commented Nov 28, 2024

cosin15 commented Dec 27, 2024

Andrey2470T commented Feb 3, 2024 •

edited

Loading

appgurueu left a comment •

edited

Loading

appgurueu commented Mar 4, 2024 •

edited

Loading

appgurueu commented Mar 6, 2024 •

edited

Loading

Andrey2470T commented Mar 8, 2024 •

edited

Loading

appgurueu commented Mar 31, 2024 •

edited

Loading

nauta-turbidus commented Mar 31, 2024 •

edited

Loading

appgurueu commented Mar 31, 2024 •

edited

Loading

grorp commented Oct 13, 2024 •

edited

Loading

nauta-turbidus commented Oct 13, 2024 •

edited

Loading

grorp commented Oct 13, 2024 •

edited

Loading

Zughy commented Nov 18, 2024 •

edited

Loading