| Time |
Nick |
Message |
| 00:07 |
|
proller joined #minetest-dev |
| 00:39 |
|
proller joined #minetest-dev |
| 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 |
| 01:02 |
|
proller joined #minetest-dev |
| 01:50 |
|
proller joined #minetest-dev |
| 01:53 |
|
tekakutli joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:05 |
|
calcul0n joined #minetest-dev |
| 05:10 |
|
tekakutl` joined #minetest-dev |
| 05:52 |
|
epoch joined #minetest-dev |
| 06:47 |
|
tekakutli joined #minetest-dev |
| 08:21 |
|
Fleckenstein joined #minetest-dev |
| 08:36 |
|
proller joined #minetest-dev |
| 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 |
|
EliasFleckenstei joined #minetest-dev |
| 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 |
|
tekakutli joined #minetest-dev |
| 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 |
|
freshreplicant[m joined #minetest-dev |
| 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 |
|
programmerjake joined #minetest-dev |
| 09:42 |
|
Zughy[m] joined #minetest-dev |
| 09:42 |
Guest54 |
unless you want more than 8 lights without a light manager (which selectively turns them on and off) probably |
| 09:42 |
|
lebruhgamer[m] joined #minetest-dev |
| 09:42 |
|
MisterE[m] joined #minetest-dev |
| 09:42 |
|
fgaz joined #minetest-dev |
| 09:42 |
|
Kimapr joined #minetest-dev |
| 09:42 |
|
Goobax[m] joined #minetest-dev |
| 09:43 |
|
Jon[m] joined #minetest-dev |
| 09:43 |
|
olive[m] joined #minetest-dev |
| 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:23 |
|
Goobax[m] joined #minetest-dev |
| 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:29 |
|
fgaz joined #minetest-dev |
| 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:43 |
|
MisterE[m] joined #minetest-dev |
| 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:48 |
|
Jon[m] joined #minetest-dev |
| 10:48 |
|
olive[m] joined #minetest-dev |
| 10:51 |
Fleckenstein |
(to clarify, I'm offering to work on that if wanted) |
| 10:51 |
|
lebruhgamer[m] joined #minetest-dev |
| 10:51 |
Fleckenstein |
i saw it was mentioned once in irrlichtmt issues but the response has been somewhat indifferent |
| 10:55 |
|
Zughy[m] joined #minetest-dev |
| 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 |
|
programmerjake joined #minetest-dev |
| 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 |
|
freshreplicant[m joined #minetest-dev |
| 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:12 |
|
Kimapr joined #minetest-dev |
| 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 |
| 11:35 |
|
freshreplicant[m joined #minetest-dev |
| 11:47 |
|
programmerjake joined #minetest-dev |
| 11:47 |
|
MisterE[m] joined #minetest-dev |
| 11:47 |
|
fgaz joined #minetest-dev |
| 11:47 |
|
Kimapr joined #minetest-dev |
| 11:47 |
|
Goobax[m] joined #minetest-dev |
| 11:47 |
|
lebruhgamer[m] joined #minetest-dev |
| 11:47 |
|
olive[m] joined #minetest-dev |
| 11:47 |
|
Zughy[m] joined #minetest-dev |
| 11:47 |
|
Jon[m] joined #minetest-dev |
| 12:30 |
|
turtleman joined #minetest-dev |
| 12:47 |
|
Guest54 joined #minetest-dev |
| 14:35 |
|
fluxionary joined #minetest-dev |
| 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:47 |
|
moonmoon left #minetest-dev |
| 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:48 |
|
Desour joined #minetest-dev |
| 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:15 |
|
tekakutli joined #minetest-dev |
| 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:01 |
|
EliasFleckenstei joined #minetest-dev |
| 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:02 |
|
Fleckenstein joined #minetest-dev |
| 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:49 |
|
proller joined #minetest-dev |
| 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:23 |
|
lionkor joined #minetest-dev |
| 20:31 |
MTDiscord |
<Fleckenstein> https://github.com/LizzyFleckenstein03/minetest/tree/stencil_shadows |
| 20:32 |
|
proller joined #minetest-dev |
| 20:36 |
|
YuGiOhJCJ joined #minetest-dev |
| 20:39 |
|
tekakutli joined #minetest-dev |
| 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:03 |
|
proller joined #minetest-dev |
| 21:23 |
MTDiscord |
<Fleckenstein> terrain is todo |
| 21:30 |
|
proller joined #minetest-dev |
| 21:59 |
|
proller joined #minetest-dev |
| 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 |
