Support skybox transparency

[MirceaKitsune]

Purpose

This PR adds support for transparent skyboxes: If the textures contain an alpha channel, additional blending modes can be used to render the sky color and sun / moon / stars behind transparent pixels. Further testing recommended: I verified the blending modes work as intended and current default behavior should not be affected.

This addresses part of #11366 by allowing a transparent skybox to be used in mixture with the default sky. I need this for a mod I had planned for a while, once the PR is integrated I may attempt to work on my idea.

Changes

To type property in set_sky offers two new settings for the skybox:

• "skybox": Unchanged functionality, the sky mesh is disabled and base_color is used.
• "skybox_back": The sky_color is used and rendered behind the alpha channel, sun / moon / stars are still rendered in front of the skybox.
• "skybox_front": The sky_color is used and rendered behind the alpha channel, sun / moon / stars are also rendered behind the the skybox.

First image shows current functionality with texture alpha ignored and fixed fog. Second is background transparency which looks similar except sky colors are rendered behind the cube with directional fog also enabled. Third is foreground transparency which additionally has the default sky components masked by the sky cube.

How to test

Open any init script in Minetest Game and use the following snippet to experiment with the transparency modes:

minetest.register_on_joinplayer(function(player)
	player:set_sky({
		type = "skybox_front",
		textures = {"default_mineral_coal.png", "default_mineral_coal.png", "default_mineral_coal.png", "default_mineral_coal.png", "default_mineral_coal.png", "default_mineral_coal.png"},
	})
end)

[Wbjitscool]

I wonder if possible we can actually get a setting to change the shape of the skybox one day and have like a spherical or other shaped skybox's and still keep the square skybox shape in the game engine too

[MirceaKitsune]

That would need to be a different system for later. Likely too advanced for me to tackle unlike the simpler tweaks that were required here. The ideal solution for that will be a system to attach meshes to the skybox.

This PR makes that less urgent: The primary limitation was textures disabling sky colors and directional fog, while the sun moon and stars couldn't be masked by the alpha channel of the cube. We can now have things like landscapes or cities in the background, without the standard sky getting disabled or the sun / moon rendering in front of structures.

[Wbjitscool]

yeah I have been having trouble trying to get my custom sun texture to change colour too like what the main sun texture dose in the sky but idk how to properly get it working i did make a mod but changing colour's is a bit too clunky i cannot seem to smooth it out

[MirceaKitsune]

That's unrelated to the sun / moon textures and their color: This only affects cubemap skyboxes. Using tonemaps is currently the best option for what I understand you're trying to achieve.

Something that makes this even more interesting: I verified texture modifiers work with the skybox and this PR. If core.encode_png can also be passed to the textures in set_sky, it should be possible to procedurally generate skyboxes entirely from Lua, which makes many things possible now that pixels can be drawn in front of the standard sky. In my test I used default_ladder_wood.png^default_mineral_coal.png to confirm they're overlayed correctly and the alpha channels respected, other modifiers such as coloring can also be used and updated in realtime.

[MirceaKitsune]

It's been two weeks: Any thoughts from the team on this? Is it okay to merge in its current form? Feel free to make any needed changes, like if anyone thinks there are better names for the new modes.

@appgurueu @sfan5 @paramat @rubenwardy @Wuzzy2

I know this isn't a full skybox API and doesn't make all desired features possible, like multiple skyboxes although texture modifiers can be used to achieve the same end result. It does lift the biggest limitation of not being able to use sky colors / fog and draw structures in front of the sun / moon / stars using the alpha channel, which will make most ideas that weren't previously possible now doable.

I made this PR for a game / mod that would require it: I've been waiting on this or a similar change, once it's in I can attempt my idea which should have no further obstacles. Related to worlds on other planets or structures, won't spoil everything but I'm sure everyone would enjoy the concepts I've had in mind.

[Wuzzy2]

I’m not part of the team but since you asked: I honestly struggle to see a concrete use case for this.

But more customization of hardcoded features (like the skybox) is always good in my eyes, so I’m in favor.

[MirceaKitsune]

Thanks, and sorry I thought you're a core dev. The use cases are there, some are less usual environments for more surreal worlds: As a random example that's not exactly my plan, a world that takes place on the inside of a hollow Earth that's cracked or has an artificial sun / moon on the inside. For more conventional worlds, this can be used to draw landscapes in the distance as an alternative to a costly high draw distance, possibly cities and towns or giant towers in the distance.

[nauta-turbidus]

Better yet, why'd you ping paramat

[MirceaKitsune]

Resolved changes by @appgurueu in the latest commit. Most notably:

• The SkyParams object uses two isSkybox and isTransparent checker functions, removing all redundant string checks for the 3 different skybox types throughout the code.
• The handleClientEvent_SetSky function was simplified to avoid duplicating the same code between types.
• Misc formatting fixes with minimum version mentioned in the API documentation.

Retested all the sky types including a custom base_color, old behavior should be unchanged while new behavior works as intended. Invalid sky type falls back to plain as before with the warning maintained behind the new checks.

[appgurueu]

only minor things left.

tested a bit, seemed ok to me.

[MirceaKitsune]

All solved, recompiled and retested to confirm functionality remains in order.

[MirceaKitsune]

@sfan5 I understand this is waiting on your approval. My last commit should have addressed everything you mentioned. Please confirm if everything is in order.

I'm going away in roughly two weeks. If no major issues remain, I'd be happy if this can be merged as is. Any minor issues like a variable name or comment location can be fixed later, although I've likely already solved all of those.

[sfan5]

Suggested change

	Note: Requires Luanti client version 5.13 or greater.
	Note: Requires Luanti client version 5.15 or greater.

[sfan5]

wouldn't it be more consistent to use base_color as fog?

[sfan5]

Suggested change

	* `sky_color`: A table used in `"regular"` `"skybox_back"` `"skybox_front"` types, containing the following values:
	* `sky_color`: Table used in `"regular"`, `"skybox_back"` and `"skybox_front"` types, containing the following values:

[sfan5]

I bet this bug does not exist.

Suggested change

	// Irrlicht doesn't like it when vertexes are left
	// alone and not rotated for some reason.
	vertex.Pos.rotateXZBy(0);

[sfan5]

this probably means if a new skybox type is sent to an older client, it will read garbage for body_orbit_tilt, fog_distance, fog_start and fog_color, right?
did you test that?

[sfan5]

the comment says it's compatibility code, so it shouldn't apply to the new types.

[sfan5]

the "skybox expects 6 textures" check below here should be adjusted too