Time  Nick       Message
13:31 jas_       if anyone is interested, it appears the behavior of sneak jumping has changed between 0.4.17 and 5.0.0-dev, such that one may now sneak jump up sheer cliffs and thin air (here is a demonstration: https://www.youtube.com/watch?v=U2fzhg8aWKY )
13:55 jas_       turns out one doesn't need to be near a node, just 'air' will do: https://www.youtube.com/watch?v=72Dryx8YeWY
14:14 Shara      Using which exact settings?
14:14 Shara      It does not seem to happen for me using new or old move
14:23 jas_       i'm not sure, i'll have to look -- thank you for testing.
14:24 jas_       it's possible that the speed of crouch or jump height is non-default
14:24 jas_       can you try https://github.com/jastevenson303/sneak_jump mod?
14:25 jas_       it doesn't happen in stable, and i test it every so often to check for changes
14:25 jas_       so it is new
14:25 jas_       (i think)
14:25 jas_       i will look and report back -- thank u again
14:27 tenplus1   hi folks, is there any reason why Minetest 0.4.17 uses 6% of my CPU just sitting on the main menu (clouds disabled) ????
15:25 rubenwardy merging web#143 in 5
15:25 ShadowBot  https://github.com/minetest/minetest.github.io/issues/143 -- Update gallery images by Treer
16:38 Krock      Android startup crash fix incoming
16:47 Krock      #7753
16:47 ShadowBot  https://github.com/minetest/minetest/issues/7753 -- Fix temporary path crash in TestAuthDatabase by SmallJoker
16:53 paramat    Krock is my hero ^_^
18:32 paramat    rubenwardy was web#143 merged?
18:32 ShadowBot  https://github.com/minetest/minetest.github.io/issues/143 -- Update gallery images by Treer
18:33 paramat    +1
20:26 paramat    #7750 +1 good PR please review
20:26 ShadowBot  https://github.com/minetest/minetest/issues/7750 -- Fix stretched stars, render stars before sun and moon by random-geek
20:39 hecks      Does minetest have some kind of minimal hardware spec for graphics PRs?
20:42 hecks      I'm in the mood to work on the renderer but I need to know what's allowed and what's not
20:47 sfan5      it shouldn't break android support (which is gles 1.0)
20:48 hecks      would it be reasonable to bump this up to 2.0 (that is, require shaders) if the benefits were very well worth it?
20:49 sfan5      shaders don't work on android yet, but there's a pr
20:49 sfan5      IMO yes
20:49 hecks      my line of thinking is, if a phone is good enough to render the amount of geometry MT pushes anyway, it probably supports shaders
20:50 hecks      the other question I've got is vram, nice things like atlasing could potentially increase the vram requirement
20:52 hecks      worst case one *could* keep the old code as fallback but that's a burden in itself
20:52 sfan5      oh no dont add texture atlases, we had those before and they were removed
20:52 sfan5      the reason why android currently uses gles 1.0 is because nobody wanted to make gles 2 work
20:52 hecks      what were the issues with atlases, then?
20:57 sfan5      http://irc.minetest.net/minetest-dev/2013-02-28#i_2902151 http://irc.minetest.net/minetest-dev/2013-04-01#i_2974754 http://irc.minetest.net/minetest-dev/2013-12-10#i_3481417
20:57 sfan5      the gist of is roughly: it broke things, didn't work correctly and hindered some new features
21:00 hecks      okay I get it
21:00 hecks      and now that I think of it, texture pack mods completely rule out atlasing
21:01 hecks      cause you can replace any one node with a 4096x4096 tile and the packer wouldn't know what to do with that
21:01 hecks      CM::updateDrawList() count in profiler is the dreaded drawcall counter here, right?
21:02 sfan5      i think so, yes
21:02 sfan5      but you should measure it yourself instead of believeing me
21:03 hecks      well I don't see anything else that looks like one
21:03 rubenwardy Texture atlases would be good
21:03 rubenwardy Our implementation was broken, a new one might actually work
21:03 hecks      okay but what about the size problem I just mentioned?
21:03 rubenwardy No idea
21:04 hecks      HD packs, while I think they're stupid, kinda wreck this idea
21:04 rubenwardy It could be disabled for thar
21:04 sfan5      not only hd packs, normal mods might use 32x mixed with 16x
21:04 sfan5      surely you can make a packer that can place varying texture sizes
21:05 hecks      rather than disabled I'd put a limit on it and provide some options
21:05 hecks      surely you can, but there's diminishing returns from making "atlases" of less than 10 textures
21:05 hecks      also atlasing the way I'm thinking would require pixel shader... hence my questions about gl earlier
21:06 hecks      in any case I don't think drawcalls (state changes) are the bottleneck here so in that case atlasing is the least concern
21:07 hecks      sure, a great implementation would cut some worlds' rendering to one dispatch, if vertex count allows... but that's overkill
21:09 hecks      the rest of the improvements I'm thinking of do not require shaders or extra memory
21:09 hecks      and that is; better meshing and mapblock LODs
21:10 hecks      LODs might require some thinking about how they're sent, though
21:21 sfan5      merging #7750 in 10 mins
21:21 ShadowBot  https://github.com/minetest/minetest/issues/7750 -- Fix stretched stars, render stars before sun and moon by random-geek
21:41 paramat    ooh LOD. have you seen the farmap PR?
21:42 paramat    #3502
21:42 ShadowBot  https://github.com/minetest/minetest/issues/3502 -- Far map and improved map transfer and rendering (WIP) by celeron55
21:43 paramat    video https://www.youtube.com/watch?v=gQ8fo5VBKEM
21:53 paramat    hecks , about requiring pixel shader, many desktop MT users turn the basic shaders (the master checkbox in settings) off because it significantly hits FPS
21:54 hecks      well it's okay
21:55 hecks      and farmap is a step in the right direction
21:56 hecks      Now consider the following: https://pastebin.com/ZAy1TKWz
21:59 sfan5      > - Let modders specify if a node is used for terrain, or if it's manmade, and if it should be a light source
21:59 sfan5      this is already a thing
21:59 hecks      sure, but specifically for LODs
22:00 hecks      read the line right under it
22:00 sfan5      > - Also let node-modifying code specify if a change is important
22:00 sfan5      but why do we need this?
22:00 hecks      to avoid unnecessary LOD updates
22:01 hecks      if I build a mesecons machine for sieving seeds and ethereal bones, which does a node dig and place every step
22:01 hecks      the LOD, seen from a kilometer, should probably ignore it
22:02 hecks      or, at least, defer the LOD update of said block until the server has absolutely bugger all to do
22:02 sfan5      sure
22:02 hecks      so what do you think of this proposal?
22:02 sfan5      that does not require modders to specify importance though, you can just do it based on distance
22:02 sfan5      sounds useful to me
22:02 paramat    this looks very interesting. the only suggestion i'm not keen on is optionally specifying if a node is for terrain or manmade or light source. however that can be guessed from 'is_ground_content' and 'light_source' nodedefs
22:03 hecks      more like optionally overriding it
22:03 hecks      case in point; my dynlight hack
22:03 hecks      that should not trigger LOD updates
22:04 paramat    and i'm not keen on treating manmade structures different from terrain and using sprites for them. there is no clear distinction anyway
22:04 hecks      at the same time, someone, ten years from now, may make themselves a huge VAO building megastructures with its lua AI
22:05 hecks      and it would be nice to specify that this *should* update LODs
22:05 hecks      as for manmade structure and deco tagging; this is for imposters
22:05 hecks      imposters would be rendered as flat quads rather than voxels, at a super, super far distance
22:06 hecks      either as mapblock-sized cross sections containing a snapshot of player buildings on them
22:06 hecks      or as individual billboards depicting decos, especially in far off "virgin" mapblocks
22:07 hecks      another reason for using imposters is that very far, low res blocks would not be able to render some features correctly, like trees
22:07 hecks      or certain player structures
22:08 Jordach    farmap is an excellent idea on paper, horrendous to maintain and use in practice
22:08 hecks      imposters would help with that
22:08 hecks      talking about c55's farmap or the proposal?
22:08 Jordach    why not both
22:08 paramat    well, for my first point i should say 'unsure about' not 'not keen on'
22:09 hecks      well I say it's a vital feature
22:09 Jordach    farmap relied on knowing the server seed
22:09 hecks      there's nothing wrong with that; but my proposal puts the burden of LODs on the server
22:10 hecks      which, as I mentioned, is about 15% extra work and no more (because math)
22:10 Jordach    then you've got the serialisation of meshes to deal with, whats the format, what's the vertice/tri colours, whats the data stored as
22:10 hecks      you do not send meshes; vertex colors are sampled client side from a palette that the server gives you
22:10 hecks      with CID as the index
22:11 Jordach    then you have to store those meshes in server memory on machines that may have as little as 1GB
22:11 paramat    yes sprites for decos seems potentially good
22:11 hecks      you don't store any meshes
22:11 hecks      you store mapblock "mipmaps", which as I've said, require only 15% extra space
22:11 hecks      just like 2D tex mipmaps will never exceed 33% of the original texture's size, it's a math rule that I forgot the name of
22:12 hecks      all of this is not trivial but also not hard
22:12 hecks      and I bet you my character model's panties that the result will be worth it
22:12 paramat    lol
22:13 Jordach    i doubt it
22:13 Jordach    LOD on the fly with 10s to 50s of clients will do all but bring the server to it's knees
22:13 hecks      one look at this picture will tell you how serious I am https://a.uguu.se/apfGJjAy78Se_pants.png
22:13 Jordach    and considering we're already dealing with almost automated *clients* wasting disk space
22:13 hecks      except most of those clients will see many of the same mapblocks
22:14 Jordach    which means you still need to store them either as local storage or in RAM
22:14 hecks      and with LODs, the "real" draw distance can be even more limited
22:14 hecks      yes, store them... 15% and no more
22:15 Jordach    15% of texture memory for clients
22:15 hecks      not texture memory
22:15 Jordach    a mega ton of vertice data
22:15 hecks      a tiny bit of texture memory for some sprites
22:15 paramat    i've always wanted LOD because i tend to write mods that create megastructures, or mapgens with huge scales
22:15 Jordach    depending on verbosity
22:15 hecks      no more vertex data than a typical 200 distance scene right now
22:15 hecks      since further mapblocks will be lower res
22:16 paramat    anyway, certainly worth chatting to celeron55 about this sometime
22:16 hecks      I would not be suggesting this if I weren't willing to do the grunt work
22:16 hecks      but with such a big feature, a pre-approval and some assistance would help
22:19 paramat    you might get c55 interested in helping out. when he gets inspired he codes like a monster
22:19 hecks      make that two monsters
22:21 hecks      but tell him to consider quickly, cause I might not have much time to do this
22:21 hecks      if I do, it'll be a marathon
22:23 paramat    i'll link him to this discussion
22:24 hecks      I'm just very, very tired of this: https://a.uguu.se/MjC4x7iZOGwh_aaaaaaaaaaa.png