| 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 |
