| 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 |
