Time |
Nick |
Message |
00:10 |
|
troller joined #minetest-dev |
00:29 |
|
troller joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:54 |
|
calcul0n_ joined #minetest-dev |
06:11 |
|
appguru joined #minetest-dev |
06:34 |
|
jwmhjwmh joined #minetest-dev |
08:57 |
|
YuGiOhJCJ joined #minetest-dev |
09:07 |
|
appguru joined #minetest-dev |
09:40 |
|
appguru joined #minetest-dev |
10:14 |
|
appguru joined #minetest-dev |
10:31 |
|
jwmhjwmh joined #minetest-dev |
10:43 |
|
Fixer joined #minetest-dev |
12:09 |
|
troller joined #minetest-dev |
12:25 |
|
olliy joined #minetest-dev |
12:30 |
|
troller joined #minetest-dev |
13:02 |
|
MTDiscord1 joined #minetest-dev |
13:04 |
|
Fixer joined #minetest-dev |
13:49 |
|
appguru joined #minetest-dev |
14:03 |
schwarzwald[m] |
How do I set up Minetest to execute from Visual Studio? When I try to run it, it gives me the error "unable to start program $PROJECT_ROOT\build\x64\Release\ALL_BUILD" |
14:10 |
schwarzwald[m] |
I figured out a workaround: you have to set minetest as the startup project. |
14:13 |
|
olliy joined #minetest-dev |
14:24 |
schwarzwald[m] |
Something seems very wrong with the results from Visual C++'s CPU sampling. |
14:25 |
schwarzwald[m] |
It thinks that over the short devtest game I sampled, std::thread.invoke is responsible for almost all the CPU usage, and it doesn't give any detail about what it's doing beyond that. |
14:26 |
rubenwardy |
make sure you compile in w32 mode, not console mode |
14:26 |
rubenwardy |
I think that's done by cmake if you're using that |
14:26 |
schwarzwald[m] |
Yes, CMake has that option on the executable, so that should be correct. |
14:44 |
|
jwmhjwmh joined #minetest-dev |
15:30 |
|
_Zaizen_[m]1 joined #minetest-dev |
15:39 |
MTDiscord |
<x2048> Does anyone want to take a look at #12791 or are we good with lhohansl's and mine implicit approval? |
15:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/12791 -- Bloom by x2048 |
15:42 |
rubenwardy |
I'm fine with that + testing |
15:42 |
rubenwardy |
maybe check with sfan5 |
15:45 |
sfan5 |
fine by me |
16:02 |
sfan5 |
@appguru have you given the data structure we'd need to fix SAO performance any thought? |
16:09 |
MTDiscord |
<Jonathon> @LM🅱 ^ |
16:21 |
MTDiscord |
<luatic> sfan5: I believe for spatial indexing an R*-trees by selection-/ collisionbox are ideal. It should have a way to do efficient updates or bulk loading as entities move. |
16:21 |
MTDiscord |
<luatic> I made this gist a while ago: https://gist.github.com/appgurueu/80031bb650f614df472e58722241992d |
16:25 |
MTDiscord |
<luatic> So far we (josiah_wi and I) have been eyeballing https://github.com/tuxalin/THST/. From the benchmarks there, it seems updating a thousand entities in the index should merely take ~2ms. We're hoping for the author to implement https://github.com/tuxalin/THST/issues/13. |
16:36 |
sfan5 |
imo that's the first step before the second |
16:36 |
sfan5 |
uh |
16:36 |
sfan5 |
second before first |
16:37 |
sfan5 |
the first step should be throwing all objects so spatial lookup isn't O(n) |
16:37 |
sfan5 |
+into a suitable data structure |
16:39 |
|
appguru joined #minetest-dev |
16:39 |
sfan5 |
constantly updating positions is a bit hard to get right and consistent inside the engine but without alternative |
16:40 |
sfan5 |
so yes we do need a data structure that can do: efficient updates, spatial queries (ideally both range + aabb), query by object id |
16:40 |
rubenwardy |
and ray intersection |
16:41 |
sfan5 |
that's a nice to have, not requirement |
16:41 |
rubenwardy |
yeah, raycaster can use range query and then filter/sort |
16:41 |
sfan5 |
when I experiemented with spatialindex I found it couldn't do the last one (also no idea about perf) |
16:42 |
sfan5 |
so I'm wondering a bit if we're trying to do something that is inherently hard for an area store to support or if that was just spatialindex being unsuitable |
16:43 |
sfan5 |
then if all that is solved putting c- and sboxes directly into the data structure can be looked at |
16:43 |
sfan5 |
but chances are doing only the former already moves performance far enough into the "good" territory that the rest isn't worth it anymore |
17:09 |
MTDiscord |
<luatic> sfan5: yeah, we found the same, but this is just spatialindex being unsuitable |
17:09 |
MTDiscord |
<luatic> libspatialindex also uses R-trees, but the line-box intersection was limited to 2D IIRC |
17:10 |
|
proller joined #minetest-dev |
17:10 |
MTDiscord |
<luatic> but R-trees are just hierarchies of boxes - so you have a box enclosing a bunch of boxes, rinse and repeat |
17:10 |
MTDiscord |
<luatic> you can leverage this when raycasting to just check whether the ray hits the parent box - if not, skip it and all its children |
17:11 |
MTDiscord |
<luatic> then apply this recursively |
17:28 |
sfan5 |
can THST do queries by object id? |
17:32 |
|
jwmhjwmh joined #minetest-dev |
17:33 |
jwmhjwmh |
Would it be acceptable for CSMs to have access to core.get_content_id and core.get_name_from_content_id? |
17:36 |
sfan5 |
they have no use for it atm |
17:39 |
sfan5 |
rubenwardy: the apk link on the website was not updated... |
17:53 |
MTDiscord |
<luatic> sfan5: If it doesn't, we can just slap an additional unordered map on it. |
17:53 |
sfan5 |
no |
17:53 |
sfan5 |
to update the position of an object you need to query it in the map, you don't want to do this by looking up the old position |
17:54 |
sfan5 |
same for removing an object |
17:55 |
MTDiscord |
<luatic> well yes |
17:58 |
MTDiscord |
<luatic> although TBF when you use any other index data structure you basically do the same; heaps can reduce overhead if they have a dedicated update(), but asymptotically it makes no difference |
18:00 |
schwarzwald[m] |
The ncursesw find script is cursed. |
18:01 |
MTDiscord |
<luatic> as for simpler spatial indexing alternatives, one could also consider (1) indexing by mapblock, as numzero had implemented (downside: won't deal well with odd distributions of entities, e.g. many entities - say chess pieces - in a mapblock) (2) using an octtree (the one Irrlicht provides is geared towards rendering too much though) (3) using a k-d-tree (I'm not aware of any decent rebalancing though; also this would be pretty much point |
18:01 |
MTDiscord |
rather than box-based) |
18:09 |
sfan5 |
thinking about it, indexing by id is not achievable without also storing all entities (or pointers) in an ordinary map of sorts |
18:09 |
sfan5 |
so looking for datastructure that does both spatial and direct indexing is kinda misguided |
18:09 |
MTDiscord |
<luatic> yes |
18:09 |
sfan5 |
however it's still much better if this is part of the data structure design instead of bolted on as a hack |
18:11 |
sfan5 |
("here's a pointer to the data structure node where this entity resides" is still a step above "this the position where it was last time, check if you can still find it" after all) |
18:14 |
schwarzwald[m] |
sfan5, maybe I missed something, but what I'm seeing right now is that FindNcursesw.cmake does not throw an error if it isn't found. |
18:19 |
|
proller joined #minetest-dev |
19:28 |
|
diceLibrarian joined #minetest-dev |
19:39 |
schwarzwald[m] |
Confirmed this BTW - if Ncursesw is not found then it defaults to the built-in FindCurses.cmake and it's hardcoded to not be REQUIRED. |
20:07 |
|
jwmhjwmh joined #minetest-dev |
20:09 |
jwmhjwmh |
sfan5: Do you feel that your most recent comment on #11885 has been addressed? |
20:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/11885 -- Add unittests for item movement code by savilli |
20:15 |
sfan5 |
I would still prefer if those changes weren't necessary (think RAII) but there's no use holding up the commotion |
20:16 |
sfan5 |
ok maybe commotion is too negatively connotated but you get what I mean |
20:17 |
jwmhjwmh |
Alright, thanks. Merging #11885, #11939, and #12766 in 5m. |
20:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/11885 -- Add unittests for item movement code by savilli |
20:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/11939 -- Restore and enhance bouncy behavior by pecksin |
20:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/12766 -- Pause shader animation timer in singleplayer pause menu by Desour |
20:24 |
Zughy[m] |
Can we have a Hacktoberfest label for.. well, the Hacktoberfest? |
20:25 |
|
Desour joined #minetest-dev |
20:25 |
Zughy[m] |
I'm pretty sure Minetest can handle it without burnouts, considering how TurkeyMcMac is doing |
20:26 |
|
YuGiOhJCJ joined #minetest-dev |
20:28 |
jwmhjwmh |
I'll try not to burn out myself. |
20:31 |
|
Pexin joined #minetest-dev |
20:54 |
MTDiscord |
<x2048> Any chances for #12379 to be merged soon? I'm asking because I want to move rendering of selection boxes into an ISceneNode implementation to fix z-fighting in #12717 |
20:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/12379 -- Allow rotating entity selectionboxes by appgurueu |
20:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/12717 -- new particle api breaks node highlighting box and halo |
21:04 |
sfan5 |
I can approve it right now if that helps |
21:10 |
sfan5 |
done |
21:16 |
|
jwmhjwmh joined #minetest-dev |
21:38 |
|
jwmhjwmh joined #minetest-dev |
22:35 |
|
panwolfram joined #minetest-dev |
22:47 |
|
Noisytoot_ joined #minetest-dev |
22:57 |
schwarzwald[m] |
Am I right in my understanding that ncurses does not work with vcpkg on Windows 11 and that I don't need it to build Minetest? |
23:04 |
|
AliasStillTaken joined #minetest-dev |
23:11 |
|
Noisytoot joined #minetest-dev |
23:20 |
|
YuGiOhJCJ joined #minetest-dev |
23:32 |
schwarzwald[m] |
Nevermind, that's not even my biggest issue right now. |
23:32 |
schwarzwald[m] |
I have an unbelievable amount of errors coming from Windows header files about redefinitions and missing declarations. |