Time  Nick       Message
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
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: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: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)
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: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!
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 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: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
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 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