Minetest logo

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

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

All times shown according to UTC.

Time Nick Message
01:15 v_rob joined #minetest-dev
03:00 specing_ joined #minetest-dev
04:20 v_rob joined #minetest-dev
05:45 v_rob joined #minetest-dev
06:31 Wuzzy joined #minetest-dev
06:50 olliy joined #minetest-dev
07:54 lhofhansl joined #minetest-dev
07:54 lhofhansl Planning to merge #11422 in the next hour.
07:54 ShadowBot https://github.com/minetest/minetest/issues/11422 -- Distribute shadow map update over multiple frames to reduce stutter by x2048
08:45 tech_exorcist joined #minetest-dev
09:08 Kimapr0 joined #minetest-dev
09:17 calcul0n__ joined #minetest-dev
09:24 entuland joined #minetest-dev
10:21 Kimapr joined #minetest-dev
10:23 sfan5 thats one long hour
10:24 Krock because he left before merge
10:25 Krock anyway. will merge #11422 and #11479 in 10 minutes
10:25 ShadowBot https://github.com/minetest/minetest/issues/11422 -- Distribute shadow map update over multiple frames to reduce stutter by x2048
10:25 ShadowBot https://github.com/minetest/minetest/issues/11479 -- Document glasslikeliquidlevel merge bits by random-geek
10:25 Krock #11430 too
10:25 ShadowBot https://github.com/minetest/minetest/issues/11430 -- Add smooth light-shadow transition at noon by x2048
10:27 YuGiOhJCJ joined #minetest-dev
10:32 lhofhansl joined #minetest-dev
10:34 Krock merging
10:34 lhofhansl Back now. Happy to do it. But don't mind if you do.
10:35 lhofhansl I'll sit back :)
10:36 Krock done
10:39 lhofhansl1 joined #minetest-dev
10:39 lhofhansl1 Now we can work on the remaining changes in 0xLiso's PSM branch.
10:40 lhofhansl joined #minetest-dev
10:46 Fixer joined #minetest-dev
10:47 Krock btw, is x2048 == 0xLiso ?
10:49 MTDiscord <Jonathon> No
11:02 YuGiOhJCJ joined #minetest-dev
12:12 hecks joined #minetest-dev
12:44 hecks left #minetest-dev
12:45 MTDiscord <Sublayer plank> I get random crashes now with the "delete unused features" irrlicht PR merged. the window freezes, the mouse is freed, and the windows remains frozen until it closes after a minute or so
12:58 sfan5 when did you last pull a new version of irrlicht?
13:00 MTDiscord <Sublayer plank> right around the time the PR was merged
13:00 MTDiscord <Sublayer plank> seems to be something to do with the smoke puff particles?
13:01 MTDiscord <Sublayer plank> https://cdn.discordapp.com/attachments/747163566800633906/868840360951025684/unknown.png
13:01 sfan5 try pulling again then
13:08 MTDiscord <Kimapr> +
13:08 calcul0n_ joined #minetest-dev
13:08 MTDiscord <Kimapr> oops, cat on keyboard
13:22 MTDiscord <Sublayer plank> oh whoops, it got fixed with ae81dbd in irrlicht which I hadn't pulled :|
14:59 specing_ joined #minetest-dev
15:43 sfan5 ~tell v-rob since you approved the original PR you might want to review #11478
15:43 ShadowBot sfan5: OK.
15:48 Extex joined #minetest-dev
15:48 tech_exorcist joined #minetest-dev
16:47 Sokomine sadly having problems running latest git: WARNING[Main]: Irrlicht: Warning: The liary version of the Irrlicht Engine (1.9.0mt3) does not match the version the application was compiled with (1.9.0mt2). This may cause problems.
16:48 Sokomine are any changes of compile parameters required? currently i'm using cmake . -DIRRLICHT_LIBRARY=/usr/local/lib/libIrrlichtMt.so.1.9 -DIRRLICHT_INCLUDE_DIR=/usr/local/include/irrlichtmt -DRUN_IN_PLACE=1 -DENABLE_GETTEXT=1 -DENABLE_FREETYPE=1 -DENABLE_LEVELDB=1 -DENABLE_POSTGRESQL=0
16:48 sfan5 make clean, then try building again
16:48 Sokomine thanks
16:49 Pexin you're using shared lib?
16:50 Sokomine there have been some changes recently regarding irrlicht...i'm not entirely sure if i'm up to date. just tell me what's the recommended way right now, please :-)
16:51 Sokomine first, it was a clone of irrlicht, then irrlichtmt - not sure what's current. i've been a bit busy with trying to teach npc to talk rpg-like (and players beeing able to program them - which is quite some work)
16:52 MTDiscord <Sublayer plank> the least painful option would probably be cloning irrlichtmt into the lib/irrlichtmt directory from the root of the minetest repo and then it should automatically compile irrlichtmt along with minetest
16:53 Sokomine oh. i currently have irrlichtmt in a folder on the same directory level as the minetest sources
16:53 MTDiscord <Sublayer plank> yeah as of a couple of commits ago it can automatically compile irrlicht along with minetest if it's put in the lib/irrlichtmt directory
16:53 Sokomine neat!
16:54 MTDiscord <Sublayer plank> commit fa4dee0 to be more exact
16:54 MTDiscord <Sublayer plank> also irrlicht/irrlichtmt is used interchangebly now, but it almost always refers to new minetest forked irrlicht version
16:54 Sokomine but it's still https://github.com/minetest/irrlicht    ?
16:55 MTDiscord <Sublayer plank> yeah it's a bit irregular
16:55 Sokomine yes, i want the most current version, even though that makes no point on my hardware and i'll most likely have to disable any graphical effects made for not 8-year-old-igps
16:56 Sokomine there's seldom a perfect way to do things. i'm glad that the development proceeds
16:57 Pexin if things keep as they are going, i get the impression in a month irrmt will be ready to finally die completely
16:57 MTDiscord <Sublayer plank> if you're on old hardware I think you'd be glad to hear hecks went through and removed a lot of unused stuff from irrlicht that minetest doesn't use so now it's super fast when compiling. no in-game performance difference though
16:58 Sokomine oh? what will happen then? i did get a bit out of sync. had less time + the npc are really demanding
16:58 MTDiscord <Sublayer plank> irrlichtmt would get absorbed into the minetest codebase
16:58 MTDiscord <Sublayer plank> although... is irrlichtmt ever going to be absorbed into minetest? I thought that wasn't the case and it would always stay separate
16:59 sfan5 hard to say, I don't think we'll reach that point soon
17:02 Sokomine ok. compiling now without the -DIRRLICHT_* parameters and the lib cleanly cloned into the lib/ folder
17:20 entuland joined #minetest-dev
17:38 olliy joined #minetest-dev
17:40 Sokomine compiled nicely now
17:53 Sokomine oh! the shadows look great! of course my hardware can't really handle it - even on lowest setting may be too much. but that is as expected. it is old hardware that was never really good for gaming
17:55 Sokomine are there any reports on how more modern igps can handle the shadows? like a ryzen?
17:59 Pexin Sokomine: from what i recall, max settings don't run very well on anything, but medium are fine on low to mid end HW. i havent tried myself
18:00 Pexin i run with no shadows and a very large view distance
18:04 Sokomine hm. dedicated graphic cards are usually much stronger than igps, even today (i think?) - or require tuning settings down. but to have some of these shadows in the future, on future hardware (again, without dedicated graphics card) would be something nice to look forward to :-)
18:38 Kimapr joined #minetest-dev
19:20 Fixer joined #minetest-dev
19:46 hecks joined #minetest-dev
19:47 hecks sfan5 i cleaned up the encoder
19:49 sfan5 I'll test it hopefully later
19:49 hecks it works, trust me... im a dolphin
19:51 MTDiscord <Jonathon> nice to see #11130 getting some attention 👍
19:51 ShadowBot https://github.com/minetest/minetest/issues/11130 -- Fix rendering of allfaces nodes with transparent textures by x2048
19:55 hecks we could use something like a todo list for things caught while reviewing a PR but deferred for later
19:56 hecks and any other known obvious optimizations that just need someone to get around and write them
19:58 rubenwardy issues, with milestones/projects
19:58 rubenwardy milestones if you want to fix before release
19:59 hecks we need a performance project then
19:59 hecks to act as this to-do list, because i can think of a few things to optimize
20:00 hecks there's the statbar thing that nobody ended up doing, there's particles, and now 11130 has an obvious optimization in the form of index reordering
20:00 tech_exorcist joined #minetest-dev
20:00 hecks which i don't want to require the author to do right now, but i'd like to note it somewhere
20:01 lhofhansl joined #minetest-dev
20:02 lhofhansl Was there a discussion I missed re: #11470? Are we to control all visual features from  the server with no control on the client?
20:02 ShadowBot https://github.com/minetest/minetest/issues/11470 -- Multipass shadow mapping by Andrey2470T
20:02 hecks you missed an IRC discussion on it
20:02 hecks which is when and how i became a coredev
20:03 hecks i need to get around to actually PRing a change to contributing.md to codify this
20:03 lhofhansl OK... I disagree. Things like (say) reflective water have nothing to do with gameplay. Shadow are border line, since they would destroy rain, etc.
20:04 lhofhansl Anyway.
20:04 hecks we basically have a gamedev lobby now in the dev team ¯\_(ツ)_/¯
20:04 hecks reflections are a problem too
20:04 hecks in general adding hardcoded effects like that is much inferior to working towards shader APIs
20:05 hecks https://a.uguu.se/Bnl2EXWX7ccs_water.gif don't tell me you'd slap a reflection on this and expect it to work
20:06 hecks as for shadows breaking particles, that's literally a bug
20:06 hecks there should be a flag whether something should cast a shadow, because some things (like flames) should never ever do that
20:07 hecks i'm rewriting the renderer to make changes like this less destructive, so maybe hold off on things like that
20:07 hecks especially because implementing something like point lights right now will be 10x more code and tech debt than it will be later
20:07 hecks this should've been done before the directional shadows, but nobody was willing to do it
20:10 hecks and ultimately the lack of ca. 2003 quality uncanny valley lighting is not the reason we can't draw users to this thing...
20:11 hecks on the contrary, if they try out the game only to find out it looks like shovelware and runs at 10 fps, i don't think they'll stick around for very long
20:12 hecks at the very least we should not prevent anyone skilled from making this thing look good, and this would kind of do that
20:13 MTDiscord <Warr1024> If I cared that much about beautiful visuals I'd be playing AAA titles instead of open-source or indie stuff.  Please, give me something that's conceptually exciting, and in exchange I'll put in the effort that it takes to overlook superficial flaws.
20:13 hecks i'm not sure if you're agreeing or disagreeing
20:13 MTDiscord <Warr1024> It makes sense to try to do something about our weaknesses, but only so long as we continue to play to our strengths too.
20:14 MTDiscord <Warr1024> Mostly agreeing, I think?
20:14 hecks i guess
20:14 hecks basically we're fine without lathering all this shiny crap on top, we don't even need it
20:14 lhofhansl I agree with that. I'll watch this. (And maybe it's time for me to take a hiatus - I have only been small things in the past month anyway)
20:15 MTDiscord <Warr1024> I mostly agree that pure visual sparkly stuff is probably not what we need the most right now.  Granted, though, there's still the story of the Cool Cam to remind me that maybe it's not so bad, either.  https://thedailywtf.com/articles/The-Cool-Cam
20:15 lhofhansl past many months that is
20:16 MTDiscord <Warr1024> If people really want to work in sparkle and polish, I guess that's fine, so long as it doesn't interfere with the critical stuff...
20:16 lhofhansl bye for now...
20:16 hecks we just shouldn't be taking on tech debt for it
20:17 hecks these implementations are usually poor quality too, and we have a big conceptual problem
20:17 MTDiscord <Warr1024> Heh, well, on the other hand, it seems like we recently brought on this new core dev who's been providing a windfall of massive debt-cancelation payments ... :-D
20:17 hecks where minetest already has a decent lighting system and these just clash with it
20:18 hecks yes but my price is that nothing as stupid as liso's directional lights ever gets merged again
20:18 hecks i'm only doing this because it's the only way to clean that up
20:18 MTDiscord <Warr1024> Yeah, all the proposed fancy realistic light stuff conflicts with the way light levels are defined in gameplay...
20:18 hecks i looked at the possible ways to do a quick and dirty fix to disable shadows remotely and all of them were terrible because we do not have variant switching
20:19 hecks fast forward i'm rewriting IVideoDriver...
20:19 hecks and catching some WTFs in the process - did you know that the selection cursor box literally remakes the box mesh every frame?
20:19 MTDiscord <GreenXenith> Shadows honestly feels like something that shouldnt be added until implemented correctly. Sure many features should just be added and improved upon, but that really shouldnt be the case with shadows, or a lot of graphics in general
20:19 hecks same for all the immediate drawing functions of IVideoDriver
20:20 hecks the crosshair becomes two drawLine calls which then becomes two meshes being created and uploaded
20:20 hecks this is why the hud is so awfully slow
20:20 hecks shadows would look cool if our voxel GI actually worked with them, not against
20:20 hecks but that isn't going to happen without serious restructuring
20:20 MTDiscord <Warr1024> Shadows weren't so bad that they shouldn't have been merged at all, but we do probably need to think about at least some kind of creator configuration options much earlier in the process, instead of handing end-users a footgun and then only afterwards thinking about whether game-makers need a way to help them.
20:21 hecks i just don't want to have to beg the user to use the right settings, that should never happen
20:21 hecks that's a total UX failure
20:21 MTDiscord <Warr1024> Yeah, that's really a big fundamental problem with MT right now.
20:21 MTDiscord <Warr1024> Users should have overriding control, but creators should be able to set defaults.
20:22 hecks we have problems with unreasonable expectations towards game developers, it's seriously hard to make something good in MT and it's becoming even harder
20:22 hecks the other day I got yelled at for using fixed forms... when it's actually the only way I could make anything good in these
20:23 hecks imagine just *not knowing* the rendering environment you're making something for
20:23 hecks that's some battered wife stuff
20:23 hecks you'll go insane trying to make some sense of it
20:23 hecks and then imagine probing the engine to see what you're standing on, only for the rules to change the next month
20:24 MTDiscord <Warr1024> It's a tad maddening trying to support a wide variety of users and devices, while not being able to know anything about them and their configuration and having to rely on the engine to figure it out for me, but the engine can't be arsed much of the time to actually consider more complex uses of features beyond what vanilla MTG would do.
20:24 MTDiscord <Warr1024> Haha, oh, right, the minetest.get_node(player:get_pos()) thing ... I think I'm probably still not 100% done dealing with the fallout from that one.
20:25 hecks at risk of sounding like a buffoon, I think I managed to wrangle the engine quite nicely and my workflow could be a litmus test for what's reasonable
20:25 MTDiscord <Warr1024> er, I think vector.round might actually be necessary to be explicitly in there, I can't remember...
20:26 MTDiscord <Warr1024> Granted, that was a case where there were 2 wrong answers to pick from and the engine switched from one wrong answer to another wrong answer.
20:27 MTDiscord <Warr1024> Yeah, as I understand, you've beaten the shit out of the entity system, while I've mostly smashed my skull against nodes and node behavior.
20:30 sfan5 hecks: [IVideoDriver] are you saying drawing <10 vertices that need to be uploaded to the gpu every frame is a performance problem?
20:30 hecks as opposed to caching them, yes
20:30 hecks because
20:30 hecks you literally issue more calls doing that than the amount of verts you're dealing with
20:31 hecks and it's the GL calls and syncs that are the problem
20:31 hecks there's literally no reason on a GLES2 feature level to not keep a VBO around for each primitive type, and just transform it with a matrix
20:32 hecks also, vertex formats are hardcoded inline inside these functions which is disgusting
20:32 hecks not only it strips you of the opportunity to optimize the vertex format for each of these (crucial because each attribute is an extra GL call)
20:33 hecks but it's also what's making each IVideoDriver variant a 5000 line file (in addition to just having a ton of superfluous drawing function)
20:33 hecks seriously, who needs draw3DTriangle...
20:33 hecks or even drawPixel, this is stupid on an actual GPU
20:33 hecks this renderer is designed with crap like burningsvideo in mind, and OpenGL 1.0
20:33 hecks well, 1.1
20:34 hecks setting the VBO state up should be the MeshBuffer's responsibility
20:34 hecks and MeshBuffer is definitely not the place where materials should be stored...
20:35 hecks so i'm beginning this by redoing IVideoDriver.h itself
20:35 hecks then, COGLES2Driver will become the base driver class
20:35 hecks OpenGLDriver will descend from it and pretty much just handle procedure pointers on the platforms that need them
20:36 hecks WebGL1Driver already descends from it
20:36 hecks OGLES1Driver will be gone
20:36 hecks i'm confident that whatever CPU I save in the process here will outweigh the supposed benefits of having a GLES1 driver, I think the difference is actually that
20:36 sfan5 you mean more calls if you create a VBO for it? glDrawArrays is a single call
20:36 hecks that GLES1 is somehow a better fit for irrlicht's retarded ways
20:36 hecks creating the VBOs inline is the problem
20:37 hecks when you could just cache it
20:37 hecks it's not like the VBO for a box is ever going to change (if you use a matrix to position it)
20:37 sfan5 that makes sense
20:38 hecks it's the attrib pointer calls
20:38 hecks particles likewise do this and that's why they're so slow
20:39 hecks even if they bound one quad mesh and issued a lot of drawcalls for it, it would still be better than what it's doing now
20:39 hecks which is remaking the VBO for every particle separately... even though it's identical
20:39 hecks our vertex formats could generally be thinner
20:39 hecks especially for nodes, there's tons of good opportunities there
20:40 hecks for a tiny bit of vertex shader ALU you could make block meshes half the size and that would be noticeable
20:44 sfan5 I just realized my previous question is nonsense because of course you have to explicitly do some calls to upload the buffer and set stuff
20:44 sfan5 it's not like glVertex works in ogl1
20:44 sfan5 I should read more about GL first...
20:44 hecks look at the COGLES2Driver.cpp and weep
20:44 hecks how it implements all these immediate drawing functions that are clearly not the GL2 way to do things
20:44 hecks but rather something more suited for a software renderer
20:46 sfan5 https://a.uguu.se/2raaBVOnUAiJ_.png this is a lot of calls to draw a line with two points
20:46 hecks ah i see you've embarked on the wild ride that is running minetest inside a GL debugger
20:46 hecks this is probably why that guy was saying GLES2 is the slower path
20:46 hecks of course it's slow if you're doing shit like this...
20:46 sfan5 I don't know the idomatic way this would be done but at least I can look at renderdoc and observe way too many calls
20:47 hecks you can use gDEBugger for the "opengl" driver
20:47 hecks it's a little different but every bit as atrocious
20:47 sfan5 is that one better?
20:47 sfan5 guess not
20:47 hecks internally the GL driver will do the same thing this thing is doing, unfortunately
20:47 hecks in the compat context
20:48 hecks because any modern card's ISA will not have any provisions for this sort of drawing
20:48 hecks the driver will emulate legacy GL functions using new stuff
20:48 hecks oh and of course
20:48 hecks drawing something with glBegin is even more calls
20:49 hecks making a GL4 engine I've noticed that crossing over to the driver is the worst, the less and less often you do it the better
20:49 hecks a friend making a GL2 driver confirmed this behavior
20:50 hecks most of the calls are painful and should be kept to a minimum and dispatched in a burst if possible
20:50 sfan5 oh btw here's another thing that can be stripped out of Irrlicht: the other vertex formats
20:50 sfan5 I'm sure you're aware though
20:50 hecks i'm guessing it has to do with how the GL specs mandates that state must be synced and consistent
20:50 hecks sure, I mean
20:51 hecks we can keep a vertex with tangents around but not in the way it's done now
20:51 sfan5 do we have an use for it?
20:51 hecks I plan to just move this to the mesh buffer code, the proper way is that a mesh buffer sets its own state and binds *itself*
20:51 hecks I don't know, do we support normal maps in any capacity?
20:51 sfan5 that support was dropped
20:51 hecks entirely?
20:51 sfan5 (because it was broken)
20:51 sfan5 yes
20:51 hecks then i can delete tangents for now
21:58 MTDiscord <Jordach> isn't that required for per face CAO shading
22:33 Kimapr1 joined #minetest-dev
23:21 Extex joined #minetest-dev
23:52 Alias2 joined #minetest-dev

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