| Time |
Nick |
Message |
| 00:07 |
|
kilbith joined #minetest-dev |
| 00:29 |
|
kilbith joined #minetest-dev |
| 01:10 |
|
Extex joined #minetest-dev |
| 01:15 |
|
MTDiscord5 joined #minetest-dev |
| 01:23 |
|
kilbith joined #minetest-dev |
| 02:01 |
|
kilbith joined #minetest-dev |
| 02:25 |
|
queria joined #minetest-dev |
| 02:30 |
|
queria^clone joined #minetest-dev |
| 02:35 |
|
kilbith_ joined #minetest-dev |
| 04:28 |
|
T4im joined #minetest-dev |
| 04:37 |
|
Lone_Wolf joined #minetest-dev |
| 05:55 |
|
T^4im joined #minetest-dev |
| 06:04 |
|
T4im joined #minetest-dev |
| 06:44 |
|
v-rob joined #minetest-dev |
| 06:47 |
|
Pexin joined #minetest-dev |
| 07:28 |
nrz |
as now we forked irrlicht i really think we should have this SDL2 layer inside irrlicht, drop the legacy similars layers and use a proper binding on minetest instead of a compat layer to prevent breakage on client |
| 07:28 |
nrz |
especially on the text input part, SDL2 is totally different than the current irrlicht input model |
| 08:01 |
|
specing_ joined #minetest-dev |
| 08:29 |
|
CeeGee joined #minetest-dev |
| 08:30 |
|
m42uko joined #minetest-dev |
| 08:42 |
|
olliy joined #minetest-dev |
| 08:50 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:46 |
|
hecks joined #minetest-dev |
| 09:52 |
hecks |
I need help compiling the irrlicht fork, make can't find libs like zlib, png and jpeg and there's nothing referring to them in the generated makefile |
| 10:06 |
|
calcul0n_ joined #minetest-dev |
| 10:10 |
sfan5 |
"make can't find" means linking errors or ..? |
| 10:10 |
hecks |
linker errors in make |
| 10:10 |
hecks |
it can't find any symbol from these libs while building irrlichtmt.dll |
| 10:10 |
hecks |
mingw 64 bit in cygwin |
| 10:11 |
sfan5 |
what are the respective *_LIBRARY vars set to? |
| 10:12 |
hecks |
-DJPEG_LIBRARY=$libs/libjpeg/lib/libjpeg.dll.a , I'm using the CI script |
| 10:12 |
hecks |
I checked the paths and they point to the right place |
| 10:12 |
sfan5 |
oh uh |
| 10:13 |
sfan5 |
I very much doubt libs compiled for "normal" usage work inside cygwin |
| 10:14 |
hecks |
uhhhh elaborate? |
| 10:14 |
hecks |
oh wait |
| 10:14 |
hecks |
the .a files are the wrong format? |
| 10:14 |
hecks |
to make it clear, I build using cygwin but the target is still regular windows |
| 10:15 |
sfan5 |
so you're cross-compiling from there? |
| 10:15 |
hecks |
and the CI scripts and libs from your server have always worked for building minetest itself in this way |
| 10:15 |
hecks |
yup |
| 10:15 |
hecks |
just treating it as the linux box I can't run because it's too hot for that at the moment =] |
| 10:16 |
sfan5 |
that's ... weird, should work though |
| 10:16 |
hecks |
yeah, what are we looking for here? |
| 10:16 |
sfan5 |
are you compiling for 64-bit and did it accidentally download 32-bit libs? |
| 10:17 |
sfan5 |
you should have CC/CXX set to something like x86_64-w64-mingw-g++ not g++ |
| 10:17 |
hecks |
yes I did that |
| 10:17 |
sfan5 |
okay just making sure |
| 10:17 |
hecks |
but your guess about the libs might be right, deps walker is telling me it's x86... i think |
| 10:18 |
sfan5 |
pastebin the make output? |
| 10:21 |
hecks |
https://paste.uguu.se/?844318c355b6f658#AKAPRDBfPEPa3xYz429cSdKeEXhtWisvxLKqWJryBMRe |
| 10:22 |
hecks |
"bin/Win32-gcc/IrrlichtMt.dll" looks suspicious |
| 10:23 |
hecks |
variant = win32 |
| 10:23 |
hecks |
uh oh? |
| 10:23 |
hecks |
oh f me |
| 10:23 |
hecks |
consider this a little bug |
| 10:23 |
hecks |
CC=/usr/bin/x86_64-w64-mingw32-gcc.exe |
| 10:23 |
hecks |
[[ "$CXX" == "x86_64-"* ]] && variant=win64 |
| 10:24 |
hecks |
i pasted the wrong line but CXX also starts with /usr/bin/ |
| 10:24 |
sfan5 |
unfortunate |
| 10:24 |
hecks |
it'll probably work if i remove that, but that check is a bit brittle =] |
| 10:26 |
hecks |
thanks, good catch on the bitness, i wouldn't have looked there |
| 10:31 |
hecks |
whoops, premature celebration |
| 10:32 |
hecks |
i should probably delete /libs/ |
| 10:32 |
hecks |
yup, worked |
| 10:49 |
|
entuland joined #minetest-dev |
| 10:55 |
hecks |
and minetest crashes on startup, lovely |
| 10:56 |
hecks |
time to make the atrocious debug build and run it through an equally atrocious debugger to learn probably nothing of value |
| 11:11 |
hecks |
Thread 1 received signal SIGSEGV, Segmentation fault. in irr::CIrrDeviceStub::CIrrDeviceStub(irr::SIrrlichtCreationParameters const&) () |
| 11:13 |
hecks |
haha, what... minetest.exe was placed in /src/ somehow |
| 11:13 |
|
Fixer joined #minetest-dev |
| 11:13 |
hecks |
finally |
| 11:27 |
hecks |
I'd like to thank whoever merged this amazing rendering feature https://a.uguu.se/weruqMBFnvm6_shadowmap.jpg |
| 11:27 |
hecks |
I never knew I needed it! |
| 11:54 |
|
calcul0n__ joined #minetest-dev |
| 12:13 |
|
hecks joined #minetest-dev |
| 12:20 |
hecks |
#11365 grab yer pitchforks... or popcorn |
| 12:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/11365 -- Shadowmaps can not be disabled by the server |
| 12:21 |
sfan5 |
you could file the same issue for 100 other features |
| 12:21 |
hecks |
yes, and some of them are also a problem, but there's one key difference |
| 12:24 |
hecks |
it's a new feature and it shouldn't break anything that was made before it |
| 12:26 |
hecks |
also, justifying an issue with existing issues is poor reasoning |
| 12:27 |
hecks |
I really hoped that after 9985 I wouldn't have to do this again |
| 12:28 |
hecks |
but I guess not, there's probably at least a handful of people who see inconveniencing me as a bonus |
| 12:29 |
sfan5 |
that's a weird conspiracy theory |
| 12:29 |
hecks |
really, just read any of the threads related to that issue... |
| 12:29 |
sfan5 |
fact is that "all any any client-side features must somehow be disable-able" is not part of our current considerations |
| 12:29 |
sfan5 |
it's more of a long-term goal |
| 12:29 |
hecks |
how about design it right from the start |
| 12:30 |
hecks |
I get that going back and fixing things like camera control is extra work, but that's no reason to take on more debt |
| 12:30 |
hecks |
I'm trying to help, this feature really sucks just for the performance cost alone |
| 12:30 |
sfan5 |
infrastructure to allow the server to properly communicate it's wishes would have to be put into place |
| 12:30 |
sfan5 |
(instead of e.g. tacking onto a random packet) |
| 12:30 |
hecks |
then how does the skybox api work |
| 12:31 |
hecks |
I mean the difference is, I'm not asking that the server should be able to dictate client settings - rather that some things should not be a setting, or should only be gated by one |
| 12:31 |
sfan5 |
skybox is not something the client chooses, it entirely follows the server wishes |
| 12:31 |
hecks |
exactly |
| 12:31 |
hecks |
so why couldn't it have been the case with shadows from day one? |
| 12:31 |
hecks |
that is, the setting should *allow* shadows, not *force* them |
| 12:32 |
hecks |
I mean, since I got my wish last time I should get it now unless my conspiracy theory is true |
| 12:32 |
hecks |
this is no different from forced gouraud shading |
| 12:32 |
sfan5 |
"an optional feature is no different from a forced feature" uh? |
| 12:32 |
hecks |
if I'm not making myself clear enough |
| 12:33 |
hecks |
someone enables shadows and connects to a server |
| 12:33 |
hecks |
and sees this https://a.uguu.se/w7ZL6FF88JUZ_shadowmap.jpg |
| 12:33 |
hecks |
and all I can do is apologize and beg the player to log out, disable shadows and log back in again |
| 12:33 |
hecks |
and perhaps have to manually change this every time they change the server |
| 12:34 |
sfan5 |
I get that |
| 12:34 |
hecks |
so yeah |
| 12:34 |
hecks |
if the PR author is gonna be an ass about it, I'll just make the switch myself but please merge it once that happens |
| 12:35 |
sfan5 |
I believe the main issue here is that most people have different priorities for what's more important for the engine to allow (client choice vs server control), it is certainly not to inconvenience you |
| 12:35 |
hecks |
because, as I wrote in the issue, this breaks existing skybox environment support |
| 12:35 |
hecks |
if you set an overcast skybox, there should be no shadows |
| 12:35 |
hecks |
does it make sense for the engine to allow disabling the hardcoded sun/moon/stars but not this? |
| 12:35 |
sfan5 |
disabling sun shadows is an issue for the skybox API IMO |
| 12:36 |
hecks |
"I just want a global off switch per client, akin to skybox settings." |
| 12:36 |
sfan5 |
related but not identical to letting the server control whether shadows are enabled |
| 12:36 |
hecks |
it's basically identical if you just do this for each player on logon |
| 12:36 |
hecks |
it can be part of the skybox api, that's okay |
| 12:36 |
hecks |
we already have some pretty fine control over the environment; skybox overrides, time of day overrides |
| 12:36 |
hecks |
and this just comes and takes a big hardcoded dump over it |
| 12:37 |
hecks |
it's one packet and one line of code in the player login event, I'll take that cost (but no more) |
| 12:37 |
sfan5 |
it is identical for your usecase because you want shadows gone |
| 12:37 |
sfan5 |
it is not identical if the ingame weather merely changes and you want to turn off the sun but not the rest |
| 12:37 |
hecks |
it covers both cases |
| 12:37 |
hecks |
it at least provides a workaround |
| 12:38 |
hecks |
yes, and I'm aware the other "client configs controls something stupid" issues are not fixed - but they're not as pressing |
| 12:38 |
sfan5 |
<hecks> how about design it right from the start |
| 12:38 |
sfan5 |
here's a quote from you ;) |
| 12:38 |
hecks |
this workaround is also useful so it's fine |
| 12:38 |
sfan5 |
no it's not |
| 12:39 |
sfan5 |
if this is fixed it should be designed properly and not "works for my usecase so it's good enough" |
| 12:39 |
hecks |
ah ffs |
| 12:39 |
hecks |
it works for the usecase of anyone who might have this problem |
| 12:39 |
hecks |
you can even write a disable_shadows mod for a generic drop-in solution |
| 12:40 |
hecks |
you're putting the burden on "doing it right" on me right now rather than on the guy who wrote this PR |
| 12:40 |
hecks |
how about that conspiracy... |
| 12:40 |
hecks |
even disabling it whenever the sun and moon are disabled would suffice |
| 12:40 |
hecks |
as long as all the performance impact were also gone in that case |
| 12:41 |
sfan5 |
if it's not disabled then that sounds like a bug |
| 12:41 |
hecks |
and it wouldn't be one bit wrong, though inflexible |
| 12:41 |
sfan5 |
also no, torches can still cast shadows |
| 12:41 |
hecks |
I thought artificial light isn't counted? |
| 12:41 |
hecks |
or is it separate |
| 12:41 |
sfan5 |
wait you're right |
| 12:41 |
pgimeno |
minimap is similar - the server can disable it, and if enabled, the client can choose whether to enable it. The difference is that in this case the server should send a default, rather than mandate it. |
| 12:41 |
pgimeno |
enforce* it |
| 12:42 |
hecks |
thanks, i forgot about the minimap |
| 12:42 |
sfan5 |
anyway I think we agree that both a way to turn off the sun/moon and turning off shadow mapping entirely would be useful |
| 12:42 |
hecks |
so there's precedent |
| 12:42 |
hecks |
yeah it shouldn't be tied, it's best if it's a separate flag |
| 12:42 |
hecks |
just because there's no good reason to tie it |
| 12:42 |
hecks |
I'll write it if you want, should be an hour's work... will that do? |
| 12:44 |
sfan5 |
dunno |
| 12:45 |
sfan5 |
obvious bugs like "disabling sun and moon does not disable shadows" should be fixed first |
| 12:45 |
pgimeno |
in past, features like shadows were marked 'experimental' |
| 12:45 |
sfan5 |
(assuming that is the case) |
| 12:45 |
pgimeno |
are shadows enabled by default? I haven't updated in a while so I don't know |
| 12:45 |
hecks |
but fixing that implies implementing some kind of tie between sun and shadows |
| 12:46 |
hecks |
and my proposal is just an independent flag |
| 12:46 |
hecks |
almost the same, fixes the issue and offers more freedom |
| 12:47 |
sfan5 |
the current harcoded assumption is that the thing called "sun" emits a lot of light and the thing called "moon" emits a faint amount, so it's already tied |
| 12:47 |
sfan5 |
+d |
| 12:47 |
hecks |
I'm very likely to never actually use the hardcoded sun so this would technically fix my issue too, but I'm, surprise, thinking of others too in this case =] |
| 12:48 |
hecks |
consider: a mod might want to disable sunlight for a player who's verifiably underground and not likely to see any sunlight, just to save performance |
| 12:49 |
sfan5 |
I guess if we wanted to "do it right from the start" there would be an API to specify what kind of light each of the <thing on the sky> (forgot the word) emits |
| 12:49 |
hecks |
and the performance is... awful, this won't make minetest look good |
| 12:49 |
hecks |
oh sure |
| 12:49 |
sfan5 |
...and that doesn't sound too hard actually |
| 12:49 |
hecks |
ideally sun and moon shouldn't be hardcoded |
| 12:49 |
hecks |
but objects that can be added and removed to the skybox |
| 12:49 |
hecks |
and I support this too and I'm willing to do it as a small project |
| 12:49 |
hecks |
a sky layers api, how's that |
| 12:50 |
sfan5 |
mind opening a separate issue and writing the ideas down? |
| 12:50 |
hecks |
sure |
| 13:57 |
hecks |
sfan5: #11366 |
| 13:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/11366 -- Sky layer API |
| 13:57 |
sfan5 |
thanks |
| 14:00 |
|
pmp-p joined #minetest-dev |
| 14:13 |
hecks |
I'd appreciate a quick decision cause I want to fix this one way or the other asap |
| 14:21 |
|
Fixer_ joined #minetest-dev |
| 14:21 |
|
Noisytoot joined #minetest-dev |
| 14:22 |
Krock |
why quick? |
| 14:22 |
hecks |
well, "quick" as in before 5.5 |
| 14:23 |
hecks |
if I have to fix this myself, I'd like to know which way has better chance of getting merged |
| 14:24 |
hecks |
sky API is a bit of extra work but I wanted that anyway, so that's fine... still feels a bit like blackmail though =] |
| 14:33 |
|
Noisytoot joined #minetest-dev |
| 14:38 |
|
kilbith joined #minetest-dev |
| 14:48 |
kilbith |
I was right when I said the shadows PR wasn't mature, but sfan5 is stubborn |
| 14:48 |
kilbith |
and btw hecks I notified you on the PR at its very opening and you didn't react |
| 14:49 |
sfan5 |
it was merged so it can be improved |
| 14:49 |
hecks |
well sorry about that, I don't check mail every day |
| 14:49 |
hecks |
I've been working on my own stuff |
| 14:49 |
hecks |
but doubt anyone would listen, I've voiced my concerns on the forum even before the PR |
| 14:50 |
kilbith |
you're wrong on that |
| 14:50 |
hecks |
as for improving the shadow mapping, do you realize what this implies? |
| 14:51 |
hecks |
you basically need the Great Map Renderer Rewrite™ to fix the performance, something nobody has been able to pull off so far |
| 14:57 |
sfan5 |
that's cool, got any more doomposting? |
| 14:58 |
hecks |
I don't need to doompost, just look at the FPS counter |
| 15:11 |
kilbith |
but hey, now we have got an official roadmap document so the Great Map Renderer Rewrite™ is gonna find its way all of a sudden! /s |
| 15:12 |
hecks |
is stability and performance anywhere on that roadmap? |
| 15:12 |
sfan5 |
try reading it? |
| 15:12 |
kilbith |
I didn't read and I don't care. code talks. |
| 15:12 |
|
T4im joined #minetest-dev |
| 15:12 |
hecks |
tangentially, I've been thinking about the renderer again after learning some more GL |
| 15:13 |
hecks |
and got something nice in mind but with the caveat that it would only work in GL4 |
| 15:14 |
kilbith |
I tried compiling your `batching` branch on your fork but it couldn't go along with IrrlichtMt |
| 15:14 |
hecks |
shucks, it's ancient anyway and I don't like its approach now |
| 15:15 |
hecks |
these days I wouldn't try to merge VBOs into superbatches but maintain one gigantic VBO use the DrawRangeElements family of drawcall functions |
| 15:15 |
hecks |
*and use |
| 15:15 |
hecks |
ideally the king of them all, MultiDrawElementsIndirect |
| 15:16 |
hecks |
this requires you to treat each VBO as a continuous space that you have to memory manage yourself, but ARB_sparse_buffer helps with that |
| 15:17 |
kilbith |
0xLiso is investigating the texture atlases for mapblock meshes but I'm doubtful about it |
| 15:17 |
hecks |
as for atlases, I'd use texture arrays with ARB_sparse_texture to make them easy to manage |
| 15:17 |
hecks |
one texture array per known tile size |
| 15:17 |
kilbith |
I believe on that to a lower VRAM consumption but not really a significant FPS increase |
| 15:18 |
hecks |
the FPS increase comes from reduced chatter to the driver, so atlases can help by making batching easier |
| 15:18 |
|
ivanbu joined #minetest-dev |
| 15:19 |
hecks |
in the extreme case, with MDEI and sparse arrays, you can draw all opaque nodes of a given drawtype in one call |
| 15:19 |
hecks |
other ideas; one vertex per node, use GS to reconstruct anything that can be reconstructed (node, nodebox, plant, fire, simple meshes) |
| 15:19 |
hecks |
autogenerate GS emitters for really simple mesh nodes |
| 15:20 |
|
T4im joined #minetest-dev |
| 15:20 |
hecks |
draw complicated mesh nodes as individual models, instance them |
| 15:20 |
hecks |
use 3D texture lightmaps to light things |
| 15:20 |
hecks |
possibly one big sparse light texture for all that is visible |
| 15:21 |
hecks |
and finally, compute shader for culling the MDI command buffers |
| 15:22 |
hecks |
this would all be extremely fast, but not very backwards compatible |
| 15:22 |
hecks |
partial compatibility with GL3 can be achieved as long as GS is available, by emulating MDI in software and issuing DrawRangeElements calls |
| 15:22 |
hecks |
also, restricting chatter with OpenGL to one burst of commands seems to improve things from what I've tested |
| 15:23 |
hecks |
so a software command buffer is worth it either way |
| 15:26 |
hecks |
actually, with minimal changes MDI could be utilized for batching as it is, with the VBO manager being the only problem to solve |
| 15:27 |
hecks |
and this can be possibly done in the irrlicht fork as a drop-in measure |
| 15:28 |
hecks |
not gonna happen until I'm shadow-free though... business is business =] |
| 15:47 |
hecks |
wow how come there is no shadow bias setting |
| 15:50 |
|
v-rob joined #minetest-dev |
| 16:07 |
|
nrz joined #minetest-dev |
| 16:12 |
|
T^4im joined #minetest-dev |
| 16:14 |
|
T4im joined #minetest-dev |
| 16:33 |
|
kilbith joined #minetest-dev |
| 16:48 |
|
Extex joined #minetest-dev |
| 16:57 |
|
kilbith_ joined #minetest-dev |
| 17:06 |
|
behalebabo joined #minetest-dev |
| 17:10 |
|
entuland joined #minetest-dev |
| 17:15 |
|
entuland joined #minetest-dev |
| 17:25 |
|
T4im joined #minetest-dev |
| 17:26 |
|
entuland joined #minetest-dev |
| 17:31 |
|
kilbith joined #minetest-dev |
| 17:41 |
|
Liso joined #minetest-dev |
| 17:56 |
|
MTDiscord joined #minetest-dev |
| 17:58 |
MTDiscord |
<Jonathon> It is libera |
| 17:58 |
MTDiscord |
<GreenXenith> (Bridge crashed, restarted) |
| 17:59 |
MTDiscord |
<Liso> ok |
| 18:25 |
Liso |
Hi. I just read the log and PR #11365. And I'm going to write down some thoughts. |
| 18:25 |
Liso |
I'm not here to have a fight, or problems. I just tried to make some contributions. But since the beginning this guy started to threaten: |
| 18:25 |
Liso |
https://forum.minetest.net/viewtopic.php?p=385437#p385437 |
| 18:25 |
Liso |
As I said at that time, I have already dealt with this kind of people. He's going to try to annoy as much as possible, even with personal attacks, until he gets what he wants, and as soon as someone reply him he's going to act offended. |
| 18:25 |
Liso |
He already made it quite clear that he didn't want shadow mapping MT, but a lot of other people did want this feature. |
| 18:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/11365 -- Shadowmaps can not be disabled by the server |
| 18:25 |
Liso |
So I implemented it, but there is no obligation to merge in MT at all. |
| 18:25 |
Liso |
I would have more to say, but I have already commented that I am not going to get into any kind of fight. And NO, I'm not going to be any ass, And for sure I'm NOT going to threaten to not develop any other stuff if there is something I don't like. |
| 18:26 |
hecks |
hi liso |
| 18:26 |
hecks |
want to debug the shadow acne issues? |
| 18:27 |
hecks |
oh, guess not |
| 18:28 |
MTDiscord |
<Liso> yes, sure. I already play with nvida nsight , but I have a lack of knowledge in shaders and 3d graphics to get how fix it properly. Also the map vs entities biases are not the same |
| 18:31 |
Liso |
for example, slope scaled depth bias work quite well with map, but it fails a lot with entities. Also there are some enttities don't have normal linke PLANTLIKE |
| 18:31 |
hecks |
there's some issues with decals and onion layered meshes |
| 18:31 |
hecks |
and 2e-5 is a suspiciously small bias, is that really okay? is there some scale thing here I'm not aware of? |
| 18:32 |
hecks |
cause all the time I've dealt with shadow mapping, a safe bias was more in the range of 5mm to 1cm |
| 18:32 |
MTDiscord |
<Liso> it's a bias to avoid precission issues. |
| 18:32 |
hecks |
and that was in engines with metric scale, while minetest I think is upscaled 10x on top of that |
| 18:32 |
MTDiscord |
<Liso> but I think i have completly wrong all the shadow mapping in the fragments. I tried to optimize too soon |
| 18:36 |
MTDiscord |
<Liso> the world -> light space position in the vertex shader, that could work with a linear transformation, but we must use this non-linear distortion in shadows, so we have to do the NDC->World->light space transformation in pixel shader. and to do that we need the invert MVP matrix :/ I already did that but I remove it. My fault. |
| 18:37 |
hecks |
here's what it looks like https://a.uguu.se/U5kuh6qDIJ5x_aaaaaa.jpg |
| 18:38 |
hecks |
put yourself in my shoes man... every time I take a break and then update the engine, I come back to stuff like this |
| 18:38 |
MTDiscord |
<Liso> self shadowing isn't it?? |
| 18:39 |
hecks |
anyway I'd investigate the bias and maybe alpha test mip issues, no shadow mapper I've seen has had these artifacts so I'm not entirely sure what's doing it |
| 18:40 |
MTDiscord |
<Liso> Yes, but 5.5 is still in development. I know it's very annoying to get those glitches just for an update, but when it works fine you are going to have a crazy good looking game |
| 18:40 |
|
Evergreen joined #minetest-dev |
| 18:41 |
MTDiscord |
<Liso> btw, IDK why I'm writing from discord and irc at the same time ? |
| 18:44 |
Liso |
Hecks, I asked a friend that works in videogames, and he told me the best option to avoid all shadow glitches is "Shadow Normal Offset Bias" technique |
| 18:44 |
Liso |
https://user-images.githubusercontent.com/7088062/36948961-df37690e-1fea-11e8-8999-af8af60403fb.png |
| 18:44 |
hecks |
With all due respect to your friend, it isn't |
| 18:45 |
hecks |
Sometimes a linear bias is better |
| 18:45 |
hecks |
the thing with normal offset is that the shadow necessarily looks emaciated, and it breaks whenever there is a seam in the mesh |
| 18:46 |
hecks |
anything with hard edges will actually fall apart into islands unless it has a separate normal set just for the normal bias - but even then it might not be satisfactory |
| 18:47 |
hecks |
so that's a bit of an ugly hack, I also work in videogames and I prefer a small linear bias around 1cm, and then raymarched contact shadows for the final stretch |
| 18:47 |
hecks |
check out Blender's Eevee renderer for a demo of that approach |
| 18:48 |
Liso |
I can't argue that, I don't have enough knowledge about the subject. If someone can implement a better way to get the bias, I'll be really grateful :) |
| 18:49 |
hecks |
well a linear bias is easier, it's just comparing the distance to a different number |
| 18:49 |
hecks |
is normal offset what you did in your implementation? |
| 18:49 |
MTDiscord |
<Liso> and also the sun angle, it breaks a lot on smalls angles |
| 18:50 |
hecks |
like what's the 2e-5 number, is it an epsilon and not a bias? |
| 18:50 |
Liso |
yes |
| 18:50 |
hecks |
alright then, well, that's where you put linear bias |
| 18:50 |
hecks |
anyway the uh |
| 18:51 |
Liso |
maybe it could be done in the shadow pass |
| 18:51 |
hecks |
yeah you can do linear bias in the shadow pass by pushing the Z a bit |
| 18:52 |
Liso |
I'm doing all kind of experiments in a "dev" branch. |
| 18:52 |
hecks |
what changes would I have to make to the shader to get a "naive" implementation? |
| 18:52 |
Liso |
I promise you I'm going to try that as soon as I can |
| 18:52 |
hecks |
just a hard shadow with no bias |
| 18:52 |
Liso |
without PSM? |
| 18:53 |
hecks |
no PCF no nothing |
| 18:53 |
hecks |
just a hard shadow |
| 18:53 |
MTDiscord |
<exe_virus> for the record, liso, you are coming along quite nicely as a graphics pipeline person, just don't get burned out, we need more of you in MT haha |
| 18:54 |
Liso |
XD, tnx :) |
| 18:55 |
hecks |
I just want to know what's causing those weird splotches on layered models |
| 18:55 |
Liso |
hecks, change getShadow -> getHardShadow I think |
| 18:55 |
specing |
OpenGL in CSMs, when? :P |
| 18:55 |
specing |
(or vulkan) |
| 18:55 |
Liso |
CSM? |
| 18:55 |
specing |
client side mods |
| 18:55 |
MTDiscord |
<exe_virus> no vulkan, please not yet |
| 18:55 |
|
jonadab joined #minetest-dev |
| 18:55 |
Liso |
oh, lol |
| 18:56 |
MTDiscord |
<exe_virus> that'll kill our old computer and phone support which IMO is half our playerbase |
| 18:56 |
specing |
MT already doesen't work on my old computers, so that's not an issue |
| 18:56 |
MTDiscord |
<exe_virus> ? what are you running? it runs on my old '98 PC |
| 18:57 |
MTDiscord |
<exe_virus> it has a 5 GB hard drive.... |
| 18:57 |
specing |
half of players are stuck on <5.0, aren't they? |
| 18:57 |
MTDiscord |
<exe_virus> that's the other half ? |
| 18:57 |
specing |
2008 laptop (thinkpad) |
| 18:57 |
specing |
Lol |
| 18:57 |
MTDiscord |
<exe_virus> I also have a 2010 thinkpad, whats the issue? |
| 18:57 |
hecks |
hm, this still doesn't make a hard shadow |
| 18:57 |
specing |
Idk, I think it was the mega slowness |
| 18:57 |
MTDiscord |
<exe_virus> what game? |
| 18:58 |
Liso |
no? |
| 18:58 |
hecks |
there's a bunch of hard shadows layered on top of one another, that's the poisson disk? |
| 18:58 |
Liso |
no, the poisson is done in the getshadow |
| 18:59 |
hecks |
I see this https://a.uguu.se/XAtwDlBZdBpI_shadow.jpg |
| 19:00 |
Liso |
heck change dynamicshadowrender.cpp line 266 #if 0 -> #if 1 to see the shadow texture debug |
| 19:00 |
hecks |
it's even got this weird filtering depending on the receiver's height |
| 19:00 |
Liso |
and increase the shadow strength to .4 to really see the shadow |
| 19:00 |
hecks |
can't you just tell me what I'm looking at? |
| 19:01 |
hecks |
https://a.uguu.se/1or58Om51Flr_layered.jpg |
| 19:01 |
Liso |
:? |
| 19:01 |
Liso |
with hard shadow? |
| 19:01 |
hecks |
yeah |
| 19:02 |
hecks |
this is what I'd expect to see if I copied a directional light a few times and nudged the angle each time |
| 19:04 |
MTDiscord |
<Liso> https://cdn.discordapp.com/attachments/747163566800633906/855885872833495070/unknown.png |
| 19:05 |
|
kilbith joined #minetest-dev |
| 19:05 |
specing |
It would also be nice if the minetest CSM api was somewhat compatible with the SpringRTS one |
| 19:06 |
MTDiscord |
<Liso> heck |
| 19:06 |
MTDiscord |
<Liso> https://cdn.discordapp.com/attachments/747163566800633906/855886227785121862/unknown.png |
| 19:06 |
specing |
https://springrts.com/wiki/Lua_OpenGL_Api |
| 19:07 |
hecks |
that's a strange thing to want in an API |
| 19:07 |
MTDiscord |
<Liso> agreed xD |
| 19:07 |
specing |
Why? |
| 19:08 |
hecks |
you usually want a good API =] also, for GL APIs it's best if they're as close to raw GL as possible |
| 19:09 |
specing |
IDK how a raw GL api looks like, but is springrts's not close? |
| 19:09 |
MTDiscord |
<Liso> also you are going to mix raw gl draw with irrlicht pipeline... IDK how that could work |
| 19:09 |
hecks |
it seems a little modified |
| 19:09 |
hecks |
it's also ancient as far as GL goes |
| 19:10 |
specing |
Spring also has the "that'll kill our old computer and phone support which IMO is half our playerbase " problem |
| 19:10 |
hecks |
these days gl looks more like; GenBuffers, GenArrays, VertexArrayVertexBuffer, BindVertexArray, DrawElements, etc. |
| 19:10 |
hecks |
VBOs are supported by damn near anything |
| 19:11 |
hecks |
it's a very old extension |
| 19:11 |
hecks |
even minetest primarily relies on DrawArrays |
| 19:11 |
specing |
And Spring-in-devel also has a graphics makeover, it will require GL 4.5 or so |
| 19:11 |
hecks |
that's what we need too |
| 19:12 |
MTDiscord |
<Liso> ogl3 will give us texture arrays ? |
| 19:13 |
specing |
In any case, I wanted to bring up this to ensure that these two engines become somewhat close in the modding sense |
| 19:13 |
specing |
means less work for spring modders to develop for mt and vice versa |
| 19:18 |
hecks |
so liso, what exactly are you doing that causes those duplicate shadows, are you actually rendering the shadow multiple times? |
| 19:18 |
hecks |
it would explain the ungodly fillrate hit |
| 19:18 |
Liso |
No, once per frame |
| 19:19 |
Liso |
maybe the front culling is making funny things? |
| 19:20 |
hecks |
to produce this? doubt it, it literally looks like multiple shadows |
| 19:20 |
hecks |
or rather multiple lights |
| 19:20 |
hecks |
it affects everything |
| 19:21 |
MTDiscord |
<GreenXenith> Looks like blurring to me |
| 19:21 |
hecks |
can I get the code line where you start the shadow pass? |
| 19:22 |
Liso |
IDK, do you change the "hardshadow" in both nodes and objects fragment ?? |
| 19:22 |
hecks |
oh right, nodes. stupid me |
| 19:23 |
hecks |
that's more like it... now |
| 19:23 |
hecks |
you've been saying that you use normal offset |
| 19:24 |
hecks |
ok this is... oh no |
| 19:24 |
Liso |
yes, at the nodes vertex sahder, line 85 and more |
| 19:24 |
hecks |
actually it's just like #9985 |
| 19:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/9985 -- Black patches on models, bad shading |
| 19:25 |
hecks |
now let me check if my models actually have normals in the first place |
| 19:25 |
hecks |
I might be stripping them due to not using shading |
| 19:25 |
hecks |
yup, that is the case |
| 19:26 |
hecks |
so this was never fixed apparently, if an .x scene has no normals then MT will use garbage data in their place |
| 19:27 |
hecks |
there's still some insanity though even without normal bias |
| 19:27 |
hecks |
https://a.uguu.se/VX5JXTKpYpbc_wut.jpg |
| 19:27 |
hecks |
like why does one eye and the hair just refuse to shade? |
| 19:28 |
MTDiscord |
<Liso> really?!?!?!? |
| 19:28 |
MTDiscord |
<GreenXenith> btw, the "duplicate shadow" thing is shadow radius https://github.com/minetest/minetest/blob/c47313db65f968559711ac1b505ef341a9872017/client/shaders/object_shader/opengl_fragment.glsl#L300-L318 with 0 shadow filter |
| 19:29 |
MTDiscord |
<Liso> you just make my nnight, heck!! I spent last week trying to fix the bias for the entities, and now If the have garbage in the normals that will help me a lot |
| 19:32 |
MTDiscord |
<Liso> ups that's a big bug, with PCFBOUND to 0 it will fail miserably |
| 19:33 |
MTDiscord |
<Liso> nice catch GreenXenith ? |
| 19:34 |
hecks |
so this is what we're looking like without the bugs https://a.uguu.se/1w8cLGTU6oAG_Clipboard01.jpg |
| 19:35 |
hecks |
bit better than the gouraud shading nonsense but I still hate it |
| 19:35 |
MTDiscord |
<GreenXenith> is that with normals? yeah flat shading is way better |
| 19:37 |
Liso |
hard shadows and .4 strength ?? try it with .2 strength and poisson at 2 |
| 19:37 |
hecks |
it's changed back to soft but sure |
| 19:41 |
Liso |
I have to go dinner, I'll read you later. |
| 19:45 |
|
kilbith joined #minetest-dev |
| 19:50 |
sfan5 |
shouldn't #10000 have eliminated the issue with normals? |
| 19:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/10000 -- Recalc mesh normals for CAOs by dcbrwn |
| 19:50 |
hecks |
sadly I don't think the .x importer is handling it right so MT can't detect it in that case |
| 19:50 |
hecks |
this can be now fixed in the fork |
| 19:50 |
sfan5 |
yeah was about to say |
| 19:51 |
sfan5 |
we can just fix it directly :) |
| 19:51 |
hecks |
by simply not providing junk data |
| 19:51 |
hecks |
https://a.uguu.se/yGlinOWI0raN_meh.jpg all things considered this looks very meh for the cost |
| 19:52 |
hecks |
most of the time it just makes the mesh darker |
| 19:52 |
hecks |
and does that by simply multiplying by a shade of gray which makes things look dirty |
| 19:53 |
hecks |
also it unduly hardens the mesh topology where the latter attempts to approximate a curved surface |
| 19:54 |
hecks |
https://a.uguu.se/eTpuc7dQIQmH_edges.jpg |
| 19:54 |
hecks |
perf is almost acceptable *if* PCF is completely disabled on nodes, that's causing the worst of the lag |
| 19:56 |
hecks |
https://a.uguu.se/GVVyvZmwvRbI_hard.jpg overall better with purely hard shadows but |
| 19:56 |
hecks |
there isn't enough resolution to make that work, which seems weird, cascaded shadow maps should be able to handle that, I hope this is cascaded? |
| 20:01 |
|
specing_ joined #minetest-dev |
| 20:12 |
|
behalebabo joined #minetest-dev |
| 20:13 |
MTDiscord |
<exe_virus> likely we need some sort of post shadow effect that not only brightens but also increases saturation |
| 20:17 |
|
Liso joined #minetest-dev |
| 20:18 |
|
YuGiOhJCJ joined #minetest-dev |
| 20:20 |
MTDiscord |
<Liso> no, it's not cascaded hecks. To do cascade ( my first attempt) we have to render the map 3 extra times, instead of 1. and that kills the perf much more. So now we use PSM, also called LSPSM. to increase the texel density near the camera. |
| 20:25 |
sfan5 |
okay garbage normals fixed in irrlichtmt |
| 20:25 |
sfan5 |
hardest part was installing an older version of blender that can still export .x |
| 20:26 |
hecks |
oh right... i made a port of that plugin but i guess you don't need it now |
| 20:26 |
MTDiscord |
<exe_virus> 1. We do need a 2.8 .x plugin |
| 20:26 |
MTDiscord |
<exe_virus> 2. We need something like gltf support haha |
| 20:31 |
MTDiscord |
<Jonathon> hecks: would you mind sharing it anyways? |
| 20:33 |
|
Extex joined #minetest-dev |
| 20:39 |
hecks |
just for fun; this is how shadows actually ought to look like https://a.uguu.se/wnDTTlYwIOr5_shadows.jpg |
| 20:40 |
hecks |
anything that isn't in the shadow gets the value of the light, and anything that's shadowed gets the node light value (kinda biased) |
| 20:40 |
hecks |
https://a.uguu.se/ILTuLBiZvgwu_shadow2.jpg |
| 20:41 |
hecks |
however this only works when time is 12:00 |
| 20:42 |
MTDiscord |
<Liso> so, probably we can adapt the shadow frustum with the sun angle to make it work better |
| 20:46 |
hecks |
https://a.uguu.se/h8SKzcn0c7iy_bounce.jpg basically the only legitimate way to mix a dynamic light with node light is to use the latter as GI |
| 20:50 |
Liso |
btw,if anyone know how to fix the darkness of the wielditems with shadows please tell me |
| 21:46 |
|
Noisytoot joined #minetest-dev |
| 21:48 |
|
kilbith joined #minetest-dev |
| 21:48 |
hecks |
https://a.uguu.se/hXIVj8HoyXM1_bleh.jpg so yeah uh |
| 21:48 |
hecks |
despite my best efforts I just don't see this working |
| 21:48 |
hecks |
bad angles are the rule rather than exception https://a.uguu.se/oTsulIEuqlot_wtf.jpg |
| 23:05 |
|
Alias2 joined #minetest-dev |
| 23:35 |
|
rubenwardy joined #minetest-dev |
| 23:36 |
|
rubenwardy joined #minetest-dev |
