Minetest logo

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

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

All times shown according to UTC.

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

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