rheo reports: get rid of flowing liquid - it ... #1931

New Issue

yourland-report · 2022-05-17T03:44:06Z

yourland-report commented

2022-05-17 03:44:06 +00:00

rheo reports a bug:

get rid of flowing liquid - it's nothing but problems, unless the flow mechanics are changed to only scale at O(n) instead of O(n^2)

Player position:

{
	y = -1153.7719726563,
	x = 2323.4108886719,
	z = 1404.1940917969
}

Player look:

{
	y = 0.70648944377899,
	x = 0.47300791740417,
	z = 0.52643728256226
}

Player information:

{
	min_rtt = 0.15899999439716,
	max_rtt = 3.5269999504089,
	connection_uptime = 6826,
	max_jitter = 1.8270000219345,
	minor = 6,
	major = 5,
	ip_version = 6,
	formspec_version = 5,
	patch = 0,
	protocol_version = 40,
	serialization_version = 29,
	lang_code = "",
	version_string = "5.6.0-dev-d208be276",
	avg_rtt = 0.17000000178814,
	state = "Active",
	avg_jitter = 0.0030000060796738,
	min_jitter = 0
}

Player meta:

{
	fields = {
		["3d_armor_inventory"] = "return {\"3d_armor:helmet_admin\", \"shields:shield_admin\", \"nether_mobs:dragon_boots 1 4556\", \"\", \"\", \"\"}",
		yl_commons_thankyou = "4",
		jointime = "1644205752",
		yl_commons_player_joined = "1652752235",
		["stamina:exhaustion"] = "26",
		["signslib:pos"] = "(1916,49,1867)",
		["ethereal:fly_timer"] = "-99",
		bitten = "0",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}",
		partychat = "party",
		placed_nodes = "11385",
		yl_church = "return {[\"last_death\"] = {[\"y\"] = 15, [\"x\"] = 1353, [\"z\"] = 1089}}",
		["stamina:poisoned"] = "no",
		["stamina:level"] = "19",
		punch_count = "654",
		arenalib_infobox_arenaID = "0",
		inflicted_damage = "103046",
		crafted = "17",
		xp = "12912",
		played_time = "761868",
		digged_nodes = "3796",
		died = "2",
		hud_state = "on",
		repellant = "0",
		yl_commons_player_created = "1644205752"
	}
}

Log identifier


[MOD] yl_report log identifier = oRdYW5SEsl828KjiWhlpLb8NQI0iPgui

Profiler save:

profile-20220517T054406.json_prettyEE

Status:

# Server: version: 5.5.0-yl | game: Minetest Game | uptime: 1d 11h 32min 37s | max lag: 2.88s | clients: MicaelStarfire, Service, AliasAlreadyTaken, celestial, mrminer, rheo, Lupercus, Alex1977, Bailiff, jj2, shanish2, plod, flux

Teleport command:

/teleport xyz 2323 -1154 1404

Compass command:

/give_compass Construction oRdYW5SEsl828KjiWhlpLb8NQI0iPgui D2691E 2323 -1154 1404

rheo reports a bug: > get rid of flowing liquid - it's nothing but problems, unless the flow mechanics are changed to only scale at O(n) instead of O(n^2) Player position: ``` { y = -1153.7719726563, x = 2323.4108886719, z = 1404.1940917969 } ``` Player look: ``` { y = 0.70648944377899, x = 0.47300791740417, z = 0.52643728256226 } ``` Player information: ``` { min_rtt = 0.15899999439716, max_rtt = 3.5269999504089, connection_uptime = 6826, max_jitter = 1.8270000219345, minor = 6, major = 5, ip_version = 6, formspec_version = 5, patch = 0, protocol_version = 40, serialization_version = 29, lang_code = "", version_string = "5.6.0-dev-d208be276", avg_rtt = 0.17000000178814, state = "Active", avg_jitter = 0.0030000060796738, min_jitter = 0 } ``` Player meta: ``` { fields = { ["3d_armor_inventory"] = "return {\"3d_armor:helmet_admin\", \"shields:shield_admin\", \"nether_mobs:dragon_boots 1 4556\", \"\", \"\", \"\"}", yl_commons_thankyou = "4", jointime = "1644205752", yl_commons_player_joined = "1652752235", ["stamina:exhaustion"] = "26", ["signslib:pos"] = "(1916,49,1867)", ["ethereal:fly_timer"] = "-99", bitten = "0", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}", partychat = "party", placed_nodes = "11385", yl_church = "return {[\"last_death\"] = {[\"y\"] = 15, [\"x\"] = 1353, [\"z\"] = 1089}}", ["stamina:poisoned"] = "no", ["stamina:level"] = "19", punch_count = "654", arenalib_infobox_arenaID = "0", inflicted_damage = "103046", crafted = "17", xp = "12912", played_time = "761868", digged_nodes = "3796", died = "2", hud_state = "on", repellant = "0", yl_commons_player_created = "1644205752" } } ``` Log identifier ``` [MOD] yl_report log identifier = oRdYW5SEsl828KjiWhlpLb8NQI0iPgui ``` Profiler save: ``` profile-20220517T054406.json_prettyEE ``` Status: ``` # Server: version: 5.5.0-yl | game: Minetest Game | uptime: 1d 11h 32min 37s | max lag: 2.88s | clients: MicaelStarfire, Service, AliasAlreadyTaken, celestial, mrminer, rheo, Lupercus, Alex1977, Bailiff, jj2, shanish2, plod, flux ``` Teleport command: ``` /teleport xyz 2323 -1154 1404 ``` Compass command: ``` /give_compass Construction oRdYW5SEsl828KjiWhlpLb8NQI0iPgui D2691E 2323 -1154 1404 ```

AliasAlreadyTaken was assigned by yourland-report

2022-05-17 03:44:06 +00:00

flux added the

1. kind/enhancement

label 2022-05-17 04:10:56 +00:00

flux commented

2022-05-17 04:14:21 +00:00

all flowing liquid nodes could be added to the LBM created in #1633

this would have some performance implications, but probably not as much as letting liquid flow uncontrollably.

another solution would be to modify the engine code to compute flow differently. i think i'm competent enough to do this, but it would be serious work to test it properly, and it's not super high on my priority list. it could even be made a configuration option so as not to break existing setups.

all flowing liquid nodes could be added to the LBM created in #1633 this would have some performance implications, but probably not as much as letting liquid flow uncontrollably. another solution would be to modify the engine code to compute flow differently. i think i'm competent enough to do this, but it would be serious work to test it properly, and it's not super high on my priority list. it could even be made a configuration option so as not to break existing setups.

flux added the

3. source/mod upstream

label 2022-05-17 04:14:33 +00:00

AliasAlreadyTaken commented

2022-05-17 08:01:03 +00:00

Would upstream benefit from such an engine performance fix?

Wouldn't such a lbm mean that all wells and other existing flowing stuff get recalculated and then redone exactly the way they were before, adding more to the load? As long as we don't remove the source node, the flowing will start again, right? Or am I missing something obvius here?

Is there a way to profile liquid reflow?

Would upstream benefit from such an engine performance fix? Wouldn't such a lbm mean that all wells and other existing flowing stuff get recalculated and then redone exactly the way they were before, adding *more* to the load? As long as we don't remove the source node, the flowing will start again, right? Or am I missing something obvius here? Is there a way to profile liquid reflow?

AliasAlreadyTaken added the

2. prio/low

label 2022-05-17 08:01:13 +00:00

flux self-assigned this 2022-05-17 15:06:04 +00:00

flux commented

2022-05-17 17:27:14 +00:00

Would upstream benefit from such an engine performance fix?

Yes, i really don't like the idea of creating our own fork of the engine code.

Wouldn't such a lbm mean that all wells and other existing flowing stuff get recalculated and then redone exactly the way they were before, adding more to the load? As long as we don't remove the source node, the flowing will start again, right? Or am I missing something obvious here?

Yes, it will create some more lag in that case, but less lag in the case of e.g. massive spills in caves that stretch thousands of blocks high and hundreds of blocks wide. Particularly when lava and water spills meet.

Is there a way to profile liquid reflow?

I don't remember exactly, but i tweaked some of the following config values on Blocky, and I remember doing some sort of testing to find acceptable values.

#    Max liquids processed per step.
liquid_loop_max (Liquid loop max) int 100000

#    The time (in seconds) that the liquids queue may grow beyond processing
#    capacity until an attempt is made to decrease its size by dumping old queue
#    items.  A value of 0 disables the functionality.
liquid_queue_purge_time (Liquid queue purge time) int 0

#    Liquid update interval in seconds.
liquid_update (Liquid update tick) float 1.0

current values on blocky are

liquid_update = 3.0
liquid_queue_purge_time = 6

I apparently had liquid_loop_max = 10000 set at some point but I removed that, because I think it was too restrictive.

But none of that solves the general issue.

EDIT:

note that all of these values are trade-offs, with no clear "correct" value.

increasing the liquid_update interval just means there's more nodes that're waiting to flow when you get around to updating liquid
decreasing the liquid_loop_max value doesn't decrease the number of nodes that need to flow
periodically purging the queue doesn't obviate the need for things to flow eventually

In light of that, I don't think I made the right choice with regard to my goals for the blocky performance tweaks, which were to try to make step lengths consistent, because that's best for machines. I should have decreased the liquid update interval, and decreased liquid_loop_max, while adding a large-ish purge time to ensure that the queue doesn't get out of control.

> Would upstream benefit from such an engine performance fix? Yes, i really don't like the idea of creating our own fork of the engine code. > Wouldn't such a lbm mean that all wells and other existing flowing stuff get recalculated and then redone exactly the way they were before, adding *more* to the load? As long as we don't remove the source node, the flowing will start again, right? Or am I missing something obvious here? Yes, it will create some more lag in that case, but less lag in the case of e.g. massive spills in caves that stretch thousands of blocks high and hundreds of blocks wide. Particularly when lava and water spills meet. > Is there a way to profile liquid reflow? I don't remember exactly, but i tweaked some of the following config values on Blocky, and I remember doing some sort of testing to find acceptable values. ``` # Max liquids processed per step. liquid_loop_max (Liquid loop max) int 100000 # The time (in seconds) that the liquids queue may grow beyond processing # capacity until an attempt is made to decrease its size by dumping old queue # items. A value of 0 disables the functionality. liquid_queue_purge_time (Liquid queue purge time) int 0 # Liquid update interval in seconds. liquid_update (Liquid update tick) float 1.0 ``` current values on blocky are ``` liquid_update = 3.0 liquid_queue_purge_time = 6 ``` I apparently had `liquid_loop_max = 10000` set at some point but I removed that, because I think it was too restrictive. But none of that solves the general issue. EDIT: note that all of these values are trade-offs, with no clear "correct" value. * increasing the `liquid_update` interval just means there's more nodes that're waiting to flow when you get around to updating liquid * decreasing the liquid_loop_max value doesn't decrease the number of nodes that need to flow * periodically purging the queue doesn't obviate the need for things to flow eventually In light of that, I don't think I made the right choice with regard to my goals for the blocky performance tweaks, which were to try to make step lengths *consistent*, because that's best for machines. I should have *decreased* the liquid update interval, and decreased `liquid_loop_max`, while adding a large-ish purge time to ensure that the queue doesn't get out of control.

flux commented

2022-05-17 23:58:12 +00:00

Also, the suggestion in the original description of the issue was to get rid of the flowing nodes entirely. Alias_force them all to air. Which would probably deserve the kind/meme label.

I can think of some other saner "flowing" mechanics. I'm just daydreaming here, this isn't a concrete proposal yet.

Starting with the "no flowing nodes of any kind" idea, liquids would end up floating if you dug under them. Turning them into a "falling node" doesn't seem like a good solution for that, given what we already know about the behavior of the mime glue nodes when they were in group:falling. It seems like perhaps instead, liquid source nodes should "flow" into the space below them, using a similar mechanism to the current flowing mechanism. They would fall, but one node at a time, and no entities. This could be extended to let them flow downards-diagonal if that was available. This could further be extended to create new "leveled" liquid nodes - sort of like 1/8th of a water node or something (the scale could be variable), which could flow over onto neighboring "leveled" nodes if their levels were different enough. This sort of mechanic would also interact well w/ my "bucket_redo" mod (see #1746), as that provides a natural way to pick up partial liquid nodes.

Also, the suggestion in the original description of the issue was to get rid of the flowing nodes *entirely*. Alias_force them all to air. Which would probably deserve the `kind/meme` label. I can think of some other saner "flowing" mechanics. I'm just daydreaming here, this isn't a concrete proposal yet. Starting with the "no flowing nodes of any kind" idea, liquids would end up floating if you dug under them. Turning them into a "falling node" doesn't seem like a good solution for that, given what we already know about the behavior of the mime glue nodes when they were in `group:falling`. It seems like perhaps instead, liquid source nodes should "flow" into the space below them, using a similar mechanism to the current flowing mechanism. They would fall, but one node at a time, and no entities. This could be extended to let them flow downards-diagonal if that was available. This could further be extended to create new "leveled" liquid nodes - sort of like 1/8th of a water node or something (the scale could be variable), which could flow over onto neighboring "leveled" nodes if their levels were different enough. This sort of mechanic would also interact well w/ my "bucket_redo" mod (see #1746), as that provides a natural way to pick up partial liquid nodes.

flux commented

2022-05-18 00:07:29 +00:00

Collection of previous dialogue on this topic (this comment will be extended hopefully multiple times)

dynamic liquids mod - doesn't get rid of main issue (O(n^2) behavior), but is interesting.
minetest apparently used to have a "finite liquid" mechanic, but I haven't yet found a description of what it was. it might have been before the git repo started.

Collection of previous dialogue on this topic (this comment will be extended hopefully multiple times) * [dynamic liquids mod](https://forum.minetest.net/viewtopic.php?t=16485) - doesn't get rid of main issue (O(n^2) behavior), but is interesting. * minetest apparently used to have a "finite liquid" mechanic, but I haven't yet found a description of what it was. it might have been before the git repo started.

flux added this to the flux's TODO list project 2022-07-02 21:34:20 +00:00

flux added

2. prio/controversial

3. source/engine

and removed

2. prio/low

3. source/mod upstream

labels 2022-10-28 00:50:30 +00:00

flux added the

4. step/discussion

label 2022-10-28 00:51:45 +00:00

Sign in to join this conversation.