Replace "glow" for entities, and "light_source" for items, with something more versatile and with glowing nodes

[theidealist101]

Problem

The glow parameter in object properties is used to visually brighten the entire texture of an entity. However, this is crude and brightens the entire texture by the same amount; you can't make some parts of the texture glow and others not.

The light_source parameter in node and item definitions gives the amount of light emitted by a node, but for some reason also acts like glow for dropped items. Because the two are linked as such, there is no way to make a node appear brightened without it emitting light.

(I'm particularly interested in this problem because I'm working on a version of Subnautica in Minetest - and of course that game depends heavily on "bioluminescence", almost all fauna and flora have some glowing parts and without them it's harder to play and loses so much of the atmosphere. I do think this change would benefit other games as well, though mostly aesthetically, such as Mineclonia which would be able to make its entities and nodes glow more easily.)

Solutions

The second problem (nodes not glowing) may be dealt with alone by splitting it into two properties: light_source which would only define light emitted, and glow which would define the glow for both nodes and dropped items, and would default to light_source if unspecified, to stop old code from breaking.

However, with the first problem (all of the texture having to glow the same amount) I believe a better solution, perhaps to be used in conjunction, would be to add some sort of glow layer in one of the following ways:

• A sort of glow overlay texture; if specified, the glow property would then only affect this and not the main texture. For nodes you could use the already-existing overlay_tiles which is used for separate coloring.
• My preferred solution: a texture modifier, something like [glow:<value>. This would be the most versatile, allowing layering and combining with other non-glowing textures, but I don't know if it's possible to do it that way.

You could make the value just true or false - is there even any use for intermediate glow levels that can't be replaced with making it glow fully and altering the color?

Alternatives

Currently the only way I know of to approximate a solution to the first problem is to add another attached entity; this is what Mineclonia uses to make the endermen's and spiders' eyes glow. However, when an entity has lots of bones with glowing pixels this quickly becomes ridiculous and prone to error; it would be much simpler to have dedicated glow textures as suggested above.

The second problem may also be faked by using entities instead of nodes, but this would also be prone to error as well as causing lag if there's lots of these fake nodes in the world.

Additional context

No response

[appgurueu]

My preferred solution: a texture modifier [...] but I don't know if it's possible to do it that way

Everything is possible one way or another, but I think this would be a very bad idea design-wise.

As their name implies, texture modifiers do just that: They modify textures. Textures are just RGBA data, there is no "glow" there. We could redefine textures to include glow, but that would make a nonsensical mess.

---

I think the proper solution is a "material" system; glow would be one possible material property. There are multiple ways this can be done, the most powerful one being material textures (roughly what you seem to be suggesting?); doing this properly depends on support for more advanced mesh file formats such as glTF, or better readers / better support for the existing formats.

glTF in particular should have good support for this - see https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#materials (search for "emissive").

Our current glTF implementation doesn't support this, but it is something I plan to implement eventually.

[Wuzzy2]

The light_source parameter in node and item definitions gives the amount of light emitted by a node, but for some reason also acts like glow for dropped items.

This is true, I made a PR for this ages ago and it was accepted. Note this only affects builtin dropped items; custom dropped items from mods (that override __builtin:item) have their own code that can do whatever.

Anyway, the only reason I did this because I thought it was cool to have glowing items. In hindsight, I think this wasn't well implemented because of the unneccessary coupling I created (dropped item glow vs node light level). It would have been better to just introduce a separate field instead. Sorry …

I wouldn't mind if this feature got reverted or redesigned. To preserve max compatility, I think the best solution would be to a) preserve current behavior, but add a new special field to override the default behavior so the dropped item glow and node light level are fully decoupled again while also not breaking compat.

---

Anyway, about the core issue: I like the idea of introducing a "pure" node glow without actually lighting up the environment. This could be used for a couple of interesting new nodes. Like what you suggested for an underwater world.