Minetest logo

IRC log for #minetest-dev, 2020-07-04

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
02:57 fluxflux joined #minetest-dev
03:41 Miner_48er joined #minetest-dev
05:36 fluxflux joined #minetest-dev
06:36 NetherEran joined #minetest-dev
07:03 calcul0n joined #minetest-dev
08:00 ShadowNinja joined #minetest-dev
09:26 hecks joined #minetest-dev
09:54 Beton joined #minetest-dev
10:06 Zughy joined #minetest-dev
10:07 Zughy Hey there, I'd like to help you investigating the 5.3 blockers. Any priority?
10:18 sfan5 you can try to reproduce https://github.com/minetest/minetest/issues/10113
10:18 sfan5 the other issues are pretty much solved
10:20 Zughy oh, right, the suicide mission. So I should basically test commits till I find when the degradation starts, right?
10:24 sfan5 well first see if you can actually notice a degradation
10:26 sfan5 if you can reliably reproduce it you can bisect the right commit which takes log2(300) steps
10:29 Zughy it'll be a honor https://eatliver.b-cdn.net/wp-content/uploads/2019/06/weird-smiles6.jpg
10:33 absurb joined #minetest-dev
10:38 Fixer joined #minetest-dev
10:54 _Zaizen_ joined #minetest-dev
10:56 oil_boi joined #minetest-dev
10:58 olliy_ joined #minetest-dev
11:40 celeron55 "the suicide mission" lmao
11:40 celeron55 mentally, so true
11:42 celeron55 physically, maybe take a break every 24 hours and you won't actually die
11:50 erlehmann joined #minetest-dev
11:53 Zughy no ok, abort, it's definitely out of my league. I've spent an hour trying understanding gprof, perf and how server lag works. Too much info, and it's just the preamble. Yet +1 for celeron popping up, it boosted the morale for a while
11:54 Fixer_ joined #minetest-dev
11:55 sfan5 checking if you see a higher lag value on 5.3 compares to 5.2 would've been enough
11:56 Zughy but the max_lag value isn't pretty much useless if we're not talking about spikes?
11:57 sfan5 the lag reported by the server is already some sort of an average
11:58 sfan5 but you could also average the lag over a e.g. 5 minute test run and then compare
11:59 Zughy a 5 minute run for a log2(300) possibilities. That seems fun! I'm on it
11:59 Krock server lag is the last peak value, and degrades slowly over time
12:00 Krock Zughy: 41.1 minutes
12:11 celeron55 pile up some mods and try to get some lag, if you can get some lag, then check if 5.2 has as much, if it does, then try to bisect
12:11 celeron55 if you can't get some lag or 5.2 doesn't have less of it when compared, then there's no point in continuing from there
12:12 celeron55 (other than reporting in the issue about what you tried)
12:20 hecks joined #minetest-dev
12:51 hecks joined #minetest-dev
13:24 Zughy nope, lag is even less than 5.2
14:01 hecks sorry to interrupt, but are mapblock meshes already in world space?
14:02 hecks I'm seeing no matrices being set or anything like that when they're being drawn
14:10 pgimeno aren't they in "camera offset" space?
14:21 hecks I'm asking about the vertex positions specifically; actually, all I need to know if those are already positioned relatively to one another
14:22 hecks in that case I can just concat the mesh buffers straight up, otherwise I'll have to apply the offset
14:41 hecks so this is being applied... to the mesh buffers themselves, huh
14:43 pgimeno camera offset should be obliterated from the code, but I don't think that's possible without modifying Irrlicht
15:08 hecks sadly I'll have to infect the batching with it too
16:32 scrain777 joined #minetest-dev
16:36 scrain777 Noob at minetest. Writing a unittest for collision; struggling to find how to run the unit tests. Building w/ buildbot on Windows mingw32
16:38 rubenwardy ./bin/minetest --run-unittests
16:38 rubenwardy or --run-unittest  I forget
16:38 scrain777 Thanks!
16:53 oiaohm joined #minetest-dev
17:06 oil_boi How does one stop the dtime "relaxing" in singleplayer when you aren't moving around?
17:15 hecks drawtime or server delta?
18:09 hecks so I'm in a situation where video::SMaterial* must be a key in a map, is this okay or is there a better unique material handle to use here?
18:26 celeron55 hmm, that doesn't happen anywhere yet?
18:27 hecks oh well, I'm just wondering if SMaterial pointers could be yanked from under my code, and if there's a more "upstream" value that should be used
18:27 hecks like... a tile ID or something
18:27 celeron55 not that i haven't written half of the trainwreck you're trying to improve, but i can't remember
18:29 celeron55 look at the mesh generator, it probably uses a map somewhere for some stuff
18:30 celeron55 oh, no, it probably doesn't
18:30 celeron55 it uses this contraption called MeshCollector
18:31 hecks oh yeah, and the materials come from collector.prebuffers
18:31 celeron55 which uses just flat arrays and linearly searches through them to find the right one, comparing TileLayers
18:32 celeron55 if you implement hash for TileLayer you could do the same thing using a map i guess
18:32 celeron55 not sure what exactly you are doing though
18:32 hecks I want to improve batching, it's the biggest bottleneck in map drawing
18:33 hecks so I need to merge mapblock meshes sharing the same material into bigger chunks
18:33 celeron55 TileLayer is the upstream value, in its entirely
18:33 celeron55 quite a big value though
18:33 celeron55 entirety*
18:34 hecks and I guess the part where they share the material is where I need some unique identification for it
18:34 hecks clientmap.cpp just cheats and builds this dynamically every frame from SMaterial but that might be brittle if used for longer than that
18:35 hecks of course, I could technically just treat a change in SMaterial as, well, enough of a change to warrant a fresh batch actually
18:37 celeron55 well, in any case TileLayer is what's used for this currently
18:39 hecks alright, thanks... if this can be pulled off, we should see an order of magnitude render perf increase
18:39 hecks yesterday's tests with huge blocksizes were very promising, of course that sucked for different reasons
18:45 celeron55 hmm
18:45 celeron55 where do you get your video::SMaterial that you want to point to?
18:46 celeron55 SMaterial is usually a value that's copied around and not something one makes a pointer to
18:48 celeron55 and it makes sense to compare it as a value rather than as a pointer (not sure if that's implemented, but one can implement that as needed)
18:49 celeron55 TileLayer is basically something that can be converted to an SMaterial but has some extra information and is mostly independent of irrlicht
18:50 celeron55 a generally similar thing anyway
18:53 NetherEran joined #minetest-dev
18:53 celeron55 the current mesh generation code always creates an intermediate result in a MeshCollector and then converts each TileLayer in it into whatever irrlicht needs to make a mesh, and in that process each TileLayer value is converted into an SMaterial value
18:55 celeron55 MeshCollector is designed to be transferrable between the mesh generator thread and the main thread
18:56 celeron55 uh... or is it
18:58 celeron55 no it isn't
18:59 celeron55 the resulting mesh is transferred from the mesh generator thread into the main thread as scene::IMesh*
19:02 hecks I planned to fetch the SMaterial from the mesh buffer just like the map renderer does
19:02 hecks effectively not caring what the mesh is and where it came from, other than its mapblock position
19:04 hecks line 368 of clientmap.cpp is where I got the idea from
19:06 hecks from what I gather, the purpose of MeshBufListList is to batch materials
19:07 hecks and I want to do the same but semi-statically, and also concat the meshbufs to reduce drawcalls by at least a factor of 10
19:10 hecks so it's... a similar thing but it's not actually using a map, huh, it's just linearly comparing the mats
19:15 hecks oh okay I think I can just use the material itself as a map key
19:21 appguru joined #minetest-dev
19:23 Unarelith joined #minetest-dev
19:42 hecks So what's the point of this check? https://github.com/minetest/minetest/blob/da71313e1df3326c2b9ddb410b963ec25682319e/src/client/clientmap.cpp#L399
19:42 hecks It sure makes graphics debuggers unusable
19:45 Unarelith joined #minetest-dev
20:11 oil_boi An interesting discovery, entities slow down clientside even if the server is telling the client it's moving fast
20:13 appguru define "moving fast"
20:15 oil_boi appguru, using move_to: https://youtu.be/OeCXNe1LBEo
20:16 oil_boi The server step isn't slowing down, but for some reason it appears to per client
20:17 appguru are you sure you haven't implemented that behaviour?
20:17 appguru because that sounds like a HUUUUUUUUGE bug if not
20:18 oil_boi It's pushing raw data to on_step, it's per client, I had 2 other people checking if it was only moving faster when they moved and I didn't see it moving faster if I stood still
20:19 oil_boi I have no idea how it's even getting that desynced per client, that means people are seeing it in different positions
20:24 oil_boi Checked on a second client, globalstep is speeding up if I move and it's shown on the first client, the minecart moves around the track faster
20:24 oil_boi Is it from that sleep_ms defined in server env?
20:38 oil_boi Ah man, I just think I'll eat this one and accept that players effect the dtime step calculation rate https://youtu.be/pMh7vWpirOw
20:43 oil_boi I think I managed to work around it, interesting, the rate goal of server step was 0.01 but players can effect that so calculating directly against dtime seems to have fixed this, so ignore that
20:44 hecks somewhat related: when a player is attached to an entity and this entity is moved, the player's client can cause that entity to lag
20:44 hecks and in general it results in this weird state where the client and the server are "arguing" about the actual position
20:44 hecks which visually looks like this jittering
20:45 oil_boi Ah okay, I think in my specific case it was because I was assuming I could do a calculation against the dtime to compensate for server step lag, but it seems to be more constant with just dtime, so quite embarrassing
20:45 pgimeno oil_boi: 0.01? that's crazy
20:46 oil_boi It works with 7 players on a very low spec server :P
20:46 hecks server framerate is rarely an issue, the cost of simulating entities is dwarfed by everything else minetest does
20:47 oil_boi Wait no, the dtime direct calculation is still causing this bug
20:47 hecks can you try computing your own delta time
20:47 oil_boi Ah yes, let me try that
20:53 oil_boi Ah since the minecart is riding upon the absolute boundary of the limitations set within reason to not have a minecart fly off the track (0.5 nodes per tick at 0.01) the boundary that is now being hit is the fact that dtime is not running consistently with the expected behavior of the engine, a consistent clock tick per server step which can be accounted for by manipulating the data per dtime tick, manual dtime
20:53 oil_boi calculations using minetest.get_us_time produce the same state result as shown before
20:54 erlehmann joined #minetest-dev
20:54 oil_boi The only way I can make this happen properly is if I can use move_to outside the scope of the entity in a predefined function which uses after(0,function() end) to escape the boundaries set into the engine by this strange bug
20:55 oil_boi A realtime globalstep handler, sucks man
20:58 oil_boi No, the global after statement is hardcoded into the server env loop, this is a bad condition
21:04 oil_boi I think the only thing possible to do is set a dtime limit and try to iterate over the missed frames if the globalstep loop raises too high to make up for lost calculation frames, but this is an extremely complex thing to implement and balance
21:19 appguru Hmm, throttling client steps if the client does nothing makes sorta sense...
21:20 appguru Updates sent by the server should still be processed tho.
21:31 oil_boi But that also means, literally every mod that is running on any server at this very moment, if this throttle glitch exists in 5.2.0 as well, is running imprecise timing per step, can cause problems
21:31 hecks isn't this just caused by the server chugging and not scheduling enough time for the lua vm?
21:32 oil_boi No, if you look very closely, when you're on a server, if you stand still, other clients also appear more choppy than if you're moving even if they have a perfect connection
21:32 oil_boi clients-> players
21:32 hecks I haven't noticed that because they've always felt choppy :]
21:33 hecks which I've been attributing to crappy interpolation
21:46 Icedream joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext