Time Nick Message 00:46 [MTMatrix] still not sure what to do with #14103. Is it supported somehow or...? 00:46 ShadowBot https://github.com/minetest/minetest/issues/14103 -- Add drawtype sunken and covered by sfence 00:47 [MTMatrix] It feels rude closing it whilst there is a discussion in progress, but nobody is really supporting it (meaning assigning themselves) 00:57 Mantar shame, that's a cool feature 01:47 MTDiscord Zughy, isn't that feature in roadmap anyway? 01:47 MTDiscord Graphical improvements, API improvements... 02:11 MTDiscord Don't let it get closed. Some dev assign yourself, please! Missing Sunken drawtypes is one of the graphical issues with minetest that really should have been fixed long ago. 02:13 MTDiscord Having the ability to mark a node as "don't draw the outside boundary of neighboring nodes, act as if they connect with this node" in general would be really nice. I've got some game types where the level design is fixed, and thus geometry should be optimizable ... and the fact that the game has prepared polygons for faces that can never be seen because of where the player is trapped, and has to cull them from every frame ... just 02:13 MTDiscord feels wrong 😄 02:14 MTDiscord Also, yeah, sfence's pr seems pretty roadmappy 02:18 MTDiscord cx384 was casually paramatting that PR :hyperXD: 02:20 MTDiscord funny how the related issue was approved by paramat 02:21 MTDiscord although, I guess one could say that sfan5 was the one approving the concept 02:46 MTDiscord pgimeno: Indeed, you can convert a quaternion to a matrix, and expect that p * q * v == p.mat() * q.mat() * v, as long as conventions were chosen to be consistent. But it looks like matrix multiplication is also somewhat different than math conventions 08:11 nore btw, does anyone know how the CI works? I don't understand why the last commit of #13687 makes the CI fail on something that looks completely unrelated 08:11 ShadowBot https://github.com/minetest/minetest/issues/13687 -- Client-side translations: gettext and plural support by Ekdohibs 08:57 sfan5 is your branch rebased on latest master? 09:19 nore I rebased it less than a week ago, since I saw you had merged a commit related to it, but it didn't seem to fix it 09:26 sfan5 strange 10:34 pgimeno @paradust oh well, starting with the axis convention choice, little is standard in Irrlicht or MT 17:26 sfan5 should I merge irr#295? 17:26 ShadowBot https://github.com/minetest/irrlicht/issues/295 -- [no sq] Reformat the code (adopted) by Desour 17:29 Desour :+1: 17:42 Desour how do we actually do #13642 in a way that people don't get weird side issues? 17:42 ShadowBot https://github.com/minetest/minetest/issues/13642 -- Import Irrlicht by numberZero 17:43 Desour we have to delete the .git folder in irrlichtmt, as git will otherwise treat it as submodule 17:45 Desour but if you switch from master to the irrlicht import branch, and presumably also when you pull, the .git is there again (but somehow doesn't show up in git status), as well as other files that differ from the imported irrlichtmt 17:47 Desour should we maybe move the imported irrlicht to another directory, and keep the old irrlichtmt repo ignored? 18:23 MTDiscord Rebased #14427 18:24 ShadowBot https://github.com/minetest/minetest/issues/14427 -- Dual wielding (revival) by Andrey2470T 18:26 Desour I haven't found a better way. so I think we should import irrlicht to a lib/irrlichtmt_imported/, and let cmake use that one. 18:27 Desour this way, the old repo will not be magically deleted or anything 18:27 Desour it'll also makes bisecting easier if you can still have the old irrlichtmt there, and have just the old minetest use it 18:30 sfan5 or maybe even under /irr? 18:31 sfan5 that way the paths aren't so long e.g. /irr/src/CIrrDeviceSDL.cpp 18:31 Desour sounds good 18:31 Desour could also be src/irr 18:31 Desour or lib/irr 18:34 MTDiscord Isn't consistent project structure more important than path length? 18:35 MTDiscord Could this be a reasonable time to re-organize the directory structure a little if necessary? 18:36 Desour do you have suggestions? 18:37 MTDiscord I think your lib/irr suggestion makes sense because Irrlicht still has an upstream project. But if we're going to treat it as part of our Minetest codebase, I would suggest maybe putting it under src/irrlicht and moving its includes to include/irrlicht or something. 18:38 MTDiscord Thoughts on that? 18:38 MTDiscord Oh, you suggested src/irr as well. Looks like we're pretty much thinking the exact same thing. 18:39 Desour for now we want to build irrlicht separately though (see https://github.com/minetest/minetest/pull/13642#issuecomment-1902678237 ), because of which it's probably better to not put it into src/ 18:41 MTDiscord It can be built as its own component even if it's in the src/ directory. We already do something like that in our existing code with the headless server vs the client. They share the same source tree but they're two different executables. 18:42 MTDiscord It's also easy to ask CMake to build a single target from the command line without any additional configuration. A simple script could be used to build and package it as a standalone library. 18:44 Desour to keep the import PR simple, it's imo better to not merge the irrlicht cmake project into the minetest cmake project 18:45 Desour (not in the import PR) 18:46 rubenwardy An includes dir only makes sense if you're making a library, I'd prefer to merge the trees into one 18:46 MTDiscord Agreed. Although I don't really have any say in this, I'm not even a core dev. 😄 18:46 MTDiscord (agreeing with Desour) 18:47 Desour contributor feedback is valuable though :) 18:47 rubenwardy especially good not to merge the irrlicht cmake project in if it's super painful cmake code as well 18:48 MTDiscord I was in the process of cleaning it up a lot after the move to CMake 3.12, but I haven't landed it yet. 18:48 Desour we can (and imo should at some point) still move irrlicht around the minetest repo later 18:50 Desour if we first want to merge the irrlicht cmake project into the minetest one, before mergeing into src/, it might be best to put it to /irr, like sfan5 suggested 18:50 MTDiscord I don't think anything has to be done CMake-project-wise at this point, because both are already designed to work correctly in their own project context. 18:50 Desour (because all other libs in lib/ have their own cmake project, afaik) 18:51 MTDiscord What's the benefit of combining it into one project()? 18:51 MTDiscord Versioning, maybe? 18:52 Desour not sure. but there's no real reason to have a separate project, I think 18:52 MTDiscord I think it boils down to whether you want to version it separately or not. 18:53 MTDiscord Or perhaps in a broader sense, whether you want to package them separetely. 18:54 Desour we dont 18:55 MTDiscord Probably a good idea to combine it into one project then like you said. Only thing to be aware of might be that per-project configuration will be shared, so all Minetest's configuration will apply to the Irrlicht code. I expect that to mostly work out of the box but it'd be good to pay attention to that when the merge happens. 18:56 Desour right 18:57 Desour this might also be a thing we want. it's weird if we're using -ffast-math for example in irrlicht only 18:57 MTDiscord It will also make sense to remove all the target export code from the Irrlicht CMake lists, to make things a lot simpler, and some dependency management that is done separately for the two projects can be combined. 18:59 MTDiscord The one annoyance there is that Minetest does much of its dependency management in /src/CMakeLists.txt, so /irr/ won't be able to pick that up. 19:00 MTDiscord I think if you add the subdirectories in the right order it would work, although I'd have to review whether you can link to the irrlicht target before it's been created. 19:58 Desour #14483 19:58 ShadowBot https://github.com/minetest/minetest/issues/14483 -- [no squash] Irrlicht import by Desour 20:08 celeron55_ interesting to see the irrlichtmt line count. that's about a sixth of the upstream irrlicht 1.8.whatever line count as far as i can tell 21:01 sfan5 Desour: i can the fix android the mingw build 21:02 Desour ah nice 21:02 Desour feel free to push to the branch 21:54 sfan5 Desour: probably everything should work now 21:57 Desour thanks! 21:59 sfan5 apparently we're crashing clang++-10 in one CI job 21:59 sfan5 can't hold on to old software forever 🤷 22:16 sfan5 Desour: fyi i pushed a change to the irrlicht mt repo, might wanna include that in the commit 22:18 Desour the irr/.github workflows are currently not run btw. 22:18 Desour I guess we should maybe move them to root .github at some point 22:22 sfan5 dunno. I'm not sure what the goal should be regarding integration into our cmake/test suite/logging or keeping it separate