Time Nick Message 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 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: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: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 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! 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 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 (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:13 hecks I'd appreciate a quick decision cause I want to fix this one way or the other asap 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: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 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: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 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 17:58 MTDiscord It is libera 17:58 MTDiscord (Bridge crashed, restarted) 17:59 MTDiscord 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 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 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 but I think i have completly wrong all the shadow mapping in the fragments. I tried to optimize too soon 18:36 MTDiscord 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 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 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:41 MTDiscord 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 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 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 no vulkan, please not yet 18:55 Liso oh, lol 18:56 MTDiscord 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 ? what are you running? it runs on my old '98 PC 18:57 MTDiscord it has a 5 GB hard drive.... 18:57 specing half of players are stuck on <5.0, aren't they? 18:57 MTDiscord that's the other half ? 18:57 specing 2008 laptop (thinkpad) 18:57 specing Lol 18:57 MTDiscord 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 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 https://cdn.discordapp.com/attachments/747163566800633906/855885872833495070/unknown.png 19:05 specing It would also be nice if the minetest CSM api was somewhat compatible with the SpringRTS one 19:06 MTDiscord heck 19:06 MTDiscord 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 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 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 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 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 really?!?!?!? 19:28 MTDiscord 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 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 ups that's a big bug, with PCFBOUND to 0 it will fail miserably 19:33 MTDiscord 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 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: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:13 MTDiscord likely we need some sort of post shadow effect that not only brightens but also increases saturation 20:20 MTDiscord 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 1. We do need a 2.8 .x plugin 20:26 MTDiscord 2. We need something like gltf support haha 20:31 MTDiscord hecks: would you mind sharing it anyways? 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 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: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