| Time |
Nick |
Message |
| 00:08 |
pgimeno |
um, getmetatable? |
| 00:10 |
pgimeno |
I know the caveats about getmetatable("") but I think we worked out a safe way to handle it, by protecting the string metatable |
| 00:11 |
pgimeno |
and getmetatable is often used for OOP, to find a parent class and stuff like that |
| 00:13 |
pgimeno |
I'm not sure about setfenv being safe |
| 00:14 |
pgimeno |
I don't think its use goes beyond setting up sandboxes |
| 00:16 |
pgimeno |
well maybe reading configuration files (which is a form of sandboxing) but is that even possible with CSM? |
| 00:25 |
|
GreenXenith joined #minetest-dev |
| 00:35 |
rubenwardy |
setfenv is useful for lua microcontrollers in mesecons |
| 00:36 |
rubenwardy |
perhaps running arbitrary user code from other users should be encouraged, is loadstring even available? |
| 00:36 |
rubenwardy |
*shouldn't |
| 02:52 |
|
Lone_Wolf joined #minetest-dev |
| 04:49 |
|
fluxflux joined #minetest-dev |
| 05:35 |
pgimeno |
a client-side luacontroller? |
| 06:56 |
|
calcul0n joined #minetest-dev |
| 07:20 |
|
NetherEran joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 09:49 |
|
behalebabo joined #minetest-dev |
| 10:24 |
|
lisac joined #minetest-dev |
| 12:53 |
|
NetherEran joined #minetest-dev |
| 12:54 |
|
absurb joined #minetest-dev |
| 13:14 |
|
Fixer joined #minetest-dev |
| 14:12 |
|
Lunatrius joined #minetest-dev |
| 14:26 |
|
appguru joined #minetest-dev |
| 14:26 |
|
NetherEran joined #minetest-dev |
| 15:02 |
|
hecks joined #minetest-dev |
| 16:08 |
hecks |
slowly getting there https://a.cockfile.com/rhMvbJ_far.jpg |
| 16:16 |
|
erlehmann joined #minetest-dev |
| 16:19 |
celeron55 |
how much are you running into problems with networking when working with those distances? |
| 16:19 |
|
Wuzzy joined #minetest-dev |
| 16:20 |
celeron55 |
at one point i was working on a more robust block transfer thing but didn't get to weeding out some annoying bugs |
| 16:21 |
celeron55 |
hmm, maybe robust isn't the right word |
| 16:21 |
hecks |
well this is an interesting question because |
| 16:21 |
hecks |
minetest actually has a problem with block amnesia |
| 16:21 |
hecks |
it discards a lot of the data that's received |
| 16:21 |
celeron55 |
yeah that's one of the things it fixed |
| 16:22 |
celeron55 |
now where's the branch |
| 16:22 |
hecks |
do you have that branch uploaded somewhere? |
| 16:22 |
hecks |
I could reintegrate it into this one |
| 16:22 |
hecks |
batching visually fixes block amnesia but it's still happening in the background, eating a lot of resources (because it triggers batch updates now) |
| 16:24 |
hecks |
now network transfer isn't as much of a problem as it sounds; I once played a server that gladly fed me blocks at 300+ distance |
| 16:24 |
celeron55 |
i doubt it's easily mergeable these days, but i think it's this https://github.com/celeron55/minetest/tree/block_transfer_v2 |
| 16:24 |
hecks |
and the only one having any problem with that was the client |
| 16:24 |
hecks |
it's fine, I can rewrite it |
| 16:24 |
celeron55 |
block selection happens completely differently in that |
| 16:25 |
hecks |
now would also be a good time to revisit farmap |
| 16:25 |
celeron55 |
that branch was part of the farmap work |
| 16:25 |
hecks |
since we're hitting distances where textures mip to 1x1 size |
| 16:26 |
celeron55 |
i separated it from farmap at the end |
| 16:26 |
hecks |
at this point one can render untextured vertex color blocks (which makes *everything* batchable) |
| 16:26 |
hecks |
and beyond that, point clouds |
| 16:26 |
hecks |
since irrlicht has decent support for GL_POINTS |
| 16:26 |
celeron55 |
so it will work as support for future farmap efforts |
| 16:26 |
celeron55 |
if it's taken into use |
| 16:26 |
hecks |
yeah that's kinda my roadmap for this |
| 16:27 |
hecks |
make batching, fix the block management mess, make the mesher spit out leaner geometry, and then do LODs |
| 16:28 |
celeron55 |
that's ambitious, but perfectly doable in a few weeks with enough skill |
| 16:28 |
celeron55 |
8) |
| 16:29 |
celeron55 |
https://github.com/celeron55/minetest/commit/62ab93aa321c8d6b0caffc8d886401fec5774726#diff-d6c71fb6c2c5e2ad979f39a0422f7786R905 |
| 16:29 |
celeron55 |
the core of that branch is there |
| 16:29 |
celeron55 |
the client tells the server what kind of block radius it wants the server's block sending code to maintain at the client |
| 16:30 |
celeron55 |
the protocol still contains the farmap stuff too |
| 16:32 |
hecks |
bruh, I'm skill incarnate :] https://a.cockfile.com/uEEvw0_Clipboard01.jpg |
| 16:36 |
celeron55 |
one of the reasons i had to make that was that when you want to transfer farmap stuff (basically lower resolution blocks), it competes with normal blocks and the server has to select which one is more important at each point in time |
| 16:36 |
celeron55 |
that code creates a priority queue where each type of block has a priority value |
| 16:36 |
hecks |
I think they should just be sent incrementally, with coarsest mips having the highest priority |
| 16:37 |
hecks |
before the server even gives the client a "big" block, it should have already served a kilometer of point clouds |
| 16:37 |
celeron55 |
usually a block 200 nodes away will have a lower priority than a farblock 300 nodes away, but the client can change that by varying its far_weight value in the TOSERVER_SET_WANTED_MAP_SEND_QUEUE packet |
| 16:37 |
hecks |
so that there are never any gaping holes in the map, this is a big issue currently https://a.cockfile.com/uMnVOV_52.jpg |
| 16:37 |
celeron55 |
maybe it should have more levels (i.e. point cloud in addition) |
| 16:38 |
hecks |
I was thinking of octree-like mips at first but they might not be necessary |
| 16:39 |
hecks |
because at that point you can render fat points and it'll look just as good and be even cheaper |
| 16:39 |
celeron55 |
i think it should be kept as simple as possible, it's not going to look perfect anyway and having too many levels will create more network usage and processing than it will help |
| 16:39 |
hecks |
sure, but consider the theory of mipmaps; a bitmap with mips will only be 33% bigger than the original |
| 16:40 |
hecks |
and that's without simplifying the data further, which you can do |
| 16:40 |
celeron55 |
well that's true |
| 16:40 |
celeron55 |
do anything you feel comfortable with |
| 16:40 |
hecks |
far blocks don't need param2, very far ones don't need light, in fact they can just be RGB332 8 bit color |
| 16:40 |
celeron55 |
i think that's what most would say |
| 16:40 |
hecks |
:] |
| 16:42 |
celeron55 |
one thing i noticed when doing the farmap stuff is that once you have any kind of level-of-detail optimization towards the client, the map generator's slowness becomes painfully obvious as it always has to generate at highest detail |
| 16:42 |
celeron55 |
loading from disk is mostly fast enough even if it's at way too high detail |
| 16:43 |
hecks |
the mapgen being able to sample more coarsely would be very useful |
| 16:43 |
hecks |
I mean, is there a reason why it shouldn't be? just feed it scaled noise |
| 16:43 |
celeron55 |
well the output won't be perfect but the basic noise will of course work |
| 16:44 |
hecks |
decos won't work but those can also be faked to some degree, maybe |
| 16:44 |
celeron55 |
maps consist of trees and whatnot, those are more difficult and they add a lot of color the landscape |
| 16:44 |
hecks |
also, at least for built in mapgens, the client can predict some of it |
| 16:44 |
hecks |
as long as the server tells it the mapgen id and seed |
| 16:44 |
hecks |
so virgin mapblocks need not ever be sent |
| 16:44 |
celeron55 |
that works for built-in mapgens yeah |
| 16:45 |
celeron55 |
if we ever have threaded lua mapgens in a separate lua environment, the mapgen lua code could be sent to the client for the purpose |
| 16:45 |
hecks |
yup |
| 16:45 |
hecks |
well if I was stubborn enough I could already have threaded lua mapgen, only using on_generate to blit a result |
| 16:46 |
celeron55 |
well i think it's not a priority right now |
| 16:46 |
celeron55 |
mapgens aren't MT's weak point atm |
| 16:46 |
hecks |
at least not until someone takes pity on sscsm and finishes it |
| 16:48 |
celeron55 |
we even have mapgens that look good at view ranges like 1000 or 2000 even while we actually don't have view ranges like that |
| 16:49 |
hecks |
yup, though the default params are tuned for short vision ranges |
| 16:50 |
hecks |
I'd show you how a decently sized v7 world looks like but someone broke noise sampling in 5.3 :] |
| 16:51 |
hecks |
I did a thing using dynamically sent skyboxes once, however https://a.cockfile.com/pi0eho_high.png |
| 16:52 |
hecks |
this was done by server side raymarching the noise https://a.cockfile.com/aToKdX_farmap.mp4 |
| 16:53 |
pgimeno |
ISTR someone having worked on rendering to the skybox a sort of outline of the perlin noise used for the map, so that it looked much larger |
| 16:53 |
hecks |
https://a.cockfile.com/aOwuu0_farmap3.png |
| 16:53 |
pgimeno |
is that what a farmap is? |
| 16:53 |
hecks |
farmap is what we call any sort of LOD around here |
| 16:54 |
celeron55 |
yeah i used the name for a thing and kind of stuck |
| 16:54 |
celeron55 |
well that would describe pretty much every term we use... |
| 16:55 |
hecks |
just another day in the mese mines 8) |
| 16:57 |
celeron55 |
how much server resources does server-side noise raymarching use? |
| 16:57 |
hecks |
surprisingly little because it's a 2D height only raymarch |
| 16:57 |
hecks |
and luajit is fast |
| 16:57 |
pgimeno |
hm, I think that was you hecks, now that I check the logs :) |
| 16:58 |
hecks |
the bottleneck was the client side decoding of the network message containing the huge ^[combine: texture string |
| 16:58 |
hecks |
https://a.cockfile.com/11LQCi_skybox.mp4 |
| 16:58 |
celeron55 |
oh it's even in lua, well that's ridiculous |
| 16:58 |
appguru |
MT needs a proper texture API |
| 16:58 |
hecks |
which prompted me to write a ^[raw: texture modifier that sent compressed bitmaps in the string |
| 16:58 |
celeron55 |
yeah go on, just do something, it'll be great |
| 16:58 |
hecks |
I need to revive ^[raw as a PR because it's pretty useful |
| 16:59 |
appguru |
Texture modifiers as part of identifiers are no good |
| 16:59 |
appguru |
Identifiers should be IDs or names and not instructions on how to generate the texture |
| 16:59 |
celeron55 |
yeah it's something you can make a proof of concept in but not actually use |
| 16:59 |
hecks |
for ephemeral textures like temp skyboxes or captchas, sending raw textures is very useful |
| 17:00 |
appguru |
We should have `minetest.register_texture_alias("aliasname", "texturename") |
| 17:00 |
celeron55 |
eh |
| 17:00 |
hecks |
this should probably be handled opaquely by the server to avoid resending the texstring as part of something's properties, but no more |
| 17:00 |
appguru |
precisely |
| 17:00 |
hecks |
but I like texstrings, they're a very cool system, it's almost like a little Substance |
| 17:01 |
appguru |
TBH I don't like them too much |
| 17:01 |
hecks |
then you don't have taste :^) |
| 17:01 |
appguru |
I don't want to be an OOP zealot, but a Texture class would've been the right thing here |
| 17:01 |
appguru |
(in the Lua API) |
| 17:02 |
hecks |
I mean, sure, having a texture combining graph API would probably be nicer |
| 17:02 |
hecks |
but there's nothing wrong with texstrings as a raw graph format for transfer over the network, and it's a good thing they're human readable |
| 17:02 |
hecks |
and you can always wrap them in your own API which is what I do |
| 17:02 |
appguru |
roughly: |
| 17:02 |
appguru |
Texture("media identifier" or resolution):modifier(params) |
| 17:03 |
celeron55 |
don't mix lua api into networking and certainly don't mix it into what the client does |
| 17:03 |
appguru |
The serialization should be handled by MT tho |
| 17:03 |
appguru |
Modders should be given need abstractions instead of building serialization formats by hands |
| 17:03 |
appguru |
Formspecs are another instance of this |
| 17:03 |
hecks |
formspecs already have a toolkit though, don't they? |
| 17:04 |
celeron55 |
the lua api design really doesn't have much to do even with what api the server C++ publishes to lua, it can always be wrapped |
| 17:04 |
appguru |
There are mods and engine-side attempts AFAIK |
| 17:04 |
hecks |
and you can be nice and make people a mod to build texstrings too :] |
| 17:04 |
hecks |
https://a.uguu.se/cA25s5ssCXD5_api.jpg |
| 17:04 |
hecks |
brag brag brag |
| 17:07 |
celeron55 |
i do like ^[raw, as long as the performance problems are somehow neatly solved. Maybe the server should convert it into a hash and transfer the actual data to the client through a different channel |
| 17:08 |
hecks |
the point of ^[raw is things that are not sent twice though, or to more than one client |
| 17:09 |
hecks |
how I optimized it instead was, I made it use indexed color (palettes) and zlib |
| 17:09 |
hecks |
finally crunching it into a base64 string |
| 17:09 |
hecks |
making it a pseudo-PNG |
| 17:09 |
celeron55 |
if there are no real performance issues with the intended use, then i guess who cares |
| 17:09 |
celeron55 |
i certainly won't |
| 17:10 |
celeron55 |
that's the way i code myself anyway |
| 17:10 |
hecks |
nah, the intended use is captchas and private formspec elements |
| 17:10 |
hecks |
the only problem was that MT leaks those kinds of textures |
| 17:10 |
celeron55 |
yeah the client never unloads textures |
| 17:10 |
celeron55 |
it may or may not be possible to use irrlicht's reference counting to fix that |
| 17:13 |
celeron55 |
not that it actually would become a problem with the intended use even if it never would unload them |
| 17:13 |
celeron55 |
as long as one sticks to low resolution |
| 17:19 |
hecks |
yeah you normally don't notice this, only when I tried doing the skybox thing it started to matter |
| 17:20 |
hecks |
proper use of grab and drop will solve it |
| 17:25 |
hecks |
sampling noise in lua is pretty useful https://a.cockfile.com/vUa0Ke_v7.jpg |
| 17:28 |
rubenwardy |
merging web#204 in 10 |
| 17:28 |
ShadowBot |
https://github.com/minetest/minetest.github.io/issues/204 -- Add latest version information by rubenwardy |
| 17:35 |
|
fluxflux joined #minetest-dev |
| 17:37 |
|
DI3HARD139 joined #minetest-dev |
| 17:43 |
|
NetherEran joined #minetest-dev |
| 17:44 |
rubenwardy |
#10109 needs a solution |
| 17:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/10109 -- Android water rendering issue |
| 17:52 |
rubenwardy |
I'm looking into it now, I suspect it's similar to other issues I've had with rendertexture on Android |
| 17:52 |
rubenwardy |
which I also didn't manage to fix |
| 18:11 |
rubenwardy |
ok, I can't reproduce the bug actually |
| 18:11 |
rubenwardy |
I was confused by the default hotbar_selected image |
| 18:28 |
sfan5 |
huh? |
| 18:30 |
rubenwardy |
So, #10109 is caused by a bug fix to fix black backgrounds on inventory images |
| 18:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/10109 -- Android water rendering issue |
| 18:30 |
rubenwardy |
I can't reproduce the black backgrounds on inventory images afterall |
| 18:31 |
pgimeno |
in GLES2? |
| 18:31 |
rubenwardy |
yes |
| 18:31 |
rubenwardy |
err |
| 18:31 |
Krock |
I observed black backgrounds in the wield item when the shaders were not up to date |
| 18:31 |
rubenwardy |
or ES 1 |
| 18:32 |
rubenwardy |
Android doesn't have shaders |
| 18:32 |
sfan5 |
gles2 always uses shaders, but not ours |
| 18:32 |
rubenwardy |
yeah, fixed shaderd |
| 18:32 |
sfan5 |
are you testing with the SMaterial 0.5f commit reverted? |
| 18:34 |
rubenwardy |
yes |
| 18:34 |
rubenwardy |
I also reverted it on the repo |
| 18:34 |
appguru |
Couldn't we do this using an IFDEF in the shaders? |
| 19:06 |
rubenwardy |
celeron55: what was your vision for the default game in Minetest? |
| 19:28 |
hecks |
does anyone know if time of day sunlight updates trigger remeshes? |
| 19:37 |
hecks |
https://a.cockfile.com/Yjeflm_faaaar.jpg gonna have to start thinking about extending the map size too at this rate |
| 19:38 |
rubenwardy |
nice, is that a natural view distance? |
| 19:38 |
hecks |
depends on what do you mean by natural |
| 19:38 |
rubenwardy |
good FPS, experienced during runtime without lots of flying around |
| 19:39 |
hecks |
no this still chugs, but at least it's viewable now |
| 19:39 |
hecks |
problem is that normally minetest doesn't even let you load this much without punching holes in it and forgetting blocks |
| 19:39 |
hecks |
and also it would die trying to render this |
| 19:40 |
rubenwardy |
a higher view range is my number 1 wish for graphics, before anything fancy |
| 19:40 |
rubenwardy |
well, also z-ordering |
| 19:40 |
rubenwardy |
for alpha |
| 19:40 |
hecks |
I'll do distance sorting as a part of this |
| 19:40 |
hecks |
this might become one mutha' big PR but it has to, because of how it's all connected |
| 19:41 |
rubenwardy |
uh oh |
| 19:41 |
hecks |
the "natural" view distance as you call it is roughly doubled at the moment |
| 19:41 |
hecks |
but I yet to have start doing basic things like frustum culling |
| 19:41 |
rubenwardy |
PR title: Bug fixes and performance improvements |
| 19:42 |
hecks |
pretty much |
| 19:42 |
hecks |
sure caught some bugs along the way |
| 19:42 |
hecks |
there's also structural changes like how camera_offset is handled |
| 19:42 |
hecks |
in fact it's been deleted from a lot of places since it's no longer needed |
| 19:43 |
hecks |
the blocks are being rendered using plain transform matrices now, it works very well at the map's edge after some adjustment |
| 19:43 |
hecks |
no more statically shifting block geometry around |
| 19:43 |
hecks |
the same thing should be done for entities eventually |
| 19:45 |
hecks |
this is a "natural" view distance, officially 350 but by necessity it's padded to more https://a.cockfile.com/aFJwAP_natural.jpg |
| 19:45 |
hecks |
so about half of the previous image |
| 19:46 |
hecks |
also my PC is getting old and you could surely pull off more on something more recent |
| 19:56 |
rubenwardy |
that's nice |
| 20:04 |
pgimeno |
hecks: I'm right now working on frustum culling for OpenMiner and I'm interested in the algos for that, mind if I PM you? |
| 20:04 |
hecks |
go ahead |
| 20:05 |
rubenwardy |
All 5.3.0 blockers have been cleared |
| 20:17 |
sfan5 |
then, can we release now? |
| 20:22 |
|
oil_boi joined #minetest-dev |
| 20:29 |
sfan5 |
I guess I now is the time to import translation stuff again |
| 20:32 |
sfan5 |
Wuzzy: instead of changing broken "needs_fallback_font" translations on weblate to be empty you could just have fixed them |
| 20:33 |
sfan5 |
but doesn't really matter |
| 20:33 |
Wuzzy |
as i dont speak the language, i do not make decisions about the "correct" value. others must decide |
| 20:33 |
Wuzzy |
so the only "safe" thing i can do is delete the value |
| 20:34 |
Wuzzy |
as far i remember, an empty value equals "no" |
| 20:34 |
sfan5 |
then you could also have left the broken value |
| 20:34 |
Wuzzy |
noooooo |
| 20:34 |
sfan5 |
it's also equivalent to no |
| 20:35 |
Wuzzy |
ugh |
| 20:35 |
Wuzzy |
we just have to wait for translators to insert the correct value |
| 20:35 |
Wuzzy |
but if we keep the broken one it wont get fixed |
| 20:35 |
Wuzzy |
unless you speak the language in question, empty is better than broken |
| 20:40 |
rubenwardy |
I agree with empty > broken |
| 20:41 |
sfan5 |
whether it's empty or gibberish doesn't change anything about the end result |
| 20:41 |
sfan5 |
anyway I am fixing the values in cases where I can determine how it's supposed to look |
| 20:43 |
rubenwardy |
sure |
| 20:45 |
rubenwardy |
it would be useful to have a tool to verify that translations aren't malicious |
| 20:45 |
rubenwardy |
like, show translations that don't look quite right against google translate |
| 20:46 |
rubenwardy |
although, carefully crafted sentences may look ok in google translate but be foul to a native reader |
| 21:00 |
sfan5 |
ok translations pushed |
| 21:05 |
sfan5 |
util/bump_version.sh is refusing to work, how nice |
| 21:08 |
rubenwardy |
could be my android change |
| 21:19 |
sfan5 |
Could not open file of texture: Z:tmpxminetest-5.3.0-win32texturesbasepacknext_icon.png |
| 21:19 |
sfan5 |
uh |
| 21:20 |
sfan5 |
the icons are invisble but not sure if this is wine's fault |
| 21:23 |
rubenwardy |
what |
| 21:23 |
rubenwardy |
yay windows |
| 21:30 |
sfan5 |
yep same issue on real windows |
| 21:32 |
rubenwardy |
maybe the texture isn't escaped in formspecs? |
| 21:34 |
sfan5 |
yeah that fixes it |
| 21:35 |
sfan5 |
rubenwardy: http://sprunge.us/gbSk21?diff |
| 21:35 |
rubenwardy |
lgtm |
| 21:35 |
* rubenwardy |
slaps himself |
| 21:35 |
sfan5 |
if that looks okay i'll include that commit before tag.. alright |
| 21:35 |
rubenwardy |
my bad |
| 21:40 |
sfan5 |
the 32-bit build crashes reliably when existing a world |
| 21:40 |
sfan5 |
that must mean nobody actually uses it |
| 21:41 |
rubenwardy |
there may be an issue for that |
| 21:41 |
sfan5 |
really? |
| 21:41 |
rubenwardy |
#10137 |
| 21:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/10137 -- "Exit to menu" button causes Minetest to close/crash |
| 21:41 |
rubenwardy |
I'd forgotten |
| 21:42 |
sfan5 |
you accidentally linked the 32-bit twice in the rc2 topic |
| 21:42 |
sfan5 |
+build |
| 21:42 |
rubenwardy |
doh |
| 21:48 |
sfan5 |
229Mminetest.exe |
| 21:48 |
sfan5 |
debugging symbols ✔ |
| 22:11 |
sfan5 |
after messing around with both winedbg and gdb+wine and finally just installing gdb on windows I get a partial backtrace that points to a std::set<unsigned long long> destructor with this being NULL |
| 22:14 |
sfan5 |
./src/script/common/c_converter.cpp:static thread_local std::set<u64> warned_msgs; |
| 22:14 |
sfan5 |
only u64 set we have |
| 22:29 |
sfan5 |
rubenwardy: thoughts on this workaround http://sprunge.us/2rYb9s?diff |
| 22:30 |
sfan5 |
turning it into an std::vector<u64> like l_deprecated_function uses (also thread-local) didn't fix it though I didn't verify the backtrace |
| 22:32 |
pgimeno |
is it OK in linux 32 bit? |
| 22:40 |
sfan5 |
works here |
| 22:42 |
pgimeno |
so it looks like a a mingw32-specific bug |
| 22:44 |
hecks |
compiling minetest with symbols, yum |
| 22:44 |
hecks |
linking the damn thing is so slow I just revert to shotgun debugging because it's literally faster |
| 23:22 |
sfan5 |
release happens tomorrow then, I guess |
| 23:38 |
appguru |
yay |
| 23:38 |
appguru |
finally |
