Minetest logo

IRC log for #minetest-dev, 2021-06-25

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:14 v-rob joined #minetest-dev
00:35 v-rob joined #minetest-dev
00:41 tekakutli joined #minetest-dev
00:46 MTDiscord <exe_virus> What is celeron55's opinion on server sent csm's?
00:46 Lone_Wolf joined #minetest-dev
00:51 Lone_Wolf Is this a known issue? Or am I doing something wrong? https://user-images.githubusercontent.com/28972859/123352579-6fff5a00-d514-11eb-9cba-27f0a5130538.png
00:51 Lone_Wolf Set it to build a server and not a client but it still wants Irrlicht
00:51 MTDiscord <GreenXenith> Minetest server still depends on Irrlicht
00:51 MTDiscord <GreenXenith> There are some math libs and other helpers it needs
00:58 Lone_Wolf According to the docs: If you build a bare server you don't need to have the Irrlicht or IrrlichtMt library installed.
00:59 Lone_Wolf This doesn't appear to indicate I need the libs: "In that case use -DIRRLICHT_INCLUDE_DIR=/some/where/irrlicht/include."
00:59 MTDiscord <GreenXenith> That wasn't my experience, so perhaps it is a bug]
00:59 MTDiscord <GreenXenith> -]
01:47 Lone_Wolf Yeah looks like you still need the includes
01:47 Lone_Wolf At least I don't need to compile it lol
01:50 YuGiOhJCJ joined #minetest-dev
02:56 wsor4035 joined #minetest-dev
03:43 v-rob joined #minetest-dev
06:46 sfan5 I thought that message is clear enough because it says "headers"
07:34 specing_ joined #minetest-dev
08:46 tech_exorcist joined #minetest-dev
08:47 tech_exorcist joined #minetest-dev
09:31 Fixer joined #minetest-dev
10:25 calcul0n joined #minetest-dev
10:30 freshreplicant[m joined #minetest-dev
10:40 wsor4035 joined #minetest-dev
11:03 entuland joined #minetest-dev
11:27 calcul0n_ joined #minetest-dev
12:10 Wuzzy joined #minetest-dev
13:20 tech_exorcist joined #minetest-dev
14:13 Fixer_ joined #minetest-dev
15:09 \c joined #minetest-dev
15:23 kilbith joined #minetest-dev
15:27 kilbith joined #minetest-dev
15:57 Fixer joined #minetest-dev
17:28 book` joined #minetest-dev
18:10 Fixer_ joined #minetest-dev
18:34 Noisytoot joined #minetest-dev
18:47 MTDiscord <Liso> Shadow Mapping bugfix sent, #11388
18:47 ShadowBot https://github.com/minetest/minetest/issues/11388 -- Bugfix #11321 #11357 #11321 by 0xLiso
19:20 pgimeno ahh I was wondering about the dupe, it's already fixed
19:29 hecks joined #minetest-dev
19:30 hecks so I just found out that irr uses this weird monkey api for setting uniforms that someone had to make a whole lot of weird template scaffolding to even support
19:31 hecks would it be okay to just drop that and require ARB_shader_objects?
19:32 hecks there's basically nothing in the wild that supports GLSL shaders and does not have ARB_shader_objects
19:32 hecks and that extension is the GL shader program API more or less as it looks like today
19:36 specing_ joined #minetest-dev
19:39 MTDiscord <Liso> and the previous way to define uniforms is marked as deprecated. It could be nice if we redesign the shader api. but to do that, we need to change more things :/
19:43 hecks I'm rewriting shaders right now
19:44 hecks just asking for a green light to require support for shader programs from now on
19:46 hecks when i'm done with this, it should be easy to create a materials lua api too
19:46 hecks create and set materials and uniforms on CAOs remotely
19:48 sfan5 does irrlicht do any internal handling of ARB_shader_objects already?
19:49 hecks it seems to address the functions but it only exposes the stupid api for uniforms...
19:49 hecks anyway i'm committed enough to this task that this might be the moment i pull in raw GL if need be
19:49 hecks but i'll try to make irrlicht give me the pointers for the time being because it caches them anyway
19:51 hecks IMaterialRendererServices is the rubbish i speak of, separate vertex and fragment uniforms are stone age
19:52 hecks and we've got this CachedShaderSetting<T,n> thing which is then specialized into two different subclasses to deal with it
19:53 hecks this is going away completely, both the subclassing and the template; the correct way is to ask GL for a list of the uniforms that the program actually contains
19:55 sfan5 better add some wrapping around it in IrrlichtMt
19:55 sfan5 so it can work seamlessly with the ogles2 driver
19:55 hecks from what i gather gles2 and gl2 are identical in this regard
19:55 hecks i'll just make irrmt give me the appropriate function pointers ok?
19:56 sfan5 hm
19:57 hecks you know what's ridiculous? irr actually shims the "correct" functions from what i gather
19:57 hecks the whole IMaterialRendererServices api makes zero sense
19:58 hecks read COpenGLSLMaterialRenderer.cpp:611 for a laugh
20:00 hecks so anyway i want to stop shimming the gl uniform api entirely, the way it's done in the function right below is awful
20:02 hecks kill this switch statement and just expect the caller to know what type it's setting
20:05 hecks the plan is to also never set uniforms immediately but wait until the program is bound for drawing, and set it all opportunistically at that time
20:06 sfan5 I don't get why irrlicht has that renderservices thing anyway
20:06 hecks ツ it's a very stupid engine
20:07 sfan5 change what you think is necessary, I think it'd be nice to keep the GL(ES) inside IrrlichtMt but no hard requirement
20:07 pgimeno hecks: are you able to test in ogles2?
20:07 hecks i can't test in ogles2 *but*
20:07 hecks reading the gles2 specification i see it's word for word like the desktop gl2 spec, at least in the shader sections
20:08 hecks and besides, irrlicht already uses the program api behind the scenes
20:08 hecks it's just hiding it behind this ancient uniform setter api
20:08 pgimeno hm, you can't use 3 in place of 3.0 as far as I know, that's one thing that has bitten hundreds of people
20:08 hecks so i want to unhide it
20:08 hecks yeah i know gles3 is closer to gl4
20:08 hecks but 2.0 seems to correspond
20:09 pgimeno by 3 and 3.0 I mean an integer in place of a float
20:09 hecks as far as programs and uniforms are concerned that's all that matters
20:09 hecks haha ok
20:10 hecks draft of the new shader api:
20:10 hecks https://paste.uguu.se/?2db048e61c32b5b5#EPNbfy5JiBGKV3T36NxTwZ7jcabSUVXy3HtgMZYrVyPH
20:11 hecks ignore the style mismatch, it can be hammered into shape later
20:11 pgimeno does it have to be encrypted? " Error decompressing paste, due to missing WebAssembly support."
20:11 hecks ah oh well
20:12 hecks pastebin refuses to work for me =]
20:12 MTDiscord <Liso> coolz
20:13 hecks don't worry i'll just draft pr it when it's somewhat solidified
20:13 pgimeno sure
20:13 sfan5 Material::Set looks like it could use v3s{16,32} and v3f wrappers
20:14 hecks yeah sure
20:14 hecks this is more sketch than code right now
20:14 hecks my main concern was figuring out the variant mechanism
20:15 hecks pgimeno: in short it's based on four types: program, pass, shader, material
20:15 hecks materials utilize shaders, shaders contain passes (utility passes like shadowcaster etc), passes contain a bunch of variant programs for feature toggling
20:15 hecks and a program just wraps the GL program
20:20 hecks guess we'll need both per shader and per material feature toggles because of things like shadows
20:20 hecks oh right this should allow per object shadow caster/receiver flags
20:20 hecks since it'll be possible for objects and nodes to selectively choose whether they receive a shader or not
20:21 hecks a shadow*
20:23 MTDiscord <Liso> the receiver shadow it's not implemented, to avoid a different render for those objects. in this bugfix there is a NDT_WIELD to avoid receive shadow(mainly for wield objects/hand). but to cast shadow yes. even we can make a node property to set the shadow casting on/off
20:26 MTDiscord <Liso> btw hecks , I really appreciate if you can test the shadow bugfix with your rounded models. just to know if that's the correct path or not.
20:26 hecks where
20:26 hecks be aware that it will never look good on my models because they do not account for shading in their topology
20:27 MTDiscord <Liso> ok
20:27 hecks but link the branch
20:27 MTDiscord <Liso> #11388
20:27 ShadowBot https://github.com/minetest/minetest/issues/11388 -- Shadow Mapping pass Bugfix #11321 #11357 #11341 by 0xLiso
20:27 MTDiscord <Liso> or https://github.com/0xLiso/minetest-shadowmap/tree/PSM whatever you want
20:27 hecks the closest thing to looking acceptable i could ever get was linear bias with unconditionally hard shadows
20:27 hecks but
20:28 hecks you need cascades to get an acceptable resolution for that
20:28 MTDiscord <Liso> and you know the problem with csm XD
20:28 MTDiscord <Liso> right now, at least
20:28 hecks i suspect that if the PCF was more subtle like in the other engines, it could also work
20:28 hecks but yours is too soft
20:29 hecks but yeah, there just isn't enough resolution in any case
20:29 hecks neither spatial nor depth for some reason
20:29 MTDiscord <Liso> yes 4x4 and 8x8, poisson makes better results IMHO
20:29 hecks it's more like
20:29 hecks whatever you do, it looks like you just copy the shadow around a few times
20:30 hecks while what i'm used to is something that looks like texture filtering
20:30 hecks usually a 3x3 or 5x5 filter
20:30 hecks i never had to implement it so i didn't look into what exactly they do
20:30 MTDiscord <Liso> I just c&p nvidia's demo for PCF xD
20:30 hecks and how old is that demo?
20:31 MTDiscord <Liso> newer than irrlitch xD
20:31 hecks looks like unity just does a 4-tap bilinear filter
20:31 MTDiscord <Liso> it is exactly what pcf is
20:31 hecks explains why it's so much easier on the fill
20:32 hecks now how many taps does minetest do...
20:32 MTDiscord <Liso> moderns impl uses poisson + random texture displacements and temporal filtering
20:32 MTDiscord <Liso> taps?
20:32 hecks shadow texture lookups
20:33 hecks i don't care about what's modern, i care about what runs well enough
20:33 hecks i'd rather spend some of that fill on other things like antialiasing
20:33 MTDiscord <Liso> 16 or 64 with level 1 or 2 of filtering, but with soft shadows makes much more
20:33 hecks which every dev these days seems to neglect
20:33 hecks holy cow
20:34 hecks well
20:34 hecks consider not doing that, this is overkill for a block game
20:34 hecks it's roasting my card, especially in forests which already have insane overdraw
20:34 MTDiscord <Liso> there is no other way, at least I don't know other way
20:35 hecks well the other way is to do a bilinear or bicubic filter
20:35 hecks you know how those work right?
20:35 MTDiscord <Liso> you sure?
20:36 hecks i'm sure that a 4x4 bilinear filter wouldn't be roasting my GPU
20:36 sfan5 the gpu will do bilinear filtering on texture access for you, won't it?
20:36 hecks no sfan, there's a catch here
20:36 hecks you cannot filter shadow maps
20:36 hecks because they're depth buffers and you're effectively doing a depth comparison
20:37 hecks and what you want to filter is the occlusion value, not the depth
20:37 sfan5 I see
20:37 hecks so your recourse is to do the bilerp yourself
20:38 MTDiscord <Liso> uhmmm that could work hecks
20:38 hecks of course you can do 16 taps and a bicubic filter as well
20:38 hecks meanwhile, liso, your approach is basically brute force
20:38 MTDiscord <Liso> but not in where you think, maybe when we mix the map shadows and objects shadows
20:38 hecks you're making a lot of samples with random offsets and integrating them
20:39 hecks and while this works if you have an insane amount of samples, it's an "ultra quality" kind of technique
20:39 MTDiscord <Liso> that is what I saw everywhere
20:39 hecks so it would be good to have options for 2x2 bilinear and pure hard shadows too
20:39 hecks the performance isn't even that bad with a hard shadow
20:40 MTDiscord <Liso> I'm going to try it
20:40 hecks go ahead
20:41 MTDiscord <Liso> btw, irrlitch doen't support mipmaping ? because maybe we can simulate the same with mipmaping
20:41 hecks what does mipping have to do with it
20:42 hecks mipmapping just samples a lower resolution copy of a texture based on the texcoord derivative
20:42 hecks and if you're thinking of using hardware bilinear filtering, see my response to sfan asking the same
20:42 MTDiscord <Liso> ok
20:42 MTDiscord <Liso> make sense
20:42 hecks you cannot filter depth data, you'll get a nonsense result
20:42 hecks it's just like a deferred gbuffer
20:44 hecks if you get stuck on this you can read unity's shaders, they're MIT licensed
20:45 hecks but reconstructed bilinear is easy anyhow
20:51 v-rob joined #minetest-dev
20:53 MTDiscord <Liso> ok, tnx
20:54 MTDiscord <Liso> anyway rtt mipmaps are disabled in irrlicht. IDK if it is for what hecks said or other reason, but its force to false
20:55 hecks i think it's unrelated
21:11 MTDiscord <Liso> Also: GLSL 1.20 specification (section 8.7) states that fragment shaders cannot choose their own mipmap level. so no hardware filtering for us in any way xD
21:13 hecks this depends on the hardware level, you can choose mips on newer cards
21:13 hecks still i don't know of any shadow mapping techniques that utilize mips
21:19 MTDiscord <Liso> MC for example
21:25 MTDiscord <Liso> Hecks, can I make a request for the new shaders ?? the #include tag 😉
21:25 hecks what?
21:26 tech_exorcist joined #minetest-dev
21:27 hecks it's not even PRed yet, or even in any usable state
21:28 MTDiscord <Liso> yes, I know, just asking 🙂
21:28 hecks i'll gladly convert everything myself when it's done, you don't need to concern yourself with that
21:28 hecks also don't bother with emoji, i won't see them anyway
21:29 MTDiscord <Liso> no, i'm not worry about that, it's just not having the #include in shaders make us to repeat code everywhere
21:30 hecks oh you mean inside glsl
21:32 hecks supporting #include properly is a bit of a tall order
21:33 hecks and it would be bad if it didn't behave like everywhere else
21:33 MTDiscord <Liso> just asking santa xD
21:38 hecks santa is very busy and just took a detour to do a nightmare pr from hell because it's technically a prerequisite for shadow mapping
21:38 MTDiscord <Liso> you are enjoying it 😉
21:59 behalebabo joined #minetest-dev
22:29 v-rob joined #minetest-dev
23:04 hecks another oddity found; we're concating shader chunks in ShaderSource::generateShader, right...
23:04 hecks but did you know that glShaderSource will do it for you as well?
23:19 hecks also do we have any plans to trim the fat from irrmt? surely we don't need: software and D3D drivers, quake 3 assets, image formats that the MT server never sends...
23:19 hecks this would reduce compile times and the size of debug builds
23:58 Alias2 joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext