[1.12.2] Question why placing block triggers like 50 chunk updates

[jabelar]

So I've got a mod that is fairly popular which allows moving lights. But some people have complained about frame rate drop when moving with a light source. However, the general idea is quite simple -- I'm just placing an invisible block with tile entity that has a light level. The tile entity takes care of things like removing the block if the light source moves away. At any given time there is only a couple blocks at most per light source. But if you're moving then a block gets added and old one gets deleted as you move from one position to the next.

 

Anyway, it really shouldn't cause too much perf lag. If you're standing still, it doesn't lag, so it seems to be related to the adding of the blocks. I've gone through and commented out the code to confirm this. Furthermore I played with different flags and notifications in the setBlockState() and related methods.

 

I don't think the light part is actually the problem, I think it is simply the placement of the block. So my question is: Why would like 40 to 50 chunk updates be triggered by placing a block in the player's location using standard World#setBlockState() method?

[V0idWa1k3r]

14 minutes ago, jabelar said:

Why would like 40 to 50 chunk updates be triggered by placing a block in the player's location using standard World#setBlockState() method?

It's not the setBlockState that triggers the updates, it's mostly relighting of stuff since the game stores light data alongside vertex data. Thus when a light level of a block changes the game has to recalculate all light levels in the affected radius. 

You can actually replicate this in vanilla with no mods involved - place like a 16x16x16 cube of fences, then place a torch next to it. Enjoy the game not responding for a bit. 

Related:

https://bugs.mojang.com/browse/MC-126518

 

14 minutes ago, jabelar said:

I don't think the light part is actually the problem, I think it is simply the placement of the block.

Unless your block does something insane placing a block is simply changing some bits in the underlying chunk array, sending newighbour change event to all surrounding blocks(all 6 of them), checking for relighting and sending the data to the clients.

And in any case even if it was the case it would cause tickrate lag, not framerate lag.

 

Unfortunately with the way the game handles lighting there is no clean way of implementing your mod without causing framerate lag. Even the dynamic lights mod that got integrated into OF with it's edits to the base game to avoid placing blocks still causes lighting updates and triggers framerate lag. 

[jabelar]

I'm fairly aware of how all that works. However, I always thought the lighting recalculation was a fairly localized thing. In fact I optimized a massive structure generator by making my own set block method which didn't update the lighting until the end and only did so in a few specific locations rather than recursively throughout the whole structure.

 

The weird thing that is new to me (and hence my question) is why it shows literally 50 chunk updates in conjunction with this placement. I could see why the current chunk might update (actual block placement plus lighting updates) and I could see why a neighboring chunk or two would probably update since the light can spread over 15 radius. But it seems to be way over-doing it.

[V0idWa1k3r]

10 minutes ago, jabelar said:

why it shows literally 50 chunk updates

It doesn't mean there were 50 chunks being updated. This info means that RenderChunk#rebuildChunk was triggered 50 times.

[jabelar]

Okay, that makes more sense. I'm wondering if there is a more efficient way to do the "rebuilding" then. Let me see what that is doing -- if it could be targeted to just the light map updating part that shouldn't really bog things down.

[Draco18s]

Two ways:

1) lower the light brights (ie 12 instead of 15)

2) move the light block less often (eg when the player moves 4 blocks away from it)