| Time |
Nick |
Message |
| 00:13 |
|
behalebabo joined #minetest-dev |
| 00:57 |
|
natewrench joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:49 |
|
nrz joined #minetest-dev |
| 05:10 |
|
calcul0n joined #minetest-dev |
| 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 |
| 07:39 |
|
lionkor joined #minetest-dev |
| 07:45 |
|
Baytuch joined #minetest-dev |
| 07:59 |
|
Baytuch_2 joined #minetest-dev |
| 09:12 |
|
lionkor joined #minetest-dev |
| 09:47 |
|
HuguesRoss joined #minetest-dev |
| 10:32 |
|
behalebabo joined #minetest-dev |
| 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) |
| 12:06 |
|
proller joined #minetest-dev |
| 12:41 |
|
proller joined #minetest-dev |
| 13:26 |
|
Fixer joined #minetest-dev |
| 13:46 |
|
appguru joined #minetest-dev |
| 13:51 |
|
appguru joined #minetest-dev |
| 13:52 |
|
TaokiLaptop joined #minetest-dev |
| 14:20 |
|
proller joined #minetest-dev |
| 14:21 |
|
Noisytoot joined #minetest-dev |
| 14:27 |
|
TaokiLaptop joined #minetest-dev |
| 15:21 |
|
natewrench joined #minetest-dev |
| 16:10 |
|
natewrench joined #minetest-dev |
| 16:24 |
|
natewrench joined #minetest-dev |
| 16:48 |
|
Warr1024 joined #minetest-dev |
| 16:56 |
|
leha2 joined #minetest-dev |
| 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:39 |
|
Fixer_ joined #minetest-dev |
| 17:42 |
rubenwardy |
There's a lot of people reporting network lag effects even in singleplayer, might be worth looking in to |
| 17:56 |
|
Fixer joined #minetest-dev |
| 18:00 |
|
Baytuch joined #minetest-dev |
| 18:20 |
|
Baytuch joined #minetest-dev |
| 19:03 |
|
Baytuch joined #minetest-dev |
| 19:30 |
|
fluxionary joined #minetest-dev |
| 19:30 |
|
vampirefrog joined #minetest-dev |
| 19:38 |
|
Fixer joined #minetest-dev |
| 20:06 |
|
Baytuch joined #minetest-dev |
| 20:16 |
|
Baytuch joined #minetest-dev |
| 20:17 |
|
natewrench joined #minetest-dev |
| 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:50 |
|
proller joined #minetest-dev |
| 20:50 |
|
Baytuch joined #minetest-dev |
| 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:55 |
|
Baytuch joined #minetest-dev |
| 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 |
| 21:57 |
|
Baytuch joined #minetest-dev |
| 22:12 |
|
Baytuch_2 joined #minetest-dev |
| 22:15 |
|
rubenwardy joined #minetest-dev |
| 22:19 |
|
Baytuch joined #minetest-dev |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:37 |
|
Taoki joined #minetest-dev |
| 22:56 |
|
wsor joined #minetest-dev |
| 23:14 |
|
behalebabo joined #minetest-dev |
