| 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 |
