| Time |
Nick |
Message |
| 06:35 |
|
calcul0n joined #minetest-dev |
| 07:41 |
|
erlehmann joined #minetest-dev |
| 07:45 |
|
NetherEran joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:01 |
|
Wuzzy joined #minetest-dev |
| 10:00 |
|
absurb joined #minetest-dev |
| 10:51 |
|
_Zaizen_ joined #minetest-dev |
| 11:10 |
|
Fixer joined #minetest-dev |
| 11:46 |
|
Kimapr joined #minetest-dev |
| 11:53 |
|
oil_boi joined #minetest-dev |
| 12:53 |
|
hecks joined #minetest-dev |
| 12:54 |
hecks |
do I need a mutex on meshes when using them? https://a.cockfile.com/K1R82X_aaaaaaa.jpg |
| 12:54 |
hecks |
I don't do anything that could modify them |
| 12:55 |
hecks |
just cloning and concating |
| 12:55 |
hecks |
and then drawing the result |
| 12:56 |
sfan5 |
depends which class "owns" the meshes I'd say |
| 12:57 |
hecks |
MapBlockMesh |
| 12:57 |
hecks |
clientmap seems to have no problem drawing them without worrying about this |
| 12:58 |
hecks |
but I'm getting straight up memory corruption |
| 12:58 |
sfan5 |
maybe the meshgen threads can modify them? |
| 12:59 |
hecks |
actually |
| 12:59 |
hecks |
I've got unrelated threads dying because of this, almost immediately |
| 13:00 |
hecks |
but gdb can continue past that point |
| 13:04 |
hecks |
there is a commented out mutex lock in the mesh gathering part of renderMap() but that mutex no longer exists |
| 13:05 |
hecks |
ah there we go, occasionally this pops up in the trace: |
| 13:05 |
hecks |
#8 0x00000000004941bb in MapBlockMesh::MapBlockMesh(MeshMakeData*, irr::core::vector3d<short>) () |
| 13:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/8 -- Saplings + Growing Trees by MarkTraceur |
| 13:05 |
hecks |
oops |
| 13:06 |
hecks |
then another thread dies, this time it's emerge |
| 13:37 |
celeron55 |
are you sure you're not using a pointer to something someone else in the same thread will delete? |
| 13:38 |
celeron55 |
i wouldn't expect to stumble upon any locking issues as almost everything related to rendering is done in the main thread |
| 13:38 |
celeron55 |
(due to irrlicht and old opengl, obviously) |
| 13:42 |
celeron55 |
if it happens quickly, i would expect valgrind's memcheck to be useful |
| 13:45 |
hecks |
hold on, I think I've got indexing issues due to c++ modulus not actually being modulus |
| 13:46 |
hecks |
that may have trashed stacks |
| 13:50 |
|
Guest88825 joined #minetest-dev |
| 14:19 |
hecks |
The mesh pointers are being relocated every frame somehow...? |
| 14:25 |
celeron55 |
well, the meshes can be re-generated for various reasons |
| 14:25 |
celeron55 |
in which case the entire MapBlockMesh is replaced with a new one |
| 14:26 |
hecks |
but every frame, on a completely featureless flat map? |
| 14:26 |
hecks |
let me stop time as well |
| 14:26 |
celeron55 |
yeah it happens to get the mapblock edges right |
| 14:26 |
celeron55 |
as when a new one comes in it can affect the generation of its neighboring ones |
| 14:27 |
celeron55 |
once there are no transfers going on there should be no mesh generation happening |
| 14:28 |
hecks |
and yet the pointers keep coming |
| 14:28 |
celeron55 |
as you can probably imagine there's a "tile wall" of sorts between each mapblock, which is affected by both mapblocks and is handled currently as being part of one of the mapblocks |
| 14:29 |
hecks |
now the pointers keep repeating |
| 14:29 |
hecks |
as if something was double buffered |
| 14:31 |
hecks |
that's what it looks like: 190558256 to 206981200, 206981200 to 190558256, repeat |
| 14:31 |
hecks |
this is an irrlicht object and who knows how it's being allocated |
| 14:31 |
hecks |
but... pointers shouldn't be yanked from under anyone |
| 14:33 |
hecks |
hmmmmm wait |
| 14:33 |
hecks |
could those be tile layers |
| 14:33 |
hecks |
no that's stupid |
| 14:33 |
hecks |
but then again MapBlockMesh::m_mesh is an array |
| 14:38 |
hecks |
it shuts up when I look at the sky or the ground |
| 14:47 |
hecks |
aaaaaah, more indexing gremlins |
| 14:47 |
hecks |
signed mapblock positions are a loaded gun |
| 14:57 |
hecks |
ok, so curiously, the trivial case of 1x1x1 batches (no-op) works |
| 16:07 |
|
Warr1024 joined #minetest-dev |
| 16:22 |
|
Lunatrius joined #minetest-dev |
| 16:42 |
|
Flitzpiepe joined #minetest-dev |
| 17:03 |
oil_boi |
1x1x1 mapblocks? |
| 17:10 |
|
Seirdy joined #minetest-dev |
| 17:12 |
hecks |
yes |
| 17:12 |
hecks |
so I'm getting this stuff to finally draw, but it's still crashing |
| 17:15 |
hecks |
and, oops, didn't set ehm_static |
| 17:30 |
|
Kimapr joined #minetest-dev |
| 17:31 |
hecks |
so now it draws and it draws FAST, without even frustum culling |
| 17:31 |
hecks |
but why the segfaults |
| 17:32 |
hecks |
must be std maps being lousy |
| 17:32 |
hecks |
gdb is being very vague about where it's dying, how do I make it less vague? |
| 17:34 |
Kimapr |
catchsegv? |
| 17:35 |
hecks |
sigsegv |
| 17:35 |
hecks |
but all it gives me is a function name, and it's not even consistent with that |
| 17:36 |
hecks |
that, or it's dying in more than one place |
| 17:40 |
|
NetherEran joined #minetest-dev |
| 17:48 |
hecks |
okay, exciting; it stopped crashing |
| 18:00 |
Krock |
what are we going to to about the jumping issues? |
| 18:00 |
Krock |
sfan5, rubenwardy ? |
| 18:00 |
Krock |
it's blocking the release and that must somehow be solved... |
| 18:02 |
Krock |
from testing, the two PRs in combination provided acceptable results. yet not perfect, this could probably be turned in 5.4.0-dev? |
| 18:02 |
Krock |
*tuned |
| 18:05 |
hecks |
works https://a.uguu.se/LnWRE4D0wDQw_batched.jpg |
| 18:05 |
hecks |
most of the batches have been trimmed, mesh drawing is now a pitiful 0.4ms |
| 18:06 |
hecks |
now todo: trim the fat from that "preprocess" step, and fix the glitches |
| 18:06 |
Krock |
deadbeef |
| 18:06 |
|
erlehmann joined #minetest-dev |
| 18:07 |
hecks |
had to give the dev exe a bogus hash to differentiate it from all the other minetest executables I have installed |
| 18:26 |
sfan5 |
Krock: the fixes are not perfect? I didn't notice anything in that direction |
| 18:30 |
pgimeno |
hecks: nice progress! |
| 18:30 |
sfan5 |
in any case 5.3.0 is fine to release with both of those fixes IMO |
| 18:39 |
Krock |
hmm, looks like it's luck based |
| 18:39 |
Krock |
https://krock-works.uk.to/u/movement-2020-07-05_20.33.27.mp4 <-- master |
| 18:40 |
Krock |
https://krock-works.uk.to/u/movement-2020-07-05_20.36.11.mp4 <-- 5.2.0-dev |
| 18:40 |
Krock |
sorry for bad VPS |
| 18:43 |
hecks |
it's framerate based |
| 18:49 |
sfan5 |
I have a stable 60 fps here and zero issues fast-climbing |
| 18:54 |
Krock |
sneak glitch no longer works? |
| 18:54 |
Krock |
alright okay |
| 18:56 |
Krock |
nvm. applies the object properties in the wrong place |
| 19:30 |
hecks |
back to the other problem, why does mapblockmesh give me a new mesh every frame |
| 19:31 |
hecks |
I'm just walking in circles or moving the camera, there's no animation going on, time is stopped |
| 19:35 |
Krock |
are you sure that it's regenerated, and not just recycled? the cache hit should be next to 100% |
| 19:37 |
|
Zughy joined #minetest-dev |
| 20:02 |
hecks |
The pointer is different, that's all I know |
| 20:02 |
hecks |
another curious thing: mesh making ms in the profiler is almost constant |
| 20:02 |
hecks |
2ms every frame even though this is a flat server with nothing to do |
| 20:03 |
hecks |
so what that does is... it consumes the mesher queue |
| 20:03 |
hecks |
updateBlock is what feeds it |
| 20:09 |
hecks |
so this is triggered by handleCommand_BlockData |
| 20:09 |
hecks |
by network? |
| 20:10 |
hecks |
if I comment that call out, it doesn't do that any more |
| 20:10 |
hecks |
and while I have to nudge mapblocks so that they appear, they're good now and framerate is in the triple digits |
| 20:12 |
|
_Zaizen_ joined #minetest-dev |
| 20:14 |
celeron55 |
the server is sending mapblocks to the client that it thinks have updated in some way |
| 20:20 |
hecks |
but there's literally nothing to update... |
| 20:20 |
hecks |
and |
| 20:20 |
hecks |
I fired up 5.2 |
| 20:22 |
hecks |
this... doesn't look good https://a.uguu.se/biGdlksszRN1_mesherms.jpg |
| 20:22 |
sfan5 |
9ms to generate a single mesh once? |
| 20:23 |
hecks |
no, this is all mesher work for the frame |
| 20:23 |
hecks |
but there's absolutely nothing for it to work on, and it's receiving packets for it too |
| 20:23 |
hecks |
this is very very bad |
| 20:24 |
hecks |
let's say I'm getting 100 FPS, 5ms drawtime for this trivial scene |
| 20:24 |
hecks |
4.9ms of that is the MESHER |
| 20:24 |
hecks |
well okay, maybe not |
| 20:24 |
hecks |
the skybox is also eating some |
| 20:25 |
|
pmp-p joined #minetest-dev |
| 20:25 |
|
Krock joined #minetest-dev |
| 20:25 |
|
longerstaff13 joined #minetest-dev |
| 20:25 |
|
nore joined #minetest-dev |
| 20:25 |
|
celeron55 joined #minetest-dev |
| 20:25 |
|
Shara joined #minetest-dev |
| 20:29 |
|
_Zaizen_ joined #minetest-dev |
| 20:29 |
|
Icedream joined #minetest-dev |
| 20:29 |
|
cheapie joined #minetest-dev |
| 20:29 |
|
ssieb joined #minetest-dev |
| 20:31 |
sfan5 |
with devtest in a flat world I get exactly zero mapblock updates when not doing anything |
| 20:31 |
|
JTE joined #minetest-dev |
| 20:31 |
|
behalebabo joined #minetest-dev |
| 20:31 |
|
EvergreenTree joined #minetest-dev |
| 20:31 |
|
basxto joined #minetest-dev |
| 20:31 |
|
rubenwardy joined #minetest-dev |
| 20:31 |
|
Calinou joined #minetest-dev |
| 20:31 |
|
Kray joined #minetest-dev |
| 20:31 |
|
aldum joined #minetest-dev |
| 20:32 |
|
tuedel joined #minetest-dev |
| 20:32 |
|
sofar joined #minetest-dev |
| 20:32 |
|
kb1000 joined #minetest-dev |
| 20:32 |
|
rom1504 joined #minetest-dev |
| 20:32 |
|
BakerPrime joined #minetest-dev |
| 20:32 |
|
T4im joined #minetest-dev |
| 20:33 |
|
T4im joined #minetest-dev |
| 20:33 |
|
BakerPrime joined #minetest-dev |
| 20:33 |
|
rom1504 joined #minetest-dev |
| 20:33 |
|
kb1000 joined #minetest-dev |
| 20:33 |
|
sofar joined #minetest-dev |
| 20:33 |
|
tuedel joined #minetest-dev |
| 20:33 |
|
aldum joined #minetest-dev |
| 20:33 |
|
Kray joined #minetest-dev |
| 20:33 |
|
Calinou joined #minetest-dev |
| 20:33 |
|
rubenwardy joined #minetest-dev |
| 20:33 |
|
basxto joined #minetest-dev |
| 20:33 |
|
EvergreenTree joined #minetest-dev |
| 20:33 |
|
behalebabo joined #minetest-dev |
| 20:33 |
|
JTE joined #minetest-dev |
| 20:33 |
|
ssieb joined #minetest-dev |
| 20:33 |
|
cheapie joined #minetest-dev |
| 20:33 |
|
Icedream joined #minetest-dev |
| 20:33 |
|
_Zaizen_ joined #minetest-dev |
| 20:33 |
|
Shara joined #minetest-dev |
| 20:33 |
|
celeron55 joined #minetest-dev |
| 20:33 |
|
nore joined #minetest-dev |
| 20:33 |
|
longerstaff13 joined #minetest-dev |
| 20:33 |
|
Krock joined #minetest-dev |
| 20:33 |
|
pmp-p joined #minetest-dev |
| 20:33 |
|
Zughy joined #minetest-dev |
| 20:33 |
|
erlehmann joined #minetest-dev |
| 20:33 |
|
Seirdy joined #minetest-dev |
| 20:33 |
|
Flitzpiepe joined #minetest-dev |
| 20:33 |
|
Lunatrius joined #minetest-dev |
| 20:33 |
|
Warr1024 joined #minetest-dev |
| 20:33 |
|
hecks joined #minetest-dev |
| 20:33 |
|
oil_boi joined #minetest-dev |
| 20:33 |
|
Wuzzy joined #minetest-dev |
| 20:33 |
|
ShadowNinja joined #minetest-dev |
| 20:33 |
|
calcul0n joined #minetest-dev |
| 20:33 |
|
oiaohm joined #minetest-dev |
| 20:33 |
|
olliy joined #minetest-dev |
| 20:33 |
|
jomat joined #minetest-dev |
| 20:33 |
|
Taoki joined #minetest-dev |
| 20:33 |
|
jonadab joined #minetest-dev |
| 20:33 |
|
Amaz joined #minetest-dev |
| 20:33 |
|
el joined #minetest-dev |
| 20:33 |
|
Foz joined #minetest-dev |
| 20:33 |
|
MarwolTuk joined #minetest-dev |
| 20:33 |
|
vesper joined #minetest-dev |
| 20:33 |
|
Ritchie joined #minetest-dev |
| 20:33 |
|
indiana joined #minetest-dev |
| 20:33 |
|
pgimeno joined #minetest-dev |
| 20:33 |
|
ircSparky joined #minetest-dev |
| 20:33 |
|
Edgy1 joined #minetest-dev |
| 20:33 |
|
ghoti joined #minetest-dev |
| 20:33 |
|
clavi joined #minetest-dev |
| 20:33 |
|
IcyDiamond joined #minetest-dev |
| 20:33 |
|
dzho joined #minetest-dev |
| 20:33 |
|
search_social joined #minetest-dev |
| 20:33 |
|
madwizard joined #minetest-dev |
| 20:33 |
|
ShadowBot joined #minetest-dev |
| 20:33 |
|
Vadtec joined #minetest-dev |
| 20:33 |
|
thePalindrome joined #minetest-dev |
| 20:33 |
|
TC01 joined #minetest-dev |
| 20:33 |
|
Sokomine joined #minetest-dev |
| 20:33 |
|
sfan5 joined #minetest-dev |
| 20:33 |
|
kevinsan joined #minetest-dev |
| 20:33 |
|
Thomas-S_ joined #minetest-dev |
| 20:33 |
|
xerox123 joined #minetest-dev |
| 20:33 |
|
bigfoot547 joined #minetest-dev |
| 20:33 |
|
Qiangong2[m] joined #minetest-dev |
| 20:33 |
|
texmex joined #minetest-dev |
| 20:33 |
|
Awkor[m] joined #minetest-dev |
| 20:33 |
|
bodqhrohro joined #minetest-dev |
| 20:33 |
|
nashimus joined #minetest-dev |
| 20:34 |
hecks |
what about the mesher |
| 20:34 |
|
Wuzzy joined #minetest-dev |
| 20:34 |
|
vesper joined #minetest-dev |
| 20:35 |
sfan5 |
can't find it in the profiler |
| 20:35 |
hecks |
Client: Mesh making, are you sure it isn't there? |
| 20:35 |
|
Lunatrius joined #minetest-dev |
| 20:35 |
|
olliy joined #minetest-dev |
| 20:35 |
|
jonadab joined #minetest-dev |
| 20:35 |
|
Amaz joined #minetest-dev |
| 20:35 |
|
indiana joined #minetest-dev |
| 20:35 |
|
madwizard joined #minetest-dev |
| 20:35 |
|
search_social joined #minetest-dev |
| 20:35 |
|
dzho joined #minetest-dev |
| 20:35 |
|
texmex joined #minetest-dev |
| 20:35 |
|
xerox123 joined #minetest-dev |
| 20:36 |
sfan5 |
oh it's there, but not showing any values |
| 20:37 |
hecks |
same machine or dedicated server? |
| 20:37 |
|
Zughy joined #minetest-dev |
| 20:37 |
|
ghoti joined #minetest-dev |
| 20:37 |
|
clavi joined #minetest-dev |
| 20:37 |
|
vesper11 joined #minetest-dev |
| 20:37 |
sfan5 |
singleplayer |
| 20:38 |
|
Foz joined #minetest-dev |
| 20:38 |
|
MarwolTuk joined #minetest-dev |
| 20:38 |
|
pgimeno joined #minetest-dev |
| 20:38 |
|
Edgy1 joined #minetest-dev |
| 20:39 |
|
Zughy joined #minetest-dev |
| 20:39 |
|
nashimus joined #minetest-dev |
| 20:39 |
|
ircSparky joined #minetest-dev |
| 20:39 |
|
Vadtec joined #minetest-dev |
| 20:40 |
|
calcul0n joined #minetest-dev |
| 20:40 |
|
jomat joined #minetest-dev |
| 20:40 |
|
bodqhrohro joined #minetest-dev |
| 20:40 |
|
bigfoot547 joined #minetest-dev |
| 20:40 |
|
Thomas-S_ joined #minetest-dev |
| 20:40 |
|
ShadowBot joined #minetest-dev |
| 20:40 |
hecks |
something was up with the profiler print interval, now it's printing a more sane value |
| 20:40 |
|
thePalindrome joined #minetest-dev |
| 20:40 |
hecks |
but there's still mesher work unaccounted for |
| 20:41 |
|
kevinsan joined #minetest-dev |
| 20:41 |
|
IcyDiamond joined #minetest-dev |
| 20:42 |
|
TC01 joined #minetest-dev |
| 20:42 |
|
Sokomine joined #minetest-dev |
| 20:42 |
|
sfan5 joined #minetest-dev |
| 20:44 |
|
kb1000 joined #minetest-dev |
| 20:45 |
hecks |
well okay, 5.2 is kind of normal with a truly minimal setup, with a send range of 1 |
| 20:47 |
hecks |
but I don't have my mesh comparer there to really verify it |
| 20:47 |
hecks |
now the same setup in 5.3 still remakes meshes that have no business being remade |
| 20:50 |
|
Lunatrius joined #minetest-dev |
| 20:50 |
|
olliy joined #minetest-dev |
| 20:50 |
|
jonadab joined #minetest-dev |
| 20:50 |
|
Amaz joined #minetest-dev |
| 20:50 |
|
indiana joined #minetest-dev |
| 20:50 |
|
madwizard joined #minetest-dev |
| 20:50 |
|
search_social joined #minetest-dev |
| 20:50 |
|
dzho joined #minetest-dev |
| 20:50 |
hecks |
block send distance of 1, stationary, flying |
| 20:50 |
hecks |
*still* re-sending blocks |
| 20:55 |
hecks |
only when I fly far enough above the map to not have any geometry within the send distance, that's when it stops |
| 20:57 |
hecks |
currently trying to understand how blocks are picked for sending, and I can't find any "dirty" condition |
| 20:58 |
|
texmex joined #minetest-dev |
| 20:58 |
|
Qiangong2[m] joined #minetest-dev |
| 20:58 |
|
Awkor[m] joined #minetest-dev |
| 21:15 |
hecks |
okay so SetBlockNotSent is the dirty bit |
| 22:19 |
|
appguru joined #minetest-dev |
| 22:20 |
|
paramat joined #minetest-dev |
| 22:21 |
paramat |
merging #10025 |
| 22:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/10025 -- Apply camera smoothing to 'not touching_ground' stepheight by paramat |
| 23:34 |
|
hecks joined #minetest-dev |
