Minetest logo

IRC log for #minetest-dev, 2022-06-22

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

All times shown according to UTC.

Time Nick Message
01:09 Baytuch_2 joined #minetest-dev
01:44 ShadowNinja You can't delete a void* because delete doesn't know what destructor to call.  Delete is essentially a destructor call followed by a free().  (although technically new has to be paired with delete and malloc/calloc/realloc has to be paired with free since they could be completely different allocators) If whatever the void* actually points to allocates any of it's own memory then you'll still have a memory leak.
01:50 schwarzwald[m] Right, I understand the problem, but I don't know the right solution. It looks like this is managed by the emerge thread, but allocated in a different thread. Maybe I'm overcomplicating it, but it seems very nontrivial to fix. e.g. it might require architecture changes.
01:50 schwarzwald[m] * architecture changes (to do well).
04:00 MTDiscord joined #minetest-dev
04:38 loggingbot_ joined #minetest-dev
04:38 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://github.com/minetest
05:15 YuGiOhJCJ joined #minetest-dev
05:35 calcul0n joined #minetest-dev
07:17 Zughy[m] I invite core devs again to schedule #12429 for the next milestone: it can break any game genre, imho way more important than code optimisation
07:17 ShadowBot https://github.com/minetest/minetest/issues/12429 -- Seeing through blocks glitch
07:33 sfan5 schwarzwald[m]: the callback argument is managed by whoever enqueues the emerge
07:34 sfan5 IIRC it was this code https://github.com/minetest/minetest/blob/46e7b5135292ae7aa233577d1cc364d60fc932f8/src/script/lua_api/l_env.cpp#L1208
07:35 sfan5 and coverity assumes num_block to be zero, which would mean state is allocated and never has a chance to be freed
07:35 sfan5 the solution here is simply to turn the assert into an if that returns early (or throws an error)
09:04 MTDiscord <luatic> Zughy: #12429 is (1) ancient and (2) nontrivial to fix, see my comment. It definitely shouldn't be put on the milestone IMO. All that can be done about is are basically hacks, which should be left up to mods to choose & use.
09:04 ShadowBot https://github.com/minetest/minetest/issues/12429 -- Seeing through blocks glitch
09:04 MTDiscord <luatic> about it*
09:09 nore joined #minetest-dev
09:39 proller joined #minetest-dev
10:18 YuGiOhJCJ joined #minetest-dev
10:24 Taoki joined #minetest-dev
10:59 Zughy[m] I don't agree, that's a HUGE problem. It means free x-ray for everyone, how is that acceptable? I honestly don't care if it requires a lot of time to be fixed, because it's a way to break every possible game
11:02 HuguesRoss7 joined #minetest-dev
11:24 celeron55 i don't think that can be that much work, altough i'm not sure what's happening
11:24 celeron55 do you move the player outside of the blocks, but leave the camera near plane inside the blocks?
11:25 celeron55 if that's the case, then the post effect color simply has to be switched on according to the camera near plane's position, not the player's
11:25 celeron55 of course that's a plane, not a point, so it takes some extra calculating
11:26 sfan5 well do you want the entire screen to turn black when some 20% (at an angle!) is inside a node?
11:34 celeron55 probably just that part. so, even more calculating, but not impossible
11:34 celeron55 that would feel super polished
12:42 MTDiscord <Warr1024> alternatively, you could add a bunch of geometry to the scene, like adding baffles inside a node if it's close enough to the camera, to achieve the blacking-out, and let the 3d hocus pocus handle mathing it into place.
12:43 MTDiscord <Warr1024> if you could handle it as a single surface per node that could be pretty nice, but it could be a lot more complex than basically doing what we do with wieldmeshes and allowing there to be some extra "just in case" surfaces.
12:55 proller joined #minetest-dev
13:06 Fixer joined #minetest-dev
13:07 YuGiOhJCJ joined #minetest-dev
14:12 YuGiOhJCJ joined #minetest-dev
15:37 calcul0n joined #minetest-dev
17:03 schwarzwald[m] <sfan5> "the solution here is simply to..." <- Do we have a convention for how error logs should be formatted?
17:04 schwarzwald[m] * be formatted? (I don't think I saw one on the dev wiki)
17:08 schwarzwald[m] We should also change the Action field in the coverity report to "Fix submitted" at some point, so people looking at the report in the future don't think it's still an outstanding issue.
17:10 Pexin well youre not supposed to BE halfway in a node. if it's computationally cheaper to black the whole screen based on the nearplane, that's probably fine
17:14 sfan5 I think just silently returning would be more correct here, otherwise it'd be throw LuaError("Area to emerge is empty");
17:16 schwarzwald[m] Silently returning does make sense. Why is there an assert?
17:30 schwarzwald[m] Pushed, #12466 ready for review.
17:30 ShadowBot https://github.com/minetest/minetest/issues/12466 -- Fix two memleak reports from Coverity by JosiahWI
17:50 behalebabo joined #minetest-dev
18:12 celeron55 Pexin: but the nearplane isn't you, it's just a rendering necessity
18:47 appguru joined #minetest-dev
19:07 Alias joined #minetest-dev
19:15 Fixer joined #minetest-dev
19:26 Pexin celeron55: my impressio was the nearplane is closer than the player collisionmesh though?
19:27 celeron55 yes but the player's collision mesh isn't used for that either, if i'm not mistaken
19:27 celeron55 it's just the camera position that's used
19:28 Pexin but the distance from the wall "should" be farther than the nearplane?
19:28 celeron55 it's probably easy to make it better but difficult to make it perfect
19:28 celeron55 yes, that's true
19:28 MTDiscord <luatic> Pexin: It works as long as you're not colliding with blocks if that's what you're asking
19:29 celeron55 altough i don't know the exact dimensions, maybe with some FOV, screen aspect ratio or view distance it might not be so
19:29 MTDiscord <luatic> Obviously blocks you may be inside (e.g. liquids) get tricky; you can sometimes see the water plane being clipped when you slowly sink
19:29 MTDiscord <luatic> where you may be inside*
19:29 celeron55 that's not an issue though
19:29 MTDiscord <luatic> in this case it isn't
19:29 MTDiscord <luatic> the issue here is that somebody is inside a block and moves the camera slightly outside of the block
19:30 MTDiscord <luatic> which means the engine doesn't black out the screen, but it's close enough for the block face to be clipped
19:30 celeron55 or, well, i mean, it doesn't look that good either, but it's generally not game breaking
19:30 MTDiscord <luatic> celeron55: it has become a (dirty) part of PvP gameplay
19:31 celeron55 for solid nodes it's game breaking
19:31 MTDiscord <luatic> together with #8952 it basically makes hiding impossible
19:31 ShadowBot https://github.com/minetest/minetest/issues/8952 -- Entities visible in mapblocks before terrain.
19:31 MTDiscord <luatic> the problem is that unless both issues are fixed fixing one is insufficient
19:31 Pexin so can the "blackout effect" be made to swap whether it is decided by playerpos vs camerapos?
19:32 celeron55 it's certainly worth trying to make the blackout effect activate based on something more resembling the camera near plane than the current implementation
19:35 Pexin personally, my concern would be computational efficiency, and adding geometry based on proximity seems like it could be bad, but maybe I'm wrong
19:36 Pexin though I'm sure ot would visually work great
19:36 MTDiscord <luatic> mathematically it would probably correct to extrude each of the node's faces for the blackout effect; programmatically this is too much work though so you'd just extrude all boxes by the clipping distance and check whether the camera is inside that; technically this will unneedingly black out the player camera for the literal edges of the block, but that's irrelevant as the player will (1) still be very much inside the node there
19:36 MTDiscord (2) it's a very slim area (near plane is very small); note also that mods can fix this already (to some extent), as they can (1) obtain node boxes and (2) calculate camera pos - however they don't know the clients clipping plane
19:36 MTDiscord <luatic> probably be correct*
19:40 MTDiscord <luatic> it seems only GLES users can change the near clipping plane "to prevent abuse"
19:40 celeron55 of course one should ask, how is the size of the near plane chosen, and the answer is, it should be as big as possible to gain accuracy in depth comparisons
19:41 MTDiscord <luatic> celeron55: it is 0.1 in blocksize
19:41 MTDiscord <luatic> so 1cm
19:41 celeron55 could be bigger, but it seems to be large enough given there aren't obvious depth fighting problems or inaccuracy
19:43 celeron55 (basically once you get Z fighting between planes that are already intentionally using different positions to try to avoid z fighting, that's one thing you need to start looking at)
20:12 x2048 joined #minetest-dev
20:19 x2048 joined #minetest-dev
21:00 proller joined #minetest-dev
21:55 MTDiscord <luatic> sfan5, celeron55: here's my proposed fix, could you take a look? #12469
21:55 ShadowBot https://github.com/minetest/minetest/issues/12469 -- Always make everything black if camera is within node by appgurueu
22:32 panwolfram joined #minetest-dev
23:05 Alias joined #minetest-dev
23:47 kilbith a mod could do it just fine

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