Minetest logo

IRC log for #minetest-dev, 2021-09-04

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:00 Calinou joined #minetest-dev
00:00 ssieb joined #minetest-dev
00:01 Taoki joined #minetest-dev
00:03 Noisytoot joined #minetest-dev
02:26 queria^clone joined #minetest-dev
02:30 queria^clone joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
05:00 YuGiOhJCJ joined #minetest-dev
05:27 Extex joined #minetest-dev
06:34 ssieb joined #minetest-dev
06:44 olliy joined #minetest-dev
06:58 ssieb joined #minetest-dev
09:36 Fixer joined #minetest-dev
09:43 tech_exorcist joined #minetest-dev
10:05 specing_ joined #minetest-dev
10:11 calcul0n joined #minetest-dev
10:14 tech_exorcist joined #minetest-dev
10:42 proller joined #minetest-dev
10:49 proller joined #minetest-dev
12:42 Fixer_ joined #minetest-dev
15:32 Thomas-S joined #minetest-dev
15:32 Thomas-S joined #minetest-dev
15:34 Thomas-S joined #minetest-dev
15:34 Thomas-S joined #minetest-dev
15:53 Extex joined #minetest-dev
16:29 proller joined #minetest-dev
16:36 longerstaff13 joined #minetest-dev
16:45 Krock Kind reminder that a meeting in 1h 15min. There was none last week, hence repeating now according to the reactions on GitHub
16:55 ivanbu joined #minetest-dev
17:59 Krock ping nrz rubenwardy sfan5 ShadowNinja
17:59 sfan5 hi
17:59 Krock hello! no hurries. just pinging to make sure :3
17:59 nrz hi, i should put children to bed but i'm there async 馃槃
17:59 ShadowNinja o/
18:00 Krock Half a year has passed since the last meeting, so it might make sense to check what's needed for the next release
18:01 Krock I might be wrong about that half year though. it's just the last team meeting mentioned on github :)
18:02 Krock so we're at 1000 open issues again. this is fine 馃敟
18:03 nrz i don't understand how it's possible regarding the amount of bugfixes done on this milestone 馃槃
18:04 MTDiscord <josiah_wi> But numbers of open irrlicht issues are consistently going down which is fun to watch.
18:04 Krock fun? more like relieved.
18:04 nrz not fun, it's just the work accomplished by forking has reached his goal
18:05 Krock There does not seem to be much special in the milestone tbh. It's PRs that are needed for most points
18:05 calcul0n_ joined #minetest-dev
18:06 Krock Also #6765 was added back in to improve light calculations, from what I can see. The PR looks alright, and only needs testing? I could do that.
18:06 ShadowBot https://github.com/minetest/minetest/issues/6765 -- Add more neighbors on mesh update by numberZero
18:06 Krock although I wonder whether this feature will ever be used
18:07 rubenwardy Here
18:07 Krock hello :)
18:07 Krock light artefacts or glitches are not that common any more, and barely anyone might care about this setting
18:07 Krock hence using the "simplified" version forever
18:08 Krock rubenwardy: do you remember why this PR was added to the milestone?
18:08 rubenwardy I don't
18:10 Krock too bad. it's really something that would best fit into performance optimization tweaks
18:10 Krock however since this PR defaults to performance, it might be unused forever. hence I don't see much of a point to keep it as milestone tbh
18:11 Krock 14% more CPU cycles when the PR is enabled, according to Rixer
18:11 Krock *Fixer
18:14 Krock commented.
18:14 sfan5 the glitches are common, just situational
18:15 Krock they look weird indeed. so correct visuals as baseline would be optimal, where performance-focused people would tweak the setting
18:15 Krock I guess that's the fair trade-off to fix this issue but still provide tweaking potential
18:16 sfan5 we would have a thousand settings if that was done consistently
18:17 Krock right. for such things it would more make sense to have a single setting to switch between performance, balanced or "correct" behaviour
18:17 Krock or well
18:17 sfan5 yeah that'd be possible
18:18 Krock or numeric: 聽performance_tweak = 0 聽for the most correct, 聽and performance_tweak = 100 for glitchy but fast gameplay, as percentage perhaps
18:19 sfan5 I'm okay with a single boolean setting for this; that could perhaps then be enabled by default on Android where performance matters a lot
18:19 sfan5 only 0.001% players would ever toggle it manually
18:22 Krock makes sense, yes.
18:24 Krock Next: #11040 - this looks like a generic tracking list for continuous Irrlicht workaround deprecation or fixes
18:24 ShadowBot https://github.com/minetest/minetest/issues/11040 -- Revisit Irrlicht workarounds
18:25 Krock is this a mandatory milestone for 5.5.0?
18:25 Krock i.e. important?
18:26 Krock anyway. it can be kept in the milestone. PRs might come or not; does not really matter
18:27 sfan5 it's not mandatory
18:27 sfan5 will probably become relevant anyway when hecks brings his opengl rewrite
18:27 Krock yes, right.
18:27 specing have you thought about cooperating on the engine with supertuxkart (who I'm told are also using irrlicht)?
18:28 Krock yes, they also have their own, heavily modded irrlicht framework
18:28 nrz specing, we talked about this 4 years ago and it was heavily modified for their needs then i think now...
18:28 nrz 馃槃
18:28 Krock cooperation would be an interesting approach, but someone would have to ensure they still somehow offer the features we need
18:29 specing nrz: alright
18:29 nrz Krock: i'm not sure it's possible now, except if we can make some parts modular to have common effort
18:30 nrz ie. the input part
18:30 specing I personally do not like the engine fracturing of the foss world, because it ultimately reduces the manpower available per engine and thus features
18:30 specing and then I get told that foss games look like they're from 2000
18:30 Krock and a decision on which version control to use. I believe they have the framework within their SVN tree
18:30 nrz specing: the foss game look like is more than there is near zero graphist people doing FOSS
18:31 nrz SVN = beuark
18:31 specing nrz: graphics as in graphics stack coding or graphics as in artists?
18:31 nrz you said games looks like 2000, then i talk about artists 馃檪
18:32 specing nrz: you talked about "graphist people"
18:32 nrz yep sorry i don't have the english terms for that 馃槃
18:33 specing There is an artist who has his own libre first person shooter (that looks like its from 2015+)
18:33 specing based on Torque3D
18:33 specing He said that all other engines are garbage :P
18:33 Krock it would be great if the patches could be backported to the original repository but tbh sourceforge is a PITA, including SVN
18:33 Krock for now it's much easier to do our own thing in a separate project
18:34 specing I don't personally mind the "garbage looks" (I'm playing a zdoom-based game right now), but it does limit me when I'm trying to promote libre games to people outside the foss world
18:35 Krock Next: #11466 - I assume you're still busy, rubenwardy ?
18:35 ShadowBot https://github.com/minetest/minetest/issues/11466 -- Use scoped app storage on Android by rubenwardy
18:35 specing where the graphics is a sore thumb
18:35 Krock the earlier it's merged, the better, I suppose. however, there were a few suggestions which might be worth considering
18:35 MTDiscord <GreenXenith> Most of graphical garbage comes from low-quality textures and models. You can have great looking games with FOSS engines when you know what youre doing with art.
18:36 MTDiscord <GreenXenith> Unfortunately FOSS communities arent known for attracting a ton of artistic talent .. good art isnt cheap to make (effort-wise)
18:37 MTDiscord <GreenXenith> tl;dr dont blame the engine for 2000s-looking graphics
18:38 Krock nrz: do you have any opinion on #11014? Otherwise it looks like it's going to be closed
18:39 ShadowBot https://github.com/minetest/minetest/issues/11014 -- Send only relevant ItemStack meta fields to Client by EliasFleckenstein03
18:39 specing Well sure, but then again... can FOSS engines handle 2020 artwork?
18:39 MTDiscord <GreenXenith> The year doesnt determine how many polygons art has
18:39 Krock for being the wrong approach. I do like the concept, but the way/implementation really ins't that great
18:40 MTDiscord <GreenXenith> Just because UE5 wants to cater to artists that think trillions of triangles is an acceptable tradeoff doesnt mean thats how it should be done
18:43 Krock @GreenXenith However there's a vertex limit within Irrlicht I think
18:44 Krock overly complicated models cannot be loaded into Minetest
18:44 sfan5 Irrlicht does no have non-indexed rendering and indexes can only be u16
18:44 sfan5 so 64k
18:44 Krock ah okay. thanks.
18:44 MTDiscord <GreenXenith> Oh, im not saying irrlicht is a good engine in any way
18:44 sfan5 should also be moot with the opengl rewrite/redo
18:44 MTDiscord <GreenXenith> It definitely has awful technical limitations due to poor implementation
18:44 Krock just wanted to mention that for the sake of completion
18:44 nrz why are we diverging about irrlicht engine ? we are talking about releasing 馃槃
18:45 Krock nrz: just processing the open points on the milestone and wiki/meeting points
18:45 Krock there's still many issues open in the milestone, hence I doubt a release comes anywhen soon
18:45 nrz yeah but complains aboutr irrlicht is not good is not the point of the meeting 馃槃
18:45 nrz we do with what we have currently
18:45 Krock however, there should be a release in November to update the Play Store apk
18:46 nrz and it's sufficient for MT currently, we don't need modern engines features for our voxel game
18:46 Krock right
18:46 MTDiscord <GreenXenith> what voxel game
18:46 MTDiscord <GreenXenith> MTG isnt supposed to be the standard any more
18:46 sfan5 Krock: earlier would be better, but that release would be based on 5.4.1 anyway
18:46 sfan5 @GreenXenith devtest ;)
18:47 MTDiscord <GreenXenith> Ok fair but that definitely shouldnt be what you base features off of :]
18:47 Krock I'll just randomly assign 16 October. Let's see that the milestones are in a good shape by then
18:48 Krock and even if not, it should be a reminder to set priorities
18:48 Krock because "roughly august" is definitely over
18:49 Krock and there's still visual issues due to the dynamic shadow PR which should be resolved by then
18:49 specing Heh. So you say that you can't get artists and then an artists tells me that all foss *engines* are garbage. I guess you could use this fork to bring irrlicht or whatever you make of it on par with 2020 commercial engines
18:49 specing (minus torque3d, it was acceptable they said)
18:50 sfan5 Krock: well there's a few things blocking release; hecks OpenGL rewrite is pretty much a requirement
18:50 *聽specing suspects that there will be barely enough manpower to maintain it at T-20years level
18:51 Krock sfan5: to be fair, Minetest is still playable
18:51 sfan5 alternatively we could work around or individually fix the issues to get 5.5 out
18:51 Krock it surely would be nice to have that
18:51 sfan5 yes
18:53 Extex joined #minetest-dev
18:54 sfan5 #11365 are #11206 release blockers for me (the android stuff can be solved separately)
18:54 ShadowBot https://github.com/minetest/minetest/issues/11365 -- Shadowmaps can not be disabled by the server
18:54 ShadowBot https://github.com/minetest/minetest/issues/11206 -- spritesheet support of sprite entities stopped working
18:54 sfan5 so we'd either need to somehow fix these so that 5.5 can be released in an acceptable state
18:54 sfan5 or wait for the opengl rewrite to fix both
18:56 Krock noted.
18:56 nrz why opengl rewrite is a requirement ?
18:56 sfan5 to disable shadowmaps shaders need to be able to be swapped out at runtime, our current system makes this impossible
18:57 sfan5 the second issue would probably be fixed "by accident" when that code is rewritten
18:57 nrz it's a new features added on this release cycle ?
18:57 sfan5 yes
18:57 Krock there's also a few workarounds in the code that could be removed afterwards (if addressed by the rewrite)
18:57 sfan5 the other option is to disable shadowmaps in the release version
18:57 sfan5 (and fix the other issues by manual investigation)
18:58 sfan5 like Krock already said releasing 5.5 would be nice because it has so many improvements so far, but I'm not sure which path we want to take
18:58 Krock I mean, the dead simple solution so far would be to remove the main menu dropdown for shadowmaps
18:58 nrz ok there is some bugs to fix, but do we have blockers ?
18:58 celeron55 disabling shadowmaps by default and allowing it to be enabled from advanced settings (not the main settings page) came to my mind also
18:59 sfan5 well yes I just named two
18:59 Krock and default to "off" so that manual modification is needed to test them, including all its resulting bugs
18:59 nrz we can disable it with an option
18:59 nrz and let people test it with a expert setting ? 馃檪
18:59 Krock celeron55: you ninja'd me :3
18:59 nrz lol same
18:59 sfan5 if we allow users to enable them in the default config game authors will still yell at user over having no control
19:00 Krock well. it's not their fault
19:00 sfan5 s/user/us/
19:00 sfan5 so if this is done I think the better alternative is to really disable them inside the code
19:01 nrz compile time option then,, ?
19:01 sfan5 no option at all
19:01 celeron55 it would go against our principles, yes, altough we don't really have guidelines for experimental features
19:01 sfan5 if people want shadows they can download a dev build
19:01 Krock nrz: more like replacing g_settings->getBool() 聽with false
19:01 nrz then just go ahead
19:01 Krock where the setting is checked
19:02 nrz and move setting to advanced mode and change label to prefix with [EXPERIMENTAL] ? 馃檪
19:02 Krock ^ <sfan5> if we allow users to enable them in the default config game authors will still yell at us over having no control
19:02 sfan5 we released an experimental feature with no way to disable it once (CSM) and look where that got us
19:03 Krock that's a point. even if I don't understand the game author's problem - really - it might be best to disable it entirely
19:03 nrz i don't understand why game author will complain ? what is the issue ? if people break their shadows on their client, it's their problem no ?
19:03 sfan5 https://github.com/minetest/minetest/issues/11365
19:03 nrz with a CSM feature is required for shadows ?
19:03 Krock !title
19:03 ShadowBot Shadowmaps can not be disabled by the server 路 Issue #11365 路 minetest/minetest 路 GitHub
19:03 celeron55 nrz: the people who break the games with shadows will complain to the game authors
19:03 celeron55 which is a problem for the game authors
19:03 Krock ,... and that because they forgot that shadow maps are experimental
19:03 sfan5 anyway I guess I should create an issue so the possibility to hot-fix + release 5.5 instead of waiting can be properly discussed and consensus reached
19:04 nrz people will commplain about rendering issues on shadows to game owners ? they don't see the distingo between the client and the game ? 馃槷
19:05 celeron55 my vote is on permanently disabling shadowmaps in the release, because there's no minimum release interval and a next release with shadows can be made at any time when it's actually ready
19:05 Krock nrz: don't set your expectations on users too high.
19:05 nrz don't put a CSM flavour for this setting, shadows have no sense to be disabled by servers owners
19:05 nrz Krock: sorry i have some hope 馃槃
19:06 sfan5 games will need to be able to be disable shadowmapping, thereforce server owners can automatically do it too
19:06 sfan5 therefore*
19:06 MTDiscord <Jonathon> people also complain when there local settings breaks a game because client settings override ones mods/games set
19:06 Krock nrz: I also don't think this server->client enforcement is needed, but better safe than sorry. disabling in C++ seems to be the go-to.
19:07 sfan5 anyway what about the meeting points
19:07 sfan5 is that all
19:07 celeron55 the thing is, the enforcement is not _really_ needed at this time, but we have to set a precedent in game authors having control over graphics
19:07 specing nrz: on the contrary, please put a csm restriction for this, it gives people more incentive to use better clients :P
19:07 Krock I'd like to know whether #11014 and #11274 should be closed
19:07 ShadowBot https://github.com/minetest/minetest/issues/11014 -- Send only relevant ItemStack meta fields to Client by EliasFleckenstein03
19:07 ShadowBot https://github.com/minetest/minetest/issues/11274 -- Fix: automatic selection / deselection of dependent mods at world configuration by kuklinistvan
19:08 sfan5 I vote close for both
19:08 Krock former for bad implementation, latter for overly complex
19:08 Krock objections?
19:08 nrz if you put that on CSM restriction, then why not all settings ? haha
19:08 nrz nop
19:11 Krock if anyone's got some time, please feel free to test #11445. It's a minor bugfix. I don't remember why I put that into the meeting points
19:11 ShadowBot https://github.com/minetest/minetest/issues/11445 -- Player death: Fix item duplication by SmallJoker
19:12 Krock joystick controls were merged. done. that's good.
19:12 sfan5 I think moving the callback to the end of the server step isn't a good solution, but I don't have a better idea
19:13 Krock well I also thought of other solutions, but doing this async in the server step seems to be the only solution
19:13 Krock because API calls might be nested in various weird ways
19:14 sfan5 though: if player death is delayed are there things that could happen after the player is alreay dead but before the callback is called? that would violate expectations a lot
19:14 sfan5 thought*
19:15 Krock on_use cannot be called by dead players, if you meant that
19:15 sfan5 no but literally anything
19:15 Krock hmm
19:16 Krock it might be possible to move the death handling code after the callback run
19:17 sfan5 http://sprunge.us/7HmteK?lua engineered example but should explain my concern
19:18 Krock oh yes! you're totally right
19:18 longerstaff13 joined #minetest-dev
19:18 Krock I'll have a look at it again soon. Thanks for the input
19:18 sfan5 good luck with a solution, I couldn't think of one yet
19:18 Krock especially because do_something could be called within on_use too
19:19 Krock which exactly causes this logical problem
19:19 sfan5 next one #11367
19:19 ShadowBot https://github.com/minetest/minetest/issues/11367 -- New move code: Only snap to collision box only on fall by SmallJoker
19:19 sfan5 in principle okay IMO but I have somewhat liked to jump up to nodes with sneak pressed and snap to them in the past
19:19 Krock right. I'd like to know whether this could possibly break any mechanics
19:20 sfan5 if it's meant to fix noclipping another solution can surely be found
19:20 Krock you'll still snap, except only when going down
19:20 sfan5 for example instead of literally modifying the position modify the player velocity to keep them on/towards the edge
19:20 sfan5 that way collision detection would still apply
19:21 sfan5 (I don't know what the sneak code currently does)
19:21 Krock short: it checks for the nearest collision and snaps to its largest bounding box
19:21 sfan5 snaps the position right?
19:22 Krock yes. no velocity or acceleration involved.
19:22 sfan5 sounds bad
19:22 celeron55 i also use the sneak when jumping "glitch" to snap to surfaces upwards
19:23 Krock move_to could be used to make this movement smoother, which then again makes it more sluggish
19:23 Krock agh. move_to does not exist on localplayer
19:23 celeron55 (with knowing it was never intended to work that way)
19:24 Krock celeron55: so the correct approach in your opinion would be to snap... when?
19:25 celeron55 the correct approach is probably to snap only when falling, but it does change the movement feel once again
19:25 Krock yes right. either the issue is fixed with a slight movement change, or it's open forever with this special snap behaviour
19:25 celeron55 it's somewhat likely nobody is dependent on that behavior though, as the only capability it gives is being able to do certain movements a bit faster
19:27 sfan5 *googles "minetest speedrunning"*
19:28 sfan5 semi-related: I'm still bothered by the unconditional upwards camera smoothing that was added in 5.2.0 to cover up some sneak-related(?) thing that was deemed too bad
19:29 Krock right. I also remember one PR which made the movement feel a bit more sluggish
19:30 Krock though I thought it was a PR for regular jumping and/or staircase walking, and not sneak
19:30 sfan5 oh yeah right, not sneak
19:30 sfan5 staircase was it, it's not meant to apply to regular jumps (IMO)
19:32 Krock https://github.com/minetest/minetest/pull/10025
19:32 Krock !title
19:32 ShadowBot Apply camera smoothing to 'not touching_ground' stepheight by paramat 路 Pull Request #10025 路 minetest/minetest 路 GitHub
19:32 sfan5 yea
19:33 Krock I really don't know any more. it's been too long since this PR. it might be worth to have a look at it once more again
19:33 sfan5 I tried to make it not apply to regular jumps once but failed :(
19:34 Krock it might help to preserve and check against the step_up variable
19:34 Krock or to forward this information to the collision information
19:35 sfan5 if I remember correctly I even tried that but the step_up information disappears to fast to appear any useful smoothing
19:35 Krock that aside; I don't have any other meeting points.
19:36 sfan5 I have two things I'd like to mention
19:36 sfan5 #11550 <- reviews plz
19:36 ShadowBot https://github.com/minetest/minetest/issues/11550 -- Dynamic_Add_Media v2 by sfan5
19:36 sfan5 and #11545
19:36 ShadowBot https://github.com/minetest/minetest/issues/11545 -- animated particlespawners by velartrill
19:36 sfan5 it'd be nice if someone else with an opinion could look at it and give feedback
19:37 Krock I can give a shot at the dynamic media PR. I haven't used this feature yet, hence might run into a few questions
19:38 sfan5 oh and also there are 5 PRs with "Roadmap: Needs approval" overdue, these should be closed if we can determine that they have been considered by one or two devs IMO
19:38 MTDiscord <Jonathon> if certain pull requested are being asked to be looked at, could https://github.com/minetest/minetest/pull/11130 be looked at as well? (already has one approval)
19:39 sfan5 I'm the obvious target for looking at that again, I'll get to it eventually...
19:39 sfan5 next on the meeting list would be to look at https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+label%3A%22One+approval%22 and consider for merge
19:40 MTDiscord <Jonathon> i like how one of those has possible close on it
19:40 MTDiscord <Jonathon> https://github.com/minetest/minetest/pull/8448 i assume since rebased that can be removed?
19:41 sfan5 yea
19:43 sfan5 *crickets*
19:44 Krock currently checking the roadmap prs
19:45 proller joined #minetest-dev
19:45 sfan5 sure, say when you're ready (also ping nrz)
19:45 MTDiscord <Jonathon> also, random question, minetest_game is in "maintenance mode/no new features", but for all intents and purposes is abandoned(looking at core dev involvement in issues and PR's). is this intended?
19:45 sfan5 good question
19:46 Krock it's a bit abandoned. I'd spend more time there if I had more time and motivation. it's really not supposed to stall
19:46 sfan5 I would do something once in a while if the rules wouldn't prevent me from doing so, two approvals are still required
19:46 Krock at least in terms of bugfixes
19:46 sfan5 maybe that can be relaxed to "do whatever, consult with coredevs for bigger changes"
19:46 MTDiscord <Jonathon> ^ninja'd
19:47 nrz cannot we have new maintenainers for official default game to add more features ? 馃檪
19:47 MTDiscord <luatic> make we MTG maintainer and modlib will rise
19:47 nrz i'd like to see coherent things like achievements (there is a nice mod for that) or more inside it 馃檪
19:47 MTDiscord <luatic> s/we/me
19:47 sfan5 it was decided that MTG should receive no new features
19:47 sfan5 I would also like to see it improved which is why I considered forking it but that requires time
19:48 sfan5 the current development approach and lack of direction is not sustainable in any case, which is why freezing it was a good decision (IMO)
19:48 nrz but why no new feature ? because no more coredev involved on it ?
19:48 sfan5 one point is what I just mentioned, https://github.com/minetest/minetest_game/issues/2710 has the entire discussion
19:48 nrz maybe we can discuss with community famous people to build a new team outside of coredevs with a good direction ? 馃檪
19:49 sfan5 sounds worth exploring
19:49 MTDiscord <luatic> The problem I see that MTG is pretty bland - it is supposed to be that way, kind of a modding base - and there's little interest in developing bland stuff.
19:50 MTDiscord <luatic> Mod developers are opinionated. They'll want combat, fancy mobs, and lots of other things that are out of scope for MTG.
19:51 nrz yes, mobs in mtg is always what i asked mtg devs to add
19:51 nrz but we have no real good engine for it
19:51 MTDiscord <luatic> True
19:51 sfan5 if big features had realistic chances at getting merged instead of being left lying around too long I'm sure there would be more contributions to MTG
19:51 MTDiscord <luatic> Entity support in Minetest is a mess
19:51 nrz i think rethinking the base on mtg close to MT can show the lack of core features for it
19:51 MTDiscord <luatic> Which is a shame because entities must be used for most interesting things
19:51 Krock agh. I really don't know what to say about those "Roadmap: Needs approval" PRs. they are kind-of okay I guess?
19:52 sfan5 I don't disagree but if "kind-of okay" is the standard we end up with too many open PRs again
19:53 nrz also rubenwardy idea about bow is pretty nice, but for that we need better entities, i think more specialiazed entities types i think 馃檪
19:55 MTDiscord <luatic> We probably need acceptable entity performance first of all
19:55 MTDiscord <Jonathon> my two bent pennies, but seems the realistic options are "do whatever, consult with coredevs for bigger changes" or clean through issues/pr's for 5.5, do a last release and then archive the repo
19:56 sfan5 @luatic which specific issue are you referring to?
19:56 MTDiscord <luatic> I was replying to nrz
19:56 sfan5 yes but I'm wondering which part of entities do you think performs badly
19:56 MTDiscord <luatic> get_objects_inside_radius
19:56 MTDiscord <luatic> IIRC also too many drawcalls, but don't quote me on that
19:57 nrz unfortunately, i already studies this call and we cannot do better
19:57 MTDiscord <luatic> We very much can optimize get_objects_inside_radius!
19:57 nrz i already improved it with profiler in the past, but we cannot really do it better
19:57 nrz if you have ideas, please PR then 馃槃
19:57 sfan5 those are good points, for the latter you could more specifically note the lack of occlusion
19:57 MTDiscord <luatic> Not if we continue using a linear search
19:58 MTDiscord <luatic> nrz: My C++ is too weak
19:58 nrz then how can you said we ccan do better ? :p
19:58 sfan5 a solid data structure proposal is more important than the C++ impl
19:58 MTDiscord <luatic> I was hoping libspatial could to the job for me, but can't find any proper docs
19:58 MTDiscord <luatic> do*
19:58 nrz sfan5 for mob entities you mean ?
19:58 sfan5 nrz: for storing entities on the server in a way that they can be searched faster
19:59 sfan5 @luatic been there done that https://github.com/sfan5/minetest/tree/spatialent
19:59 nrz tbh, on my mangos experience (wow server), it was just a hashmap<u64, Entity*> and it was sufficiently fast to have 1000 players and thousands of NPCs loaded in meory working
19:59 MTDiscord <luatic> sfan5: and how did it turn out?
20:00 sfan5 there's a bug somewhere because it eventually segfaults
20:00 MTDiscord <ElCeejo> fix the damn pathfinder
20:00 sfan5 I didn't do any serious enough measurements to say anything about perf
20:00 nrz the only optimization we may do is to have per mapblock search, but if we do that you will need mapblock traversal for entities
20:00 sfan5 @ElCeejo it's fixed, open a bug otherwise
20:01 nrz or we should implement like Minecraft, map sectors
20:01 nrz and entities are owned by sectors not by the whole map, but hoenstly i don't see what kind of entity search you mean
20:01 MTDiscord <luatic> I see you used an R-tree. I'm not quite sure whether that is the right tree as long as you're only concerned about points.
20:01 nrz except get_objects_in_radius
20:01 MTDiscord <ElCeejo> Oh I would open a bug about the pathfinders blatant incompetence but it would be buried beneath a pile of other bugs
20:02 MTDiscord <luatic> 3d pathfinding is HARD
20:02 sfan5 @ElCeejo if you not interested in constructive actions to improve the situation please refrain from commenting
20:02 sfan5 +are
20:02 MTDiscord <luatic> Most pathfinders do it node-based, which is actually pretty wrong.
20:02 MTDiscord <luatic> Node collisionboxes may have holes, may be larger than one node, etc
20:02 MTDiscord <luatic> Which means you can't just say "this node is penetrable" "this one's not"
20:03 sfan5 taking facedir into account would go a long way wouldn't it?
20:03 MTDiscord <luatic> And then the entity collisionbox isn't a point either. Most pathfinders assume points though.
20:03 MTDiscord <ElCeejo> 3d pathfinding is indeed difficult, but even I can make a pathfinder that's useful for any box larger than 1 node
20:03 MTDiscord <ElCeejo> but it has to be lua-side which is very sub-optimal
20:04 sfan5 maybe you could contribute your implementation then if it's better
20:04 MTDiscord <luatic> sfan5: It wouldn't, if you had a real spatial non-node based pathfinder. You'd first render the collisionboxes of all nodes (I can do that in plain Lua already using modlib). But the next step is the hard one.
20:04 MTDiscord <ElCeejo> I would love to contribute my implementation but it's in lua
20:04 MTDiscord <luatic> At least in 3D. In 2D it can be done pretty fast.
20:05 MTDiscord <luatic> Ceej: Stop whining, Lua isn't all that slow. It's a constant factor in the end. Maybe start optimizing complexity?
20:05 MTDiscord <ElCeejo> My pathfinder is by no means slow, but it's not as fast as it could be if it were done engine side
20:06 sfan5 "contribute implementation" could also mean that someone is willing to pick it up and port it C++
20:06 MTDiscord <luatic> Also sfan5, IIRC there's an R-tree which takes velocity into account, so you wouldn't have to update all moving entities every step.
20:07 MTDiscord <luatic> Yes, TPR trees. The lib implements them too.
20:08 sfan5 is it really that helpful when velocity can (and does) change every step too?
20:09 MTDiscord <luatic> No, not really. It's only really helpful if velocity remains mostly constant.
20:09 MTDiscord <luatic> Shouldn't have forgotten about gravity.
20:10 sfan5 Krock, nrz: ping for https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+label%3A%22One+approval%22
20:10 sfan5 #11592 bugfix, mergable
20:10 ShadowBot https://github.com/minetest/minetest/issues/11592 -- Fix movement in random_input mode by NeroBurner
20:10 sfan5 #11498 feature, mergable IMO, waiting on a change
20:10 ShadowBot https://github.com/minetest/minetest/issues/11498 -- Add embedded PNG texture modifier by hecktest
20:10 sfan5 #11466 waiting
20:10 ShadowBot https://github.com/minetest/minetest/issues/11466 -- Use scoped app storage on Android by rubenwardy
20:11 MTDiscord <luatic> Oh gosh can we please kill the atrocious texture modifier format?
20:11 sfan5 1) no, because backwards compatibility 2) better proposal please, there's an issue for it
20:11 sfan5 #11429, #10810, #10796 haven't looked at it, probably okay
20:11 ShadowBot https://github.com/minetest/minetest/issues/11429 -- Add no_texture.png as fallback for unspecified textures by Wuzzy2
20:11 ShadowBot https://github.com/minetest/minetest/issues/10810 -- Split liquid_viscosity to liquid_viscosity and move_resistance by Wuzzy2
20:11 ShadowBot https://github.com/minetest/minetest/issues/10796 -- Chop game background by appgurueu
20:11 sfan5 #10729 feature, mergable, missing a review
20:12 ShadowBot https://github.com/minetest/minetest/issues/10729 -- Allow Enabling The Touch UI In A Desktop Build by TheBrokenRail
20:12 sfan5 #10431 replacement merged, close this?
20:12 MTDiscord <luatic> sfan5: Yeah I made that issue.
20:12 ShadowBot https://github.com/minetest/minetest/issues/10431 -- Fix long infotext letter cutoff, add ellipsis by Wuzzy2
20:12 sfan5 oh, if discord nicks weren't so weird I would know who I'm talking to
20:13 MTDiscord <luatic> Would love it if 10796 finally got off my virtual chest. It's such a small PR, it could've been merged a while ago already.
20:13 MTDiscord <luatic> I thought the relay transmitted Discord usernames?
20:13 Krock <MTDiscord> <luatic> I thought the relay transmitted Discord usernames?
20:13 MTDiscord <luatic> Yeah it does
20:13 appguru joined #minetest-dev
20:13 MTDiscord <luatic> It's just that I prefer luatic now
20:14 sfan5 it sure does but I've never seen you with this nick
20:14 MTDiscord <luatic> But I don't really want to rename my GitHub
20:14 sfan5 #10795 looks okay, needs rebase and another approval
20:14 ShadowBot https://github.com/minetest/minetest/issues/10795 -- Fix HUD multiline text alignment by appgurueu
20:14 sfan5 (the rest I haven't mentioned) no opinion from me at this time
20:16 appguru By rebase needed you mean I have to resolve the merge conflicts?
20:19 nrz hmm it should take some time to review all things, i added my approval on #10324 at first
20:19 ShadowBot https://github.com/minetest/minetest/issues/10324 -- Split vector.new into 3 constructors by Desour
20:19 nrz for the other i already checked but it was a bit wide if i remember to gather my approval, let me recheck tomorrow
20:20 sfan5 appguru: yes
20:21 appguru Ouch android hacks
20:21 appguru we'll need android testing
20:22 sfan5 I don't know what that thing is there in the hud code, I merely simplified it
20:22 MTDiscord <luatic> Can you link the PR
20:23 sfan5 #10795 ?
20:23 ShadowBot https://github.com/minetest/minetest/issues/10795 -- Fix HUD multiline text alignment by appgurueu
20:23 MTDiscord <luatic> Did you remove the if (e->offset.X < -20) textfont = font_scaled; ?
20:23 sfan5 if it weren't for the huge previews on discord I'm sure you could still see it ;)
20:24 MTDiscord <luatic> sfan5: The PR that caused the conflicts
20:24 sfan5 oh
20:24 sfan5 #11478
20:24 ShadowBot https://github.com/minetest/minetest/issues/11478 -- Add bold, italic and monospace font styling for HUD text elements by sfan5
20:24 sfan5 I "removed" the code you quoted but only because the android hack is now applied before font selection
20:25 MTDiscord <luatic> Ah yes
20:33 rubenwardy nrz: looool, you can do better by not having a naive linear search - and using spatial partitions
20:33 sfan5 oh now I know who I forgot to ping
20:33 appguru ^ precisely
20:33 sfan5 sorry ruben
20:34 rubenwardy sorry for what?
20:35 sfan5 not pinging you on meeting-related points
20:37 appguru We need to be more consequent about our invalid input handling. Providing invalid input to load time functions - such as registry funcs - should immediately throw an error, not try to correct the values behind your back or silently catch the error and log some error messages.
20:38 appguru Because the latter two are exactly what leads to unexpected behavior.
20:38 sfan5 have we done any of the former recently?
20:39 appguru Not that I know
20:39 appguru But something like that was brought up on Wuzzy's PR
20:45 appguru Please merge the background image chopping PR BTW
20:45 appguru I have rebased the HUD text alignment fix and fixed some minor things, should be fine too
20:48 sfan5 the only "complaint" I have is that `auto wss = std::wstringstream(text);` could as well just be `std::wstringstream wss(text);`
20:48 sfan5 and I haven't tested it yet
20:57 proller joined #minetest-dev
21:01 pgimeno a love2d user sent this lib to the forum, it appears to be a pure Lua interpretation (by that I mean nothing love-specific) and maybe it can be used for get_objects_inside_radius
21:01 pgimeno https://love2d.org/forums/viewtopic.php?f=5&amp;t=91782
21:03 pgimeno I still don't have an answer to how slow it is to modify the tree, though, and for moving entities it will obviously change often
21:09 sfan5 " insertion and deletion take a lot of effort, meaning that for a dynamic set of objects this is not a convenient technique." hmm
21:09 pgimeno yeah, that's what I don't have an answer on, "how bad is it?"
21:10 tech_exorcist joined #minetest-dev
21:10 pgimeno also it's for 2D rectangles, I haven't looked into the algorithm to see how easy or hard it would be to extend it to 3D
21:15 sfan5 honestly throwing a 2D implementation at it that uses the X and Z coords would also solve most of the problems
21:16 pgimeno heh
21:23 MTDiscord <luatic> UGH
21:23 MTDiscord <luatic> That R*-tree uses table.insert / table.remove for insertion and removal
21:24 MTDiscord <luatic> Well, that's probably acceptable for a maximum of 20 children per node
21:24 MTDiscord <luatic> Still, a set would be faster
21:28 pgimeno of course that's just about the technique, the idea would be to implement it in the C++ side
21:29 MTDiscord <luatic> Why can't we take the libspatialindex implementation?
21:30 sfan5 merging game#2656 and game#2885 (only translation) in 5m
21:30 ShadowBot https://github.com/minetest/minetest_game/issues/2656 -- default: Improves reading and writing to books. by orbea
21:30 ShadowBot https://github.com/minetest/minetest_game/issues/2885 -- improve zh_CN translation by ferrumcccp
21:32 sfan5 looking at my code there's one obvious limitation: you can't fetch objects by ID from the spatialthingy, you have to do a pos lookup
21:33 sfan5 the other problem is that you can't directly put pointers into the thing, this happens to work here because it's id type is large enough to hold a pointer
21:35 sfan5 s/it's/its/
22:03 asdflkj_sh joined #minetest-dev
22:32 specing joined #minetest-dev
23:04 AliasAlreadyTake joined #minetest-dev
23:27 Taoki joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext