Player emitting light abilities

[TekhnaeRaav]

I think it would be an amazing feature to add something that allows your player hold a torch and emit light as he goes, and allow you to do this with any other items or mods.

[benrob0329]

Someone did entity lighting, but because it was a shader effect it was rejected. (Not everyone uses shaders because our pipeline isn't the most efficient, so a gameplay changing advantage would be bad).

[paramat]

Mods that do this are intensive, engine doing it may also be intensive due to updating world light values frequently (2+ times a second), each update has to update meshes too.
Can't be clientside as other players need to be able to see the light another player creates.
Has to be param1 values changed to stop mobs spawning in this light etc.
Would be a nice feature.

[TekhnaeRaav]

If you did this you would have to make sure that torches don't work underwater 😉

Has to be param1 values changed to stop mobs spawning in this light etc.

Mobs don't spawn that close to you though do they?

[ghost]

There are no mobs in MTG.

…

On Tue, Jan 16, 2018, 6:43 PM TekhnaeRaav ***@***.***> wrote: If you did this you would have to make sure that torches don't work underwater 😉 Has to be param1 values changed to stop mobs spawning in this light etc. Mobs don't spawn that close to you though do they? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6921 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWXKYnJXVt6HOEqcW6H9GTL8zJ3i3uztks5tLTQagaJpZM4RgYpf> .

[benrob0329]

Minetest is much, much more than MTG.

[ghost]

Minetest is much, much more than MTG.

But it does not have a mobs API – so caring about mobs is a mobs mod maker’s issue.

[benrob0329]

Giving the mod maker the tools he needs is an engine issue.

[ghost]

This should DEFINITELY be implemented. What if I wanted to implement glowing mobs?

I have a dynamic lighting mod that places a light-emitting node above the players head (which in and of itself is a HORRIBLE hack :( ). Since nodes can only be placed on integer coordinates, this makes for a VERY choppy experience for my players.

All of this could be fixed if entities were able to emit light, and the light_source value of the entity could be mutated on the fly. All I would have to do would be set the players light_source value to the light_source value of the item being wielded - VOILA - mine-craft like dynamic lighting.

[rubenwardy]

I think it's fine to implement this in a way that it doesn't affect light levels server side, or at least not how it's stored in the node. Meaning that the lighting part is purely client side, and so can animate nicely. It should be an entity property, which players can ofc have. It shouldn't require shaders but could be optionally made faster using them when enabled

[paramat]

Native-Coder unfortunately it's not that simple, there are issues:

A player holds a light as protection against mobs spawning but they spawn anyway.

Meshes on the client will still need to be updated rapidly, causing low FPS. Because light can spread up to 16 nodes you will always be updating up to 27 mapblocks at a time, this could not be done rapidly so light would move in steps and could not be smooth at all, and wouldn't be much better than the hacky mods used now. Mesh creation is very much a bottleneck so an engine implementation may not help as much as is hoped.

We then have 2 types of light, real and fake, it will be expected that the fake light acts like real light.

[ghost]

Could we update meshes in a separate thread?

[rdnuk]

i don't understand the game code enough to make any recommendation where this is concerned.
But i am curious as to how most other game engines are able to have light and shadows managed separately from the nodes.
Every time a features is suggested in minetest that requires modification to the way lighting works in game, it seems to get shut down with "it wont work" etc, so my guess is that the lighting and shadows systems need an overhaul but would be a massive job?

Why wont it work, Why are light values stored on a node by node basis, and why does minetest come across as one of the few games that cant manage light and shadows properly?

Not trying to undermine anyone, just trying to get an understanding as to why the system was implemented like this, the reasoning etc.

If anyone could help me understand, would be awesome :)

[ghost]

^^^what he said!

[paramat]

Could we update meshes in a separate thread?

Not sure, not sure it would help, if updating meshes is intensive it might not make much difference.

how most other game engines are able to have light and shadows managed separately from the nodes.

I'm not sure most do, and many games are not voxel games so are less demanding on lighting.

Every time a features is suggested in minetest that requires modification to the way lighting works in game, it seems to get shut down

Not every time, and not in this case, i only wrote it will be intensive and not smooth, i also wrote it would be a nice feature to have.
Keep in mind most suggestions will not be possible because they are suggested by people who don't understand how lighting works, and they, understandably, make over-ambitious requests because they want an exciting or powerful feature. In OSS inevitably most requests are not possible or practical.

my guess is that the lighting and shadows systems need an overhaul

Not necessarily, that seems a wrong conclusion coming from misunderstanding.

Why wont it work

In this case it's totally possible, i'm only wrote it will be intensive and not smoothly updating, MC walking light updates only a few times a second too.

Why are light values stored on a node by node basis

Many reasons, much of the game is built around this. There were long discussions between the lighting experts about reworking lighting to include hardware lighting, the conclusion was that the current per-node light values had to remain but be combined with hardware lighting.

why does minetest come across as one of the few games that cant manage light and shadows properly?

It does manage properly. I think it may partly be because you are involved with dev, i expect most OSS games have suggestions and devs often saying 'no we can't do that because ...'. When you're involved with game dev you start to be aware of all the limitations.

why the system was implemented like this

That suggests the system is not so good. It's the same basic system as MC, the system wasn't a mistake, it is probably the most suitable and lightweight method.

[rubenwardy]

I think this is a fairly important feature to have, as lots of games would want this feature. It's very useful