Time  Nick         Message
00:50 Fleckenstein https://lizzy.rs/stencil_shadows.mp4
00:50 Guest54      ♥
00:50 Fleckenstein finally
00:58 Guest54      FYI: these are the mystical irrlicht shadows that you can add with addShadowVolumeSceneNode() – lizzy figured out how to do them
08:49 Guest54      so here are some things dearest lizzy and me learned last night about stencil shadows:
08:49 Guest54      1. to get them to work, you have to initialize the device correctly, i.e. the 'shadows' flag in createDevice() must be set to true
08:53 Fleckenstein Guest54: I think the number of light sources is very limited
08:53 Fleckenstein OpenGL MaxLights
08:54 Fleckenstein > MaxLights (int) Number of hardware lights supported in the fixed function pipeline of the driver, typically 6-8. Use light manager or deferred shading for more.
08:54 Fleckenstein so maybe we'll have to figure out light manager
08:55 Guest54      am i correct in that this means you can't have more than 8 shadows at the same time without shaders?
08:55 Fleckenstein more than 8 light sources
08:55 Fleckenstein = more than 8 shadows from a single object
08:56 Fleckenstein the light system removal from irrlichtmt is genuinely annoying
08:56 Guest54      well given we currently have 0 shadows from a single object in that case, i think it's still a win
08:56 Fleckenstein ofc
08:56 Fleckenstein and light manager might be worth looking at it idk
08:57 Fleckenstein we might end up having to make our own light manager that smartly selects the nearby light sources to use :D
08:57 Guest54      this one? https://irrlicht.sourceforge.io/docu/example020.html
08:57 Fleckenstein seems like it, I really haven't dug into it
08:57 Guest54      yeah i think if you are in a cave full of torches you *might* want to be a bit smart with clustering or so about which ones contribute to your shadow
08:57 Fleckenstein right now my irrlichtmt compiles but the terrain is all black
08:58 Fleckenstein prolly just some stuff i didn't re-add properly, digging through the diffs
08:58 Guest54      > This is completely optional: if you do not register a light manager, then a default distance-based scheme will be used to prioritise hardware lights based on their distance from the active camera.
08:58 Fleckenstein ahh
08:58 Fleckenstein nice
08:58 Guest54      try the demo out i say
08:59 Fleckenstein well we'll figure that out once sunlight works properly
08:59 Fleckenstein i mean you can have a look at it rn but im busy with getting stuff to work with modern minetest
08:59 Guest54      i already looked at it yesterday
09:00 Fleckenstein oh what did you find
09:00 Fleckenstein what does it do better
09:01 Guest54      well, you probably want to prioritize lights based on the distance to the rendered thing, so you can get local lighting
09:01 Guest54      the distance to the camera is way less important for this
09:02 Guest54      but even then, there is an optimization apparently, you can just read the linked page you'll be as knowledgeful as i am
09:02 Guest54      > LIGHTS_IN_ZONE shows a technique for turning on lights based on a 'zone'. Each empty scene node is considered to be the parent of a zone. When nodes are rendered, they turn off all lights, then find their parent 'zone' and turn on all lights that are inside that zone, i.e. are descendents of it in the scene graph. This produces true 'local'
09:02 Guest54      lighting for each cube in this example. You could use a similar technique to locally light all meshes in (e.g.) a room, without the lights spilling out to other rooms.
09:03 Fleckenstein ohh
09:03 Guest54      anyways, basically you can only have 8 lights max at the same time, but you can turn them on and off during rendering, so … you can just be smart about it
09:03 Fleckenstein yep
09:03 Fleckenstein the zoning sounds good
09:03 Fleckenstein tho difficult
09:03 sfan5        <Fleckenstein> the light system removal from irrlichtmt is genuinely annoying
09:04 sfan5        afair stencil shadows were thrown out as an idea long time ago
09:04 Guest54      sfan5 i remember *you* insisted they were not to be done when i proposed it, have any arguments against them?
09:04 Guest54      they are crisp, but single color
09:04 Fleckenstein and you can use the without shaders
09:05 Guest54      on a potato
09:05 Fleckenstein the code for stencil shadows is minimal
09:05 Fleckenstein you just need to keep the lighting system around
09:05 Guest54      and they are never going to be as blurry as shadow maps, since they are based on an extrusion of the mesh
09:05 Guest54      that also means it will not handle transparent textures in meshes, but that's a limitation of the technique
09:06 Guest54      you'll get a shadow of the outline of the mesh based on an extruded volume and that's it
09:06 Fleckenstein mfw justifying a misdecision with another misdecision
09:07 Guest54      also stencil shadows had people way back (before 2010 or so) say “oh, my graphics card actually supports this” in the irrlicht forums, so they are *really* well supported
09:08 Guest54      i suspect any 15 year old integrated GPU that chokes on the shadow maps will probably be able to do these crisp shadows, if it can run minetest at all
09:09 Guest54      oh also there was the gouraud shading for the landscape lizzy
09:09 Guest54      that looked fabulous
09:09 Guest54      once it worked
09:09 Guest54      wait was that phong shading after all in the end?
09:09 Guest54      i forgot
09:09 Fleckenstein no
09:09 Fleckenstein irrlicht doesn't support that without shaders
09:10 Fleckenstein gouraud shading only works well without fast faces
09:10 Fleckenstein so it's a trade off
09:10 Guest54      yeah but i think the order of the triangles is worth to be looking into
09:10 Fleckenstein but it seems like fast faces were nuked anyway?
09:10 Fleckenstein why?
09:10 Fleckenstein the results we got were expected
09:11 Fleckenstein it does the lighting for each vertex and interpolates between
09:12 sfan5        I am not a graphics expert so take this with a grain of salt but: stencil shadows depend on some legacy OpenGL stuff, "they work without shaders" is moot as we will be going shader-only anyway
09:12 Guest54      yeah, but consider the following, if you had cut the triangles differently for every weird triangle that we saw that was lighted incorrectly, maybe that would have worked
09:12 Guest54      lol
09:12 Fleckenstein > we will be going shader-only anyway
09:12 Fleckenstein skill issue
09:12 Guest54      as if you can not use the stencil buffer with shaders lol
09:12 Fleckenstein this is pretty much against the original goal of the minetest project even
09:13 Guest54      i think in fact, 8 lights is a limitation of the *fixed function* pipeline
09:13 sfan5        we don't even have roadmap so where is this mythical original goal?
09:13 sfan5        "you just need to keep the lighting system around" is missing the whole point too, code in irrlicht counts too and we actively need to support/maintain it
09:14 Guest54      sfan5 stencil shadows are not “legacy”, they are a different way to draw shadows with different tradeoffs and they are not going away on modern hardware. and use of the stencil buffer is not a thing limited to opengl 1.x
09:14 sfan5        anyway @numzero or @x2048 will be able to give you more insight why stencil shadows are out of question in 2023
09:15 Guest54      the tradeoff is basically: single colored but crisp shadows at the expense of more geometry (shadow volumes) or multicolored smooth/blocky shadows (depending on your texture memory) at the expense of more textures (shadow maps)
09:16 Fleckenstein > stencil shadows are out of question in 2023
09:16 Guest54      there are a few other things, e.g. with shadow maps i think you need to recalculate all lighting when a single light changes whereas with shadow volumes you only need to recalculate the affected volume, but i am not an expert on the topic, i only spent 9+ hours yesterday in a call with lizzy on it
09:16 Fleckenstein i give zero fucks about what year it is
09:16 Fleckenstein stencil shadows work better and more performantly
09:16 Guest54      also both techniques are beyond ancient in computer science terms – shadow maps are from 1978 and shadow volumes are from 1977
09:17 Fleckenstein rejecting a technique because it's old is esotheric BS
09:18 Fleckenstein it's not like we want to force users to use it, we just want to offer the option to do it
09:19 sfan5        maybe I misunderstood something in that context, but I'm very sure there were reasons why Irrlicht's stencil shadow support was not an option
09:21 Guest54      i presume this to be either the “shadows have a single color” thing or the rendering bugs that we figured out to avoid yesterday (by using new enough irrlicht in the end)
09:21 Fleckenstein it very obviously is an option
09:21 Fleckenstein it works
09:21 Fleckenstein and its good
09:21 Guest54      oh it also handles stuff like self-shadowing out of the box if i am not mistaken
09:22 Fleckenstein if it's able to deliver a decent experience to a wide variety of users, there is not reason to not at least ship it as an option
09:22 Fleckenstein anything beyond that is either esotheric or a skill issue
09:22 Guest54      also given the absolutely absurdly high hardware requirements for shadow maps i think multiple dynamic lights with shadow maps are out of the question until someone buys every minetest user a supercomputer
09:23 Fleckenstein and yea, minetest was specifically created to support low end hardware
09:23 Fleckenstein http://wiki.minetest.com/wiki/History_of_Minetest
09:23 Guest54      i am thinking of the “you are in a cave and have torches and want atmosphere” thing
09:23 sfan5        Fleckenstein: like I said ask @x2048 or @numzero for their opinion on this
09:24 Guest54      this feels like the TGA thing again, people passing judgement without looking into the particular tradeoffs of different approaches :(
09:24 Guest54      well let's ask the shadowmap experts then
09:25 Fleckenstein tho I don't really understand why we would need to ask "experts" whether it works when we can pretty easily verify with our own eyes that it works
09:26 Guest54      it's a buerocratic process called gatekeeping :P
09:27 rubenwardy   It's over ten years since Minetest was created, even low end hardware has shader support now
09:27 sfan5        erle loves to negatively frame things without fully understanding them himself
09:27 sfan5        this makes me remember why I do not like interacting with him
09:27 Guest54      lizzy also you can view it a different way: if you ask “why didn't you do this?” you may find that the issues you fixed yesterday were insurmountable obstacles to them, maybe.
09:27 sfan5        Fleckenstein: because there may be larger implications regarding the planned renderer/driver rewrite and how things are going to work in the future
09:28 sfan5        if we merge something that is somehow bound to legacy OpenGL (I don't know whether this is true or not) we will have to remove it again within 3 months
09:28 sfan5        that would be clearly wasted work
09:29 Fleckenstein > erle loves to negatively frame things without fully understanding them himself
09:29 Guest54      rubenwardy yeah and just having shader support doesn't get you nice-looking shadows. you need a really good graphics card. try minetest on an old thinkpad and you will find that even if it claims to support OGLES 2, but minetest for some reason will have multiple rendering issues. try minetest on a reform 2 (a relatively new, but arm-based
09:29 Guest54      computer) and you will find that you'll never get crisp shadows.
09:29 Fleckenstein the joke writes itself
09:30 Fleckenstein we're like "look we have shadows that work faster and also look cool"
09:30 Fleckenstein you're like "nah i dont understand it but it's bad"
09:30 Guest54      i have spent many hours to not understand the particular tradeoffs between shadow maps and shadow volumes just so i could be a negative influence in this chat – finally someone recognizes me for my achievements!
09:31 Fleckenstein > even low end hardware has shader support now
09:31 Fleckenstein ok but
09:31 Guest54      anyways, i remember celeron55_ writing in the chat that stencil shadows were not done because *no one figured them out*
09:31 Fleckenstein stencil shadows are still faster
09:31 Fleckenstein > we will have to remove it again within 3 months
09:31 Guest54      and to be fair, i asked Fleckenstein because i was not able to figure it out
09:31 Guest54      the elusive rendering rewrite, always 3 to 6 months out
09:32 Fleckenstein the issue here is removing things that are still actively used by a large variety of users
09:32 Guest54      i stopped being scared by the threats of minetest not running with acceptable fps on my hardware a year ago or so
09:32 sfan5        Guest54: stop talking out of your ass
09:32 sfan5        if you watched the irrlichtmt development you would know that the base OpenGL3 is literally merged
09:33 sfan5        of course you did not and yet you pretend to know better
09:34 sfan5        not sure what "still actively used by a large variety of users" is referring to
09:34 sfan5        hardware support?
09:34 Guest54      i am not watching irrlichtmt development closely, yes
09:34 Fleckenstein well i have a medium-spec to low-spec laptop
09:34 Fleckenstein and i know many people who play minetest on such machines
09:34 Guest54      sfan5  currently the baseline for minetest running is “probably every machine that can do wayland and some that even can not do that”
09:35 sfan5        we have discussed that multiple times and at length in the devteam and shader-less opengl is definitely going away for modernization reasons
09:35 Fleckenstein > modernization reasons
09:35 sfan5        because it - like other things - requires active maintenance and support while potentially blocking performance improvements
09:35 Fleckenstein this is literally a performance improvement
09:36 Guest54      yeah lol
09:36 Guest54      even on newer hardware
09:36 Fleckenstein "modernization" is BS
09:36 Fleckenstein it's a skill issue to not support both
09:36 Guest54      my best knowledge for what machine can do, e.g. mineclone2 at acceptable performance is “currently everything works on an old thinkpad from around 2006”
09:36 Fleckenstein so many engines can easily do it
09:36 sfan5        is "skill issue" some discord buzzword?
09:36 Fleckenstein what does it have to do with the argument?
09:37 sfan5        I don't know what it's supposed to mean when you just throw around "skill issue"
09:37 Guest54      these old machines often can do shaders btw, but a) minetest shaders are too big for older machines, even many with OGLES 2 support b) the shadow mapping implementation does not produce nice shadows with crisp edges on modern machines anyway and is a performance hog in any case
09:37 Fleckenstein incompetence
09:38 sfan5        anyway, you are mixing up topics in a way that doesn't make sense
09:38 Fleckenstein it's easily possible to offer a good experience to users on both high end and low end machines
09:38 sfan5        I am talking about hardware support
09:38 sfan5        by your words, stencil shadows work with shaders, so what does that have to do it?
09:38 Fleckenstein whar
09:39 Fleckenstein if i said that, it was a mistake
09:39 Fleckenstein stencil shadows work without shaders
09:39 sfan5        so they don't work with shaders?
09:39 Fleckenstein yes, and?
09:39 Guest54      well, i claimed that you could access the stencil buffer from shaders, which is true
09:39 Fleckenstein i'm not suggesting to *replace* shadow mapping
09:39 Guest54      as far as i know lol
09:39 Guest54      me neither
09:40 Fleckenstein well yea one could probably make stencil shadows with shaders as well, maybe I should look into that
09:40 sfan5        ok let's start from the beginning
09:41 sfan5        I said "we might drop shader-less support in the future for modernization", you said "but stencial shadows literally improve performance"
09:41 sfan5        where is the relation between the two?
09:42 Guest54      well, if you look into how it's imlemented, stencil shadows are so simple in performance terms that you don't need a shader even
09:42 Guest54      unless you want more than 8 lights without a light manager (which selectively turns them on and off) probably
09:43 sfan5        that does not make the topics related
09:43 Fleckenstein sfan5 you used possibly dropping shader-less support in the future as an argument against the irrlicht lighting system and subsequently stencil shadows
09:43 Fleckenstein you brought up the connection
09:43 sfan5        no?
09:44 Guest54      you did write something about it being ”legacy opengl”, despite being stencil shadows one of the major techniques to make shadows on modern opengl hardware (the other is shadow maps obv, different tradeoffs)
09:45 Guest54      https://irc.minetest.net/minetest-dev/2023-04-13#i_6075755
09:45 sfan5        at some point someone brought up the topic of how Minetest is supposed to support low end hardware
09:45 sfan5        which then turned into a mess
09:45 Guest54      > I am not a graphics expert so take this with a grain of salt but: stencil shadows depend on some legacy OpenGL stuff, "they work without shaders" is moot as we will be going shader-only anyway
09:45 Fleckenstein whatever i think we might have misunderstood
09:46 Fleckenstein i don't know whether there is a point in arguing about shaderless support
09:46 Fleckenstein erleh might have more info about that
09:46 sfan5        for the stencil shadows ask our resident graphics experts about the implications
09:46 Guest54      regarding dropping support for the hardware, you are probably underestimating the amount of people playing minetest on a potato
09:47 Guest54      all these people could have stencil shadows right now
09:47 MTDiscord    <Fleckenstein> quoting the minetest wiki
09:47 Guest54      in fact, they could have had them for 10+ years or so, if anyone had turned them on
09:47 MTDiscord    <Fleckenstein> "At first celeron55 had nothing. Just a knowledge of game design and a dream. He watched Minecraft take form. But there was something that wasn't right.  In all of Minecraft's glory, it had left someone out. The little guy. People with less powerful PCs that could only stare and watch Minecraft slowly melt their PCs. This angered celeron, so much to the point where one day he sat at his computer, watched Minecraft majestically fry
09:47 MTDiscord    his PC, and thought "I could do better." So he did."
09:47 MTDiscord    <Fleckenstein> watched Minecraft majestically fry his PC, and thought "I could do better." So he did."
09:47 sfan5        hardware support has been discussed in the team multiple times at length and it is almost guaranteed that we will be dropping shader-less support and perhaps OpenGL <3 too
09:47 rubenwardy   10 year old hardware in 2010 was 2000. Now, it's 2010
09:47 sfan5        (and yes, c55 agrees too)
09:48 rubenwardy   +3
09:48 Guest54      look, if “the oldest hardware i have that can do stencil shadows” is not a performance argument, i don't know
09:48 sfan5        discussing this any more is a waste of time and if erle would like MT to work on his 2008 thinkpad he can fork MT and maintain the old code himself
09:48 Guest54      the method is just simpler (and less capable, before someone brings up shadows of colored glass, nope)
09:48 sfan5        but it still has nothing to do with stencil shadows (if as you say it is not some legacy opengl thing)
09:48 Fleckenstein the year doesn't really matter, if there are enough people who use minetest on low-end / old hardware
09:49 Guest54      i don't know what the “legacy opengl” thing means. like did hardware stop having stencil buffers at some point or what do you think?
09:50 sfan5        dunno, like I said take this with a grain of salt
09:51 sfan5        and like I also said maybe I misunderstood
09:51 rubenwardy   I believe legacy opengl is OpenGL before 3.0
09:51 rubenwardy   https://www.khronos.org/opengl/wiki/Legacy_OpenGL
09:52 Fleckenstein > hardware support has been discussed in the team multiple times at length and it is almost guaranteed that we will be dropping shader-less support and perhaps OpenGL <3 too
09:52 Fleckenstein understood, minetest developers value their personal comfort ("modernization" "maintainability") higher than providing a good experience to more users
09:52 Fleckenstein i don't think it makes sense to argue any further if our values differ
09:53 sfan5        I know you wrote this as some sort of gotcha but yes what if that is the case?
09:53 sfan5        people work on MT for fun in their free time, do you think it is fun for a seasoned graphics programmer to maintain some OpenGL 1.x code? I don't think so
09:53 rubenwardy   modernising the pipeline will provide a better experience to more users as it allows better use of hardware. Most users are using hardware newer than 2009
09:54 Guest54      rubenwardy the problem is, again, just because hardware claims to support something it a) does not mean it works well and b) minetest does not necessarily use it well
09:55 Guest54      e.g. the shaders on the mali 400 GPU don't work with OGLES 2 because some shader exceeds the minimum shader size guaranteed by the spec, it will be the same with ogl3
09:55 Guest54      it will not be “all ogl3 machines can do this”, it will be “machines close to what the devs have will work”
09:56 Guest54      anyways, i am not sure if i own have a computer that will run minetest well in that case, maybe reform 2
09:56 sfan5        do not extrapolate edge cases to the general case
09:56 Fleckenstein 1. it wasn't necessarily a gotcha, I genuinely think that I we can't work together if user experience is such a low priority 2. fun is subjective, I personally enjoy playing around with old things, especially if there is a practical benefit to it 3. rubenwardy, there is no reason to not support both legay and modern hardware, many engines do this
09:56 Guest54      openRA did this too btw, modernize the rendering. i think it basically means that new versions of openRA do not run on computers that are less than 5 years old … too old.
09:57 Guest54      on *some* computers, as in “i own one that is new enough, but can't do it”
09:57 Fleckenstein old hardware is not an edge case, you're just a snob
09:58 sfan5        try jumping to conclusions less, too
09:58 Guest54      sfan5 IMO it is always the case that if you do not develop on low-spec machines then your software will suck on them. i wrote some synthesizer software on the oldest machine i could get my hands on so it would not crap out on newer ones.
09:58 Fleckenstein "we can't do this because it's not modern" ok but I have a laptop from 2016 and it improves my user experience
09:58 Guest54      you need test cases to prevent the scenario and minetest simply does not have or want them
09:58 rubenwardy   2016 would be within the support range
09:59 Guest54      what is this mystical “support range” and when do my thinkpads fall out of it?
09:59 Guest54      (just asking so i can choose which version to maintain until i get bored)
10:00 sfan5        Fleckenstein: by the way is that meant to be an insult?
10:01 Fleckenstein no, I just have bad temper
10:01 sfan5        do not take this personally but the way you respond is at times aggravating
10:01 Guest54      i am sure some people could say the same thing to you (or me, for that matter)
10:02 sfan5        in any case "old hardware is an edge case" is not what I said
10:02 Guest54      let's not become carbon copies of kilbith everyone
10:02 Fleckenstein the criticism is valid
10:02 celeron55_   it's about time for the old hardware users to learn graphics and start maintaining the legacy support
10:02 Guest54      personal attacks, however justified, are just distracting from the issue at hand
10:02 Fleckenstein > it's about time for the old hardware users to learn graphics and start maintaining the legacy support
10:02 Fleckenstein this is literally what we are doing
10:02 celeron55_   if not, then it will go, because it's not fun to maintain for those who don't use legacy hardware
10:02 celeron55_   it's that simple
10:02 celeron55_   do you understand?
10:02 Fleckenstein of course
10:02 Fleckenstein its what we are trying to do
10:02 Guest54      celeron55_ hi i am an old hardware user and i know a bit about stencil shadows lol
10:03 Guest54      yeah
10:03 celeron55_   OpenRA's 5 years, that you quoted, is pretty far from what MT will end up with, though
10:03 rubenwardy   I believe we were talking about 10-13 years
10:03 sfan5        reminder that stencil shadows still have nothing to do with the planned dropping of old hardware support
10:03 celeron55_   maintaining != complaining on IRC
10:03 Guest54      well it is not deliberate in openRA's case, they just mis-estimated what hardware is in use and/or new
10:03 celeron55_   you need to make the life of the modern hardware users as easy as possible while maintaining the legacy support
10:03 celeron55_   that's your goal now
10:03 Guest54      which will also happen to minetest
10:04 Guest54      celeron55_ it literally looks better on modern hardware than anything i have seen with shadowmaps
10:04 Fleckenstein i am working on it ok
10:04 sfan5        the point is totally lost on Guest54
10:04 Fleckenstein this discussion started with me criticising the way that unused features were nuked from irrlichtmt
10:04 sfan5        Fleckenstein: it would be useful to have a diff of what needs to be readded to irrlichtmt to get it back working
10:04 Fleckenstein yea
10:05 Fleckenstein ill submit a PR today
10:05 Fleckenstein i have most of it done already
10:05 Fleckenstein i just decided to make a remark about it
10:05 Guest54      Fleckenstein does that mean the changes in the ogl bindings were not too much of an obstacle?
10:05 Fleckenstein if different features were removed in different commits, it would have been easier to just revert one commit
10:05 celeron55_   i'd like to emphasize that MT is open to supporting old hardware, as long as supporting it doesn't hinder our ability to attract users of modern hardware and developers that understand modern graphics
10:06 Fleckenstein Guest54 it's not quite working yet
10:06 Fleckenstein but I think that's just some detail i missed somewhere
10:06 Fleckenstein most of it was just finding out what code to copy from modern irrlicht
10:07 Fleckenstein which ofc is suboptimal because we won't be able to backport patches from upstream for lighting code that way
10:07 Guest54      celeron55_ in that case, using stencil shadows fits the bill: you just have to set up the stencil buffer, provide lights, and call addShadowVolumeSceneNode() for the thing you want to cast a shadow for. there are a few more minor things, but that's about it.
10:08 celeron55_   we'll see once you submit the PR
10:08 Guest54      in fact, lizzy and me mainly looked at irrlicht example 8 (the one with the dwarf with realtime shadows that runs on a potato)
10:09 sfan5        this is probably the third time I'm saying this: we have to maintain the code in irrlicht too, it is not 'free'!
10:09 Guest54      celeron55_ search for “//add shadow” here to see what i mean ;) https://irrlicht.sourceforge.io/docu/example008.html
10:09 celeron55_   Guest54: talking about it instead of implementing it only makes it harder for you
10:09 celeron55_   and everyone else
10:09 Guest54      but lizzy already implemented it, see the video
10:10 Fleckenstein lizzy.rs/stencil_shadows.mp4
10:10 Fleckenstein http://
10:10 celeron55_   that's still talking, not implementing
10:10 Guest54      huh?
10:10 Fleckenstein I should leave the talking to Guest54 and get back to work
10:10 Guest54      i should get to work and leave the talking
10:17 Guest54      for future reference, in case the stencil shadows video goes away or ppl don't want to watch it: here is a screenshot that clearly shows what we are talking about, including self-shadowing on the player model https://mister-muffin.de/p/uIQN.png
10:24 Fleckenstein I'll put light manager in a separate commit, because I'm not sure whether we'll use it
10:26 pgimeno      isn't irrlicht in its way out, or did I misunderstand the plans?
10:28 celeron55_   "irrlicht" is now just a part of MT that happens to be called "irrlicht" and is a free-for-all for reworking
10:28 celeron55_   that's the way it's "going out"
10:30 Guest54      pgimeno irrlicht had a facility to do stencil shadows that was never used. a bunch of stuff that was never used was deleted from irrlichtmt. bringing it back does not require an additional dependency on recent irrlicht.
10:31 Guest54      so the first step yesterday was getting it to work with minetest 5.4 just calling irrlicht functions as a proof of concept, the second step is what i believe Fleckenstein is doing right now: figure out how to get it work with newer minetest which does not use irrlicht, by making irrlichtmt capable of doing it.
10:32 Fleckenstein yea basically just manually reverting the removal
10:36 pgimeno      and why was it removed?
10:37 Guest54      well, if you fork a library you have suddenly code ownership. which means you have a bunch of stuff. deleting it was a way to deal with less stuff.
10:38 Guest54      even if it is a joke, “deleted code is debugged code” can be, in many ways, true.
10:39 Guest54      pgimeno irrlichtmt is not a traditional fork, it is more “everything not used by minetest gets removed, the rest will be molded to whatever the coredevs desire instead of being a general-purpose library like irrlicht”
10:42 Guest54      pgimeno as a user, this mainly means 1. you have to update irrlichtmt it in lockstep with minetest 2. rendering facilities are limited to whatever the coredevs want (see the opengl 3 thing above) since everything else is nuked 3. and all irrlicht domain-specific knowledge goes the way of the dodo (which, considering they way minetest used irrlicht,
10:42 Guest54      is not too much of a loss lol)
10:45 Fleckenstein if you like modernization, what about a vulkan driver for irrlichtmt
10:45 Fleckenstein some irrlicht forks already have vulkan support, so we could probably cherry pick some stuff
10:51 Fleckenstein (to clarify, I'm offering to work on that if wanted)
10:51 Fleckenstein i saw it was mentioned once in irrlichtmt issues but the response has been somewhat indifferent
10:56 Guest54      btw, regarding driver support, sometimes drivers expose less facilities than you might expect. IIRC some old integrated intel graphics for example advertised ogl2.1 on linux, but years later it was suggested to only expose ogl1.4 because e.g. chrome and wine apps were using some things that were generally fast on ogl2+ GPUs, but not on the intel
10:56 Guest54      ones. i did not look into it deep enough though. just saying you have to actually run the thing to see if the advertised support works out.
10:57 Guest54      and also openRA basically did set ogl 3.2 as a minimum, so i think it's not too wrong to look at that project and see what went wrong (or right) with such a goal
11:01 Guest54      also the issue with ”do users have the hardware” basically solves itself, you can see that on their bug tracker too – when you increase minimum hardware requirements you get a bunch of reports at first of the game not working with some users at a knowledge level of “oh can i just download a new opengl version?” and then after a few years
11:01 Guest54      they stop, not because everyone has upgraded, but because the users simply went elsewhere
11:02 sfan5        Fleckenstein: not sure if you read the exact comment I wrote but vulkan would basically be duplicating the work (on the irr and engine side) while not bringing as much advantages over "simply" using modern OpenGL
11:04 Fleckenstein opengl (modern opengl too) still abstracts away from the hardware a lot, while vulkan is more idiomatic and therefore more performant
11:05 Fleckenstein while opengl is suitable for standalone projects (it does state management for you), game engines can benefit from vulkan's performance and debugging capabilities
11:06 Fleckenstein and duplication of work is mostly avoided by having an abstract interface (irrlicht) that can run OpenGL or Vulkan in the background?
11:07 pgimeno      my hardware isn't 10 years old and I don't think it supports Vulkan
11:09 sfan5        question if you can abstract it far enough that differences don't matter, I don't know
11:09 sfan5        if someone wrote a functioning vulkan driver it would probably be merged
11:11 Guest54      irrlicht vulkan has been done (or so someone claims on the internet) https://irrlicht.sourceforge.io/forum/viewtopic.php?t=52371
11:14 Guest54      there is also this Fleckenstein https://github.com/Devsh-Graphics-Programming/Nabla
11:14 Guest54      > Nabla (previously called IrrlichtBaW ) is a new renovated version of older Irrlicht engine. The name change to Nabla allows for using Nabla side by side with the legacy Irrlicht and IrrlichtBaW engines. The project currently aims for a thread-able and Vulkan-centered API, the Vulkan backend is almost complete, and OpenGL and ES backends are
11:14 Guest54      currently in maintenance mode.
11:24 sfan5        worth mentioning that testing any of the irrlicht forks has in the past failed on the fact that they stripped out all the GUI code
11:26 rubenwardy   we'd have to delete formspecs? Sounds like a plus
15:42 sfan5        rubenwardy: did you update the website with the new android url
15:42 rubenwardy   Idid
15:42 rubenwardy   https://github.com/minetest/minetest.github.io/commit/0ed9953f8faddd23bb78cbd7af8c61913db90d17
15:42 rubenwardy   !title
15:42 ShadowBot    Update link to Android .apk · minetest/minetest.github.io@0ed9953 · GitHub
15:42 sfan5        ah, good
15:44 sfan5        merging #13420 in 10m
15:44 ShadowBot    https://github.com/minetest/minetest/issues/13420 -- Update dependency libraries in buildbot by sfan5
15:49 sfan5        and #13336
15:49 ShadowBot    https://github.com/minetest/minetest/issues/13336 -- Simulate all keys being released when when game loses focus by Zardshard
16:00 rubenwardy   *coughs*
16:06 rubenwardy   and 99 PRs!
16:11 MTDiscord    <luatic> 99 PRs on the wall, 99 PRs. Take one down and pass it around, 98 PRs.
16:11 nrz          gg !
16:15 MTDiscord    <josiah_wi> Next milestone: 99 issues?
16:15 rubenwardy   I'll be happy with 999 issues
16:19 Krock        1055 issues are fine because it scares off people and reduces the risk of having to re-open duplicates due to "sudden importance"
16:20 MTDiscord    <Andrey01> Why do my open PRs continue to be ignored? I have been asking for reviewing them already many times on this channel starting still since the beginning of January and none of my requests weren't satisfied
16:23 sfan5        lack of time
16:23 sfan5        it's not only your PRs that are being ignored
16:49 Guest54      behold, for i have summarized the stencil shadow drama https://mister-muffin.de/p/DLlb.png
16:51 Fleckenstein hehe
16:52 MTDiscord    <ROllerozxa> LOL
16:58 Krock        rubenwardy: scroll up: https://github.com/minetest/minetest/pull/12768/files#diff-d0ed4cc3fb70489fe51c7e0ac180cba2a7472124f9f9e9ae67b01a37fbd580b7R80
16:58 rubenwardy   oh dang
16:58 Krock        tbf I almost missed it too
16:58 rubenwardy   got confused by the weird indentation in the GitHub sidebar
16:59 MTDiscord    <luatic> can't you edit the PR?
17:00 Guest54      carmack about the tradeoffs in shadow volumes vs shadow maps: https://fabiensanglard.net/doom3_documentation/CarmackOnShadowVolumes.txt
17:00 rubenwardy   Anyway, don't forget the mixed indentation
17:00 MTDiscord    <luatic> I feel like round trips could be avoided for trivialities if core devs just fixed such issues right away; commenting and then waiting for the PR author to fix and then re-reviewing surely takes longer?
17:01 Krock        in that case, yes. generally no because there might be different opinions on it
17:01 rubenwardy   makes sense for code style
17:01 rubenwardy   pushed
17:02 rubenwardy   merging #12768 and #13322 in 10
17:02 ShadowBot    https://github.com/minetest/minetest/issues/12768 -- [nosquash] Bigfoot and footstep at feet by Desour
17:02 ShadowBot    https://github.com/minetest/minetest/issues/13322 -- Fix black loading screen background if `menu_clouds = false` by grorp
17:02 rubenwardy   unless you wanted to review that latter one sfan5?
17:02 Krock        I think there's one more
17:02 Krock        #13238 <-- for merge
17:02 ShadowBot    https://github.com/minetest/minetest/issues/13238 -- Clarify documentation of punch key by Wuzzy2
17:03 rubenwardy   ah sure
17:04 rubenwardy   Apparently the most popular shadow volume technique is patented
17:05 Guest54      carmacks reverse you mean?
17:05 rubenwardy   nevermind, the patent expred https://patents.google.com/patent/US6384822B1/en
17:06 Guest54      given the stuff was working on hardware 20+ dears ago i am not surprised by it expiring ^^
17:26 Guest54      trolling aside, what does the high quality setting on the shadow maps actually do besides reducing the frame rate on higher quality? to me it looks like it just tries to blur the (shadowmap-undersampling-related?) aliasing artifacts away, but you can see them even at the highest setting
17:28 rubenwardy   it increases the size of the shadow map and also does filtering
17:28 Guest54      oh, i guess that means it's like carmack says, you basically get aliasing artifacts at any size
17:31 Guest54      rubenwardy do high quality shadow maps without filtering just exhibit less pixelated artifacts or do they become different?
17:31 Guest54      i mean stuff like the triangles at node edges
17:32 MTDiscord    <x2048> "reducing framerate" id very subjective btw. higher SM resolution = higher fill rate requirememt. If the GPU cannot keep it, FPS drops significantly.
17:32 Guest54      for reference, the triangles i mean https://mister-muffin.de/p/n_1v.png
17:33 Guest54      x2048 so what was your opinion of stencil shadows when you evaluated them?
17:33 MTDiscord    <x2048> I did not 🙂
17:33 Guest54      oh lol
17:33 MTDiscord    <x2048> I only brought the shadow map PR to completion
17:34 Guest54      x2048 are you aware of anyone finding a problem with the irrlicht stencil shadows?
17:34 MTDiscord    <x2048> no, I am not aware of anyone using them either 🙂
17:35 MTDiscord    <x2048> why would that matter?
17:35 Guest54      because “for the stencil shadows ask our resident graphics experts about the implications”
17:36 MTDiscord    <x2048> BTW is this the right place for these discussions or is it better in -hub?
17:37 Guest54      well lizzy is working on stencil shadows, isn't it a dev theme. they got deleted from irrlichtmt, so they have to be put back in.
17:37 MTDiscord    <x2048> nvm
17:39 Guest54      x2048 did you watch the video lizzy posted? anyways, in case you can spare the time, if you find any problems with stencil shadows besides “the shadow is a single color” and “it will disregard transparent textures on the mesh”, i'd be interested and i guess so are others.
17:40 Fleckenstein >tfw walking in the sun irl and getting the sudden urge to switch to third person the check your shadow
17:40 Fleckenstein my brain has been severely damaged
17:40 Fleckenstein *to check your shadow
17:40 MTDiscord    <x2048> I'm not a graphics expert by any means, just happened to be in the right place uøin the right time. I've seen the demo and read the writeup by Carmack. My impression is that it's best for closed spaces and games with predictable scenes.
17:41 MTDiscord    <x2048> The warning about fillrate and bounding the shadow volumes raises a flag.
17:43 Guest54      x2048 “best for closed spaces” because of the projection to infinity or what?
17:44 Guest54      (i am of the opinion that you do not necessarily want to cast a shadow on a mountain 2 mapblocks over, since artificial light does not reach that far in minetest)
17:48 rubenwardy   Desour: quick question, why are the `open` functions for example `SoundDataUnopenBuffer::open` limited to r-values? Is it so that users access via a shared_ptr?
17:50 Desour       rubenwardy: that's because the unopen sounddatas are not meant to be kept after opening. it also allows not copying SoundDataUnopenBuffer's buffer (= the compressed ogg vorbis file)
17:51 MTDiscord    <x2048> that limiting of the volumes requires more than 1 function call in irrlicht. is this problem solved?
17:51 MTDiscord    <x2048> what about shadows from the sun?
17:52 Guest54      x2048 given the (perceived by me) huge amount of work that went into shadow mapping bugfixes, could you point to some things where shadowmaps needed work that might also be a problem for shadow volumes? also, is minetest using perspective shadow maps or a shadow map from world light space?
17:55 MTDiscord    <x2048> none of those, which is a problem of its own
17:55 Guest54      wait what does it do
17:56 Guest54      the only other technique i know about is creating a depth map from the light POV and constructing shadow volumes from the edges in the picture, but that seems a bit far out hehe
17:56 Guest54      also it's basically the unholy child of both approaches hehe
17:59 Guest54      maybe a forum thread about shadow volumes would be more appropriate
18:01 MTDiscord    <x2048> It does a variation of simple SM with nonlinear "lens" distortion of the SM.
18:02 Guest54      x2048 distortion so that the thing looks less blocky or what?
18:02 MTDiscord    <x2048> This this allows condensing the resolution of SM near the player and cover larger area of the map using a single texture.
18:03 Guest54      and the triangle thing is inherent to the method?
18:03 Guest54      i mean it happens very close to the player as well
18:03 MTDiscord    <x2048> What you see there are texels of the shadow map.
18:04 Guest54      oh no
18:04 MTDiscord    <x2048> If the resolution is high enough that 1 SM texel has the size of one pixel you won't see them
18:04 Guest54      and everything else is undersamping
18:05 MTDiscord    <x2048> SMs are always undersampled
18:05 Guest54      then i correct myself, carmack was not only right, he was *horribly* right
18:05 MTDiscord    <x2048> ni one cares
18:05 MTDiscord    <x2048> *no one
18:05 MTDiscord    <x2048> event Pixar
18:06 Guest54      well, they are not doing real-time rendering
18:06 Guest54      anyways, thanks for the info, i have to go
18:10 Guest54      x2048 oh, btw do you share any of the concerns regarding the use of the stencil buffer being “legacy opengl”?
18:54 Desour       it's weird, I can't find the option to force-enable HRTF anymore in alsoft-config. and if I save the config to a file, it doesn't include force-enabled hrtf either (I still have hrtf though)
18:57 rubenwardy   not in the HRTF tab?
18:57 Desour       hm, but in ~/.config/alsoft.conf, the option still exists and works
18:58 rubenwardy   huh same, the GUI doesn't appear to have that any more
18:58 Desour       maybe the alsoft-config window is just too small to show it
18:58 rubenwardy   Playback > Stereo Mode > Headphones maybe?
18:58 Desour       or the option was deprecated or something
19:00 Desour       if I rename my alsoft.conf, hrtf gets off again
19:00 Desour       I've tried stereo mode, but it seems to be something different
19:03 Desour       ah, stereo mode is the new setting, but the hrtf settings seems to take preference
19:03 Desour       (when I tried it, I set it to speakers, while force hrtf was still on)
19:47 MTDiscord    <x2048> Guest54: well, stencil buffers and operations are not formally "obsolete" but due to stencil test being a part of the latest stage of the fixed pipeline, it is does not help performance and requires multiple 3D passes per frame which in turn requires 3D pass to be very fast: imagine using VBO/VAOs, low number of drawcalls etc. Minetest does not have a very fast 3D stage. From what I've read, many of the problems where stencil buffer
19:47 MTDiscord    helps can be solved in fragment shaders and more efficiently since fragment shader can terminate early or do the operation in one pass.
19:54 Guest54      x2048 so what you are saying is that shadow maps are fully orthogonal to the rest of the rendering pipeline
19:54 MTDiscord    <x2048> *"Multiple 3D passes per frame" may not be fully correct, there must be 1+ passes (parts of the scene or on-screen primitives) that fill the buffer (unless it's previously filled), and 1+ passes (again, scene, primitives or effects) to draw using the stencil.
19:54 MTDiscord    <x2048> what do you mean by orthogonal?
19:55 Guest54      it doesn't affect the pipeline too much since you are working on a texture, not on geometry
19:57 MTDiscord    <x2048> The way it's done now, it's a dedicated, hand-crafted 3D pass, but it uses the same geometry. It can be rewritten using the main 3D pass, but lack of time 😕
19:58 Guest54      so what i don't get is: if shadow volumes require so much resources, how come the irrlicht stencil shadows have vastly lower resource consumption than the shadow mapping approach?
20:00 MTDiscord    <x2048> I don't know what the claim of having vastly lower resource consumption is based on.
20:01 MTDiscord    <x2048> Shadows at 11 AM are small, and shadows from animals on a flat surface are very short. Try mountains covered with trees during sunset.
20:02 MTDiscord    <x2048> Btw, tree leaves will never cast correct shadows with shadow volumes, because if texture transparency being important.
20:02 Guest54      i do know that
20:06 Guest54      x2048 my claim on lower resource consumption is that i own a bunch of old thinkpads that all have so much framerate loss with shadow maps that stuff is unplayable, while on the same devices you can use irrlicht stencil shadows and it's not such a huge a drag on resources.
20:06 Guest54      well, with shadow maps in minetest
20:09 Guest54      i'll test the performance when lizzy has her stuff ready
20:31 MTDiscord    <Fleckenstein> https://github.com/LizzyFleckenstein03/minetest/tree/stencil_shadows
20:44 sfan5        looking at the irrlicht commits the opengl driver uses glLight*() which at https://docs.gl/gl3/glLight is categorized under "fixed function" and indicated to be removed in OpenGL 3.2 or later
20:55 MTDiscord    <x2048> Looking at performance, it does not seem that any part of the map casts shadows in this patch, and that is 95% of performance impact (not taking into account the memory needed for shadow map)
21:23 MTDiscord    <Fleckenstein> terrain is todo
23:00 rubenwardy   merging #13414 in 10
23:00 ShadowBot    https://github.com/minetest/minetest/issues/13414 -- Add focused styling to buttons by rubenwardy
23:03 rubenwardy   given notice feels a bit pointless when other devs are probably asleep
23:05 rubenwardy   and #13408
23:05 ShadowBot    https://github.com/minetest/minetest/issues/13408 -- [NOSQUASH] Track server's maximum AsyncRunStep by lhofhansl