Time  Nick       Message
06:19 celeron55  Zughy[m]: i'll make you some sort of supertriager team with only you in it
06:19 celeron55  the problem here is, github doesn't have any permission level between the triager and full repo write permissions
06:20 celeron55  so supertriager will have full commit permissions
06:25 celeron55  of course this is practically the same as adding you to the core team
06:28 celeron55  done
10:48 Zughy[m]   <celeron55> "so supertriager will have full..." <- I won't ever try to commit or merge anything, I know it's not my role. Thank you for the role, it'll make core devs life easier
10:49 celeron55  it will definitely benefit everyone
10:54 celeron55  it's a nice achievement to have the same level of trust as the core devs. IMO that also means you're part of the core team
10:55 ROllerozxa hooray!
11:21 Zughy[m]   (I've put a heart reaction to your last message, celeron)
16:57 MTDiscord  <luatic> sfan5: Considering error messages like 2022-08-11 12:45:58 ERROR[Main]: /home/stefan/mt-build/build/minetest_64/minetest/src/serverenvironment.cpp:e9: createIntroductionTimeString: A fatal error occurred: attempted to query on non fully set up LBMManager, is there no option to get rid of the first path?
16:57 MTDiscord  <luatic> i.e. the /home/stefan/mt-build/build/minetest_64/
16:58 sfan5      within the source, not directly
16:58 sfan5      compiler options can help
17:42 rubenwardy There's a lot of people reporting network lag effects even in singleplayer, might be worth looking in to
20:23 MTDiscord  <x2048> Any objections to moving updateDrawlist() to a thread of its own?
20:26 sfan5      concurrent map access is likely to be unsafe
20:32 celeron55  you can't just move stuff accessing the map without creating means to copy the necessary data from the map first
20:32 celeron55  otherwise you just end up locking the thread you wanted to allow to do other things
20:32 MTDiscord  <x2048> mesh gen is in its own thread, right?
20:33 celeron55  yes. and it has a mechanism to copy the full map area it's generating the mesh for
20:34 MTDiscord  <x2048> MeshMakeData::fill
20:34 celeron55  given updateDrawlist() basically needs access to everything, you can't do this at all
20:35 celeron55  you need to optimize it otherwise
20:36 MTDiscord  <x2048> okay, I'll slice it then ?
20:36 celeron55  off the top of my head i'd recommend for example looking at ways the mesh gen could pre-calculate stuff for it to be stored in mapblocks, to speed up whatever it needs to do
20:36 celeron55  whatever updateDrawlist() needs to do, i mean
20:37 MTDiscord  <x2048> I'll start by spreading it over multiple frames
20:38 sfan5      I think that has some nasty side effects
20:38 celeron55  you'll have results based on outdated data, which means flickering
20:39 celeron55  or, unconsistent data, more like
20:39 MTDiscord  <x2048> map does not change that often
20:40 sfan5      but the look direction does
20:40 celeron55  there could be a compacted map representation stored in a separate thread which would be sent changes as they come, and it would maintain the compacted representation of the map for the updateDrawlist() that would be run in that thread
20:41 celeron55  maybe the meshgen could do the compaction
20:41 celeron55  dunno, just throwing ideas at the wall
20:44 MTDiscord  <x2048> if was also playing with diffing the draw list
20:44 celeron55  maybe you could generate a drawlist without concern for look direction, and only furstum cull it in every frame
20:44 MTDiscord  <x2048> only calculating what's changed
20:44 sfan5      whats so inefficient about calculating the draw list anyway
20:44 MTDiscord  <x2048> occlusing culling
20:44 MTDiscord  <x2048> *occlusion culling
20:44 celeron55  yes, definitely occlusion culling
20:45 sfan5      I guess some stuff could be cached for that to go faster
20:45 MTDiscord  <x2048> 95%+ of the time spent
20:45 celeron55  that's the thing that would have to be precalculated in some way
20:45 MTDiscord  <x2048> the problem is that cache becomes invalid as soon as you move
20:47 sfan5      I was thinking maybe cache the sides from which easy mapblock is opaque
20:48 sfan5      but it's been a while since seeing the relevant code
20:53 celeron55  i recall this has been talked many years ago, but nothing came of those discussions
20:53 celeron55  it's not a trivial problem but probably a solvable one
20:57 sfan5      note to self: don't recompile between taking perf results
21:04 MTDiscord  <x2048> I guess what makes sense to cache is the occluders of the occluded block and see if that occlusion still occurs. We could cache just he mapblocks and see if there is still a solid node on the path of the ray.
21:04 MTDiscord  <x2048> That would save a ton of rerunning the rays
21:05 sfan5      re 12679 I tried to unsuccessfully reproduce the performance problem, can't even find getTimerTime() in the flamegraph
21:07 sfan5      there it is actually
21:08 sfan5      https://0x0.st/o2Q2.png before fix, https://0x0.st/o2QL.png after fix
21:08 sfan5      I wouldn't say this improves fps any
21:17 MTDiscord  <x2048> It clearly makes a difference on my system
21:19 MTDiscord  <x2048> http://0x0.st/o2QW.png