Time  Nick       Message
07:54 lhofhansl  Planning to merge #11422 in the next hour.
07:54 ShadowBot  https://github.com/minetest/minetest/issues/11422 -- Distribute shadow map update over multiple frames to reduce stutter by x2048
10:23 sfan5      thats one long hour
10:24 Krock      because he left before merge
10:25 Krock      anyway. will merge #11422 and #11479 in 10 minutes
10:25 ShadowBot  https://github.com/minetest/minetest/issues/11422 -- Distribute shadow map update over multiple frames to reduce stutter by x2048
10:25 ShadowBot  https://github.com/minetest/minetest/issues/11479 -- Document glasslikeliquidlevel merge bits by random-geek
10:25 Krock      #11430 too
10:25 ShadowBot  https://github.com/minetest/minetest/issues/11430 -- Add smooth light-shadow transition at noon by x2048
10:34 Krock      merging
10:34 lhofhansl  Back now. Happy to do it. But don't mind if you do.
10:35 lhofhansl  I'll sit back :)
10:36 Krock      done
10:39 lhofhansl1 Now we can work on the remaining changes in 0xLiso's PSM branch.
10:47 Krock      btw, is x2048 == 0xLiso ?
10:49 MTDiscord  <Jonathon> No
12:45 MTDiscord  <Sublayer plank> I get random crashes now with the "delete unused features" irrlicht PR merged. the window freezes, the mouse is freed, and the windows remains frozen until it closes after a minute or so
12:58 sfan5      when did you last pull a new version of irrlicht?
13:00 MTDiscord  <Sublayer plank> right around the time the PR was merged
13:00 MTDiscord  <Sublayer plank> seems to be something to do with the smoke puff particles?
13:01 MTDiscord  <Sublayer plank> https://cdn.discordapp.com/attachments/747163566800633906/868840360951025684/unknown.png
13:01 sfan5      try pulling again then
13:08 MTDiscord  <Kimapr> +
13:08 MTDiscord  <Kimapr> oops, cat on keyboard
13:22 MTDiscord  <Sublayer plank> oh whoops, it got fixed with ae81dbd in irrlicht which I hadn't pulled :|
15:43 sfan5      ~tell v-rob since you approved the original PR you might want to review #11478
15:43 ShadowBot  sfan5: OK.
16:47 Sokomine   sadly having problems running latest git: WARNING[Main]: Irrlicht: Warning: The liary version of the Irrlicht Engine (1.9.0mt3) does not match the version the application was compiled with (1.9.0mt2). This may cause problems.
16:48 Sokomine   are any changes of compile parameters required? currently i'm using cmake . -DIRRLICHT_LIBRARY=/usr/local/lib/libIrrlichtMt.so.1.9 -DIRRLICHT_INCLUDE_DIR=/usr/local/include/irrlichtmt -DRUN_IN_PLACE=1 -DENABLE_GETTEXT=1 -DENABLE_FREETYPE=1 -DENABLE_LEVELDB=1 -DENABLE_POSTGRESQL=0
16:48 sfan5      make clean, then try building again
16:48 Sokomine   thanks
16:49 Pexin      you're using shared lib?
16:50 Sokomine   there have been some changes recently regarding irrlicht...i'm not entirely sure if i'm up to date. just tell me what's the recommended way right now, please :-)
16:51 Sokomine   first, it was a clone of irrlicht, then irrlichtmt - not sure what's current. i've been a bit busy with trying to teach npc to talk rpg-like (and players beeing able to program them - which is quite some work)
16:52 MTDiscord  <Sublayer plank> the least painful option would probably be cloning irrlichtmt into the lib/irrlichtmt directory from the root of the minetest repo and then it should automatically compile irrlichtmt along with minetest
16:53 Sokomine   oh. i currently have irrlichtmt in a folder on the same directory level as the minetest sources
16:53 MTDiscord  <Sublayer plank> yeah as of a couple of commits ago it can automatically compile irrlicht along with minetest if it's put in the lib/irrlichtmt directory
16:53 Sokomine   neat!
16:54 MTDiscord  <Sublayer plank> commit fa4dee0 to be more exact
16:54 MTDiscord  <Sublayer plank> also irrlicht/irrlichtmt is used interchangebly now, but it almost always refers to new minetest forked irrlicht version
16:54 Sokomine   but it's still https://github.com/minetest/irrlicht    ?
16:55 MTDiscord  <Sublayer plank> yeah it's a bit irregular
16:55 Sokomine   yes, i want the most current version, even though that makes no point on my hardware and i'll most likely have to disable any graphical effects made for not 8-year-old-igps
16:56 Sokomine   there's seldom a perfect way to do things. i'm glad that the development proceeds
16:57 Pexin      if things keep as they are going, i get the impression in a month irrmt will be ready to finally die completely
16:57 MTDiscord  <Sublayer plank> if you're on old hardware I think you'd be glad to hear hecks went through and removed a lot of unused stuff from irrlicht that minetest doesn't use so now it's super fast when compiling. no in-game performance difference though
16:58 Sokomine   oh? what will happen then? i did get a bit out of sync. had less time + the npc are really demanding
16:58 MTDiscord  <Sublayer plank> irrlichtmt would get absorbed into the minetest codebase
16:58 MTDiscord  <Sublayer plank> although... is irrlichtmt ever going to be absorbed into minetest? I thought that wasn't the case and it would always stay separate
16:59 sfan5      hard to say, I don't think we'll reach that point soon
17:02 Sokomine   ok. compiling now without the -DIRRLICHT_* parameters and the lib cleanly cloned into the lib/ folder
17:40 Sokomine   compiled nicely now
17:53 Sokomine   oh! the shadows look great! of course my hardware can't really handle it - even on lowest setting may be too much. but that is as expected. it is old hardware that was never really good for gaming
17:55 Sokomine   are there any reports on how more modern igps can handle the shadows? like a ryzen?
17:59 Pexin      Sokomine: from what i recall, max settings don't run very well on anything, but medium are fine on low to mid end HW. i havent tried myself
18:00 Pexin      i run with no shadows and a very large view distance
18:04 Sokomine   hm. dedicated graphic cards are usually much stronger than igps, even today (i think?) - or require tuning settings down. but to have some of these shadows in the future, on future hardware (again, without dedicated graphics card) would be something nice to look forward to :-)
19:47 hecks      sfan5 i cleaned up the encoder
19:49 sfan5      I'll test it hopefully later
19:49 hecks      it works, trust me... im a dolphin
19:51 MTDiscord  <Jonathon> nice to see #11130 getting some attention ?
19:51 ShadowBot  https://github.com/minetest/minetest/issues/11130 -- Fix rendering of allfaces nodes with transparent textures by x2048
19:55 hecks      we could use something like a todo list for things caught while reviewing a PR but deferred for later
19:56 hecks      and any other known obvious optimizations that just need someone to get around and write them
19:58 rubenwardy issues, with milestones/projects
19:58 rubenwardy milestones if you want to fix before release
19:59 hecks      we need a performance project then
19:59 hecks      to act as this to-do list, because i can think of a few things to optimize
20:00 hecks      there's the statbar thing that nobody ended up doing, there's particles, and now 11130 has an obvious optimization in the form of index reordering
20:00 hecks      which i don't want to require the author to do right now, but i'd like to note it somewhere
20:02 lhofhansl  Was there a discussion I missed re: #11470? Are we to control all visual features from  the server with no control on the client?
20:02 ShadowBot  https://github.com/minetest/minetest/issues/11470 -- Multipass shadow mapping by Andrey2470T
20:02 hecks      you missed an IRC discussion on it
20:02 hecks      which is when and how i became a coredev
20:03 hecks      i need to get around to actually PRing a change to contributing.md to codify this
20:03 lhofhansl  OK... I disagree. Things like (say) reflective water have nothing to do with gameplay. Shadow are border line, since they would destroy rain, etc.
20:04 lhofhansl  Anyway.
20:04 hecks      we basically have a gamedev lobby now in the dev team ¯\_(ツ)_/¯
20:04 hecks      reflections are a problem too
20:04 hecks      in general adding hardcoded effects like that is much inferior to working towards shader APIs
20:05 hecks      https://a.uguu.se/Bnl2EXWX7ccs_water.gif don't tell me you'd slap a reflection on this and expect it to work
20:06 hecks      as for shadows breaking particles, that's literally a bug
20:06 hecks      there should be a flag whether something should cast a shadow, because some things (like flames) should never ever do that
20:07 hecks      i'm rewriting the renderer to make changes like this less destructive, so maybe hold off on things like that
20:07 hecks      especially because implementing something like point lights right now will be 10x more code and tech debt than it will be later
20:07 hecks      this should've been done before the directional shadows, but nobody was willing to do it
20:10 hecks      and ultimately the lack of ca. 2003 quality uncanny valley lighting is not the reason we can't draw users to this thing...
20:11 hecks      on the contrary, if they try out the game only to find out it looks like shovelware and runs at 10 fps, i don't think they'll stick around for very long
20:12 hecks      at the very least we should not prevent anyone skilled from making this thing look good, and this would kind of do that
20:13 MTDiscord  <Warr1024> If I cared that much about beautiful visuals I'd be playing AAA titles instead of open-source or indie stuff.  Please, give me something that's conceptually exciting, and in exchange I'll put in the effort that it takes to overlook superficial flaws.
20:13 hecks      i'm not sure if you're agreeing or disagreeing
20:13 MTDiscord  <Warr1024> It makes sense to try to do something about our weaknesses, but only so long as we continue to play to our strengths too.
20:14 MTDiscord  <Warr1024> Mostly agreeing, I think?
20:14 hecks      i guess
20:14 hecks      basically we're fine without lathering all this shiny crap on top, we don't even need it
20:14 lhofhansl  I agree with that. I'll watch this. (And maybe it's time for me to take a hiatus - I have only been small things in the past month anyway)
20:15 MTDiscord  <Warr1024> I mostly agree that pure visual sparkly stuff is probably not what we need the most right now.  Granted, though, there's still the story of the Cool Cam to remind me that maybe it's not so bad, either.  https://thedailywtf.com/articles/The-Cool-Cam
20:15 lhofhansl  past many months that is
20:16 MTDiscord  <Warr1024> If people really want to work in sparkle and polish, I guess that's fine, so long as it doesn't interfere with the critical stuff...
20:16 lhofhansl  bye for now...
20:16 hecks      we just shouldn't be taking on tech debt for it
20:17 hecks      these implementations are usually poor quality too, and we have a big conceptual problem
20:17 MTDiscord  <Warr1024> Heh, well, on the other hand, it seems like we recently brought on this new core dev who's been providing a windfall of massive debt-cancelation payments ... :-D
20:17 hecks      where minetest already has a decent lighting system and these just clash with it
20:18 hecks      yes but my price is that nothing as stupid as liso's directional lights ever gets merged again
20:18 hecks      i'm only doing this because it's the only way to clean that up
20:18 MTDiscord  <Warr1024> Yeah, all the proposed fancy realistic light stuff conflicts with the way light levels are defined in gameplay...
20:18 hecks      i looked at the possible ways to do a quick and dirty fix to disable shadows remotely and all of them were terrible because we do not have variant switching
20:19 hecks      fast forward i'm rewriting IVideoDriver...
20:19 hecks      and catching some WTFs in the process - did you know that the selection cursor box literally remakes the box mesh every frame?
20:19 MTDiscord  <GreenXenith> Shadows honestly feels like something that shouldnt be added until implemented correctly. Sure many features should just be added and improved upon, but that really shouldnt be the case with shadows, or a lot of graphics in general
20:19 hecks      same for all the immediate drawing functions of IVideoDriver
20:20 hecks      the crosshair becomes two drawLine calls which then becomes two meshes being created and uploaded
20:20 hecks      this is why the hud is so awfully slow
20:20 hecks      shadows would look cool if our voxel GI actually worked with them, not against
20:20 hecks      but that isn't going to happen without serious restructuring
20:20 MTDiscord  <Warr1024> Shadows weren't so bad that they shouldn't have been merged at all, but we do probably need to think about at least some kind of creator configuration options much earlier in the process, instead of handing end-users a footgun and then only afterwards thinking about whether game-makers need a way to help them.
20:21 hecks      i just don't want to have to beg the user to use the right settings, that should never happen
20:21 hecks      that's a total UX failure
20:21 MTDiscord  <Warr1024> Yeah, that's really a big fundamental problem with MT right now.
20:21 MTDiscord  <Warr1024> Users should have overriding control, but creators should be able to set defaults.
20:22 hecks      we have problems with unreasonable expectations towards game developers, it's seriously hard to make something good in MT and it's becoming even harder
20:22 hecks      the other day I got yelled at for using fixed forms... when it's actually the only way I could make anything good in these
20:23 hecks      imagine just *not knowing* the rendering environment you're making something for
20:23 hecks      that's some battered wife stuff
20:23 hecks      you'll go insane trying to make some sense of it
20:23 hecks      and then imagine probing the engine to see what you're standing on, only for the rules to change the next month
20:24 MTDiscord  <Warr1024> It's a tad maddening trying to support a wide variety of users and devices, while not being able to know anything about them and their configuration and having to rely on the engine to figure it out for me, but the engine can't be arsed much of the time to actually consider more complex uses of features beyond what vanilla MTG would do.
20:24 MTDiscord  <Warr1024> Haha, oh, right, the minetest.get_node(player:get_pos()) thing ... I think I'm probably still not 100% done dealing with the fallout from that one.
20:25 hecks      at risk of sounding like a buffoon, I think I managed to wrangle the engine quite nicely and my workflow could be a litmus test for what's reasonable
20:25 MTDiscord  <Warr1024> er, I think vector.round might actually be necessary to be explicitly in there, I can't remember...
20:26 MTDiscord  <Warr1024> Granted, that was a case where there were 2 wrong answers to pick from and the engine switched from one wrong answer to another wrong answer.
20:27 MTDiscord  <Warr1024> Yeah, as I understand, you've beaten the shit out of the entity system, while I've mostly smashed my skull against nodes and node behavior.
20:30 sfan5      hecks: [IVideoDriver] are you saying drawing <10 vertices that need to be uploaded to the gpu every frame is a performance problem?
20:30 hecks      as opposed to caching them, yes
20:30 hecks      because
20:30 hecks      you literally issue more calls doing that than the amount of verts you're dealing with
20:31 hecks      and it's the GL calls and syncs that are the problem
20:31 hecks      there's literally no reason on a GLES2 feature level to not keep a VBO around for each primitive type, and just transform it with a matrix
20:32 hecks      also, vertex formats are hardcoded inline inside these functions which is disgusting
20:32 hecks      not only it strips you of the opportunity to optimize the vertex format for each of these (crucial because each attribute is an extra GL call)
20:33 hecks      but it's also what's making each IVideoDriver variant a 5000 line file (in addition to just having a ton of superfluous drawing function)
20:33 hecks      seriously, who needs draw3DTriangle...
20:33 hecks      or even drawPixel, this is stupid on an actual GPU
20:33 hecks      this renderer is designed with crap like burningsvideo in mind, and OpenGL 1.0
20:33 hecks      well, 1.1
20:34 hecks      setting the VBO state up should be the MeshBuffer's responsibility
20:34 hecks      and MeshBuffer is definitely not the place where materials should be stored...
20:35 hecks      so i'm beginning this by redoing IVideoDriver.h itself
20:35 hecks      then, COGLES2Driver will become the base driver class
20:35 hecks      OpenGLDriver will descend from it and pretty much just handle procedure pointers on the platforms that need them
20:36 hecks      WebGL1Driver already descends from it
20:36 hecks      OGLES1Driver will be gone
20:36 hecks      i'm confident that whatever CPU I save in the process here will outweigh the supposed benefits of having a GLES1 driver, I think the difference is actually that
20:36 sfan5      you mean more calls if you create a VBO for it? glDrawArrays is a single call
20:36 hecks      that GLES1 is somehow a better fit for irrlicht's retarded ways
20:36 hecks      creating the VBOs inline is the problem
20:37 hecks      when you could just cache it
20:37 hecks      it's not like the VBO for a box is ever going to change (if you use a matrix to position it)
20:37 sfan5      that makes sense
20:38 hecks      it's the attrib pointer calls
20:38 hecks      particles likewise do this and that's why they're so slow
20:39 hecks      even if they bound one quad mesh and issued a lot of drawcalls for it, it would still be better than what it's doing now
20:39 hecks      which is remaking the VBO for every particle separately... even though it's identical
20:39 hecks      our vertex formats could generally be thinner
20:39 hecks      especially for nodes, there's tons of good opportunities there
20:40 hecks      for a tiny bit of vertex shader ALU you could make block meshes half the size and that would be noticeable
20:44 sfan5      I just realized my previous question is nonsense because of course you have to explicitly do some calls to upload the buffer and set stuff
20:44 sfan5      it's not like glVertex works in ogl1
20:44 sfan5      I should read more about GL first...
20:44 hecks      look at the COGLES2Driver.cpp and weep
20:44 hecks      how it implements all these immediate drawing functions that are clearly not the GL2 way to do things
20:44 hecks      but rather something more suited for a software renderer
20:46 sfan5      https://a.uguu.se/2raaBVOnUAiJ_.png this is a lot of calls to draw a line with two points
20:46 hecks      ah i see you've embarked on the wild ride that is running minetest inside a GL debugger
20:46 hecks      this is probably why that guy was saying GLES2 is the slower path
20:46 hecks      of course it's slow if you're doing shit like this...
20:46 sfan5      I don't know the idomatic way this would be done but at least I can look at renderdoc and observe way too many calls
20:47 hecks      you can use gDEBugger for the "opengl" driver
20:47 hecks      it's a little different but every bit as atrocious
20:47 sfan5      is that one better?
20:47 sfan5      guess not
20:47 hecks      internally the GL driver will do the same thing this thing is doing, unfortunately
20:47 hecks      in the compat context
20:48 hecks      because any modern card's ISA will not have any provisions for this sort of drawing
20:48 hecks      the driver will emulate legacy GL functions using new stuff
20:48 hecks      oh and of course
20:48 hecks      drawing something with glBegin is even more calls
20:49 hecks      making a GL4 engine I've noticed that crossing over to the driver is the worst, the less and less often you do it the better
20:49 hecks      a friend making a GL2 driver confirmed this behavior
20:50 hecks      most of the calls are painful and should be kept to a minimum and dispatched in a burst if possible
20:50 sfan5      oh btw here's another thing that can be stripped out of Irrlicht: the other vertex formats
20:50 sfan5      I'm sure you're aware though
20:50 hecks      i'm guessing it has to do with how the GL specs mandates that state must be synced and consistent
20:50 hecks      sure, I mean
20:51 hecks      we can keep a vertex with tangents around but not in the way it's done now
20:51 sfan5      do we have an use for it?
20:51 hecks      I plan to just move this to the mesh buffer code, the proper way is that a mesh buffer sets its own state and binds *itself*
20:51 hecks      I don't know, do we support normal maps in any capacity?
20:51 sfan5      that support was dropped
20:51 hecks      entirely?
20:51 sfan5      (because it was broken)
20:51 sfan5      yes
20:51 hecks      then i can delete tangents for now
21:58 MTDiscord  <Jordach> isn't that required for per face CAO shading