Time Nick Message 00:21 rubenwardy updated #12367 00:21 pgimeno https://github.com/minetest/minetest/pull/12367 -- Add minetest.get_player_window_information() by rubenwardy 01:28 lhofhansl I have to admit, I am somewhat excited about the combination of #13133 + #13179 + #13207 + #13213 + #13216 ... Finally Minetest is usable at large viewing_range (even 1000)! 01:28 pgimeno https://github.com/minetest/minetest/pull/13133 -- 8x block meshes by x2048 01:28 pgimeno https://github.com/minetest/minetest/pull/13179 -- Generalize mesh chunking, and make it configurable. by lhofhansl 01:28 pgimeno https://github.com/minetest/minetest/pull/13207 -- Spread updating the drawlist over multiple frames. by lhofhansl 01:28 pgimeno https://github.com/minetest/minetest/pull/13213 -- Reduce server CPU consumption with large view_ranges by lhofhansl 01:28 pgimeno https://github.com/minetest/minetest/pull/13216 -- Remove fast faces by numberZero 01:31 kilbith no far from ready actually, I'm preparing to describe an issue with bigger block meshes when I get some time 01:51 lhofhansl kilbith: Of course there might be more issues to fix, but this is far better than MT has ever been in this area. 01:54 kilbith we probably should be better off postponing 5.8 to the next spring to stabilize all of that and explore more optimizations 01:54 kilbith * 5.7 02:17 lhofhansl kilbith: Mesh chunking is disabled now by default. File an issue for problems that you. IMHO (1) if we do not start with something we'll never get there, (2) all the nice graphics in MT are useless if it's slow. Just my $0.02 02:44 sofar I wonder if lhofhansl has a branch with all those commits stacked together 04:08 lhofhansl (I keep getting dropped from IRC) 04:08 lhofhansl sofar: I have a local franken-Minetest. I'm happy to create/share a branch with all these :) 09:34 MTDiscord omg the memleaks have finally been fixed? 09:35 MTDiscord which memleaks? 09:37 MTDiscord the texture modifier memleaks (I hope) 09:37 MTDiscord e.g. unused texture modifier images are dropped now, right=? 11:06 MTDiscord we're... removing fast faces now? 11:15 MTDiscord also I think infinite viewing range was broken sometime around octablock (haven't bisected yet) 11:15 MTDiscord it's supposed to show all loaded mapblocks, but now it is restricted to the current viewing range 11:17 MTDiscord no, it's restricted to current view range + a small amount 11:18 MTDiscord (but yea) 11:21 MTDiscord yes, cubic as opposed to circular I think 11:21 MTDiscord but still regressed 11:21 MTDiscord wouldn't removing fast faces fuck over lower-end GPUs that cant handle more faces? 11:22 MTDiscord uh yeah 11:22 MTDiscord imo it should be extended to merge even more faces 11:22 MTDiscord it should be important to check that changes that improve performance for high-end desktop setups at high viewing range doesn't regress e.g. android performance 11:23 MTDiscord just throwing that out there 11:23 MTDiscord removing fast faces does fix some glitches though 11:23 MTDiscord because it does it wrong 11:23 MTDiscord (i mean the holes at edges) 11:29 MTDiscord kimpar: to my experience, face count may be a problem with nouveau. In other cases, fill rate tends to dominate 11:31 MTDiscord and note that face merging is very limited anyway: 11:31 MTDiscord only flat surfaces, with same lighting, no ambient occlusion, etc. 11:36 MTDiscord ok so bisect reveals https://github.com/minetest/minetest/commit/2715cc8bf68a2cc8cd583cd5b0bb732ee13a1b49 to be the issue of infinite view range being broken 11:39 MTDiscord sfan5: you mentioned dropping fixed-function pipeline is a possibility. Does that mean it is possible to support OpenGL 3+ Core and OpenGL ES 2+ only? 11:45 MTDiscord doesnt opengl 2 have shaders too? 11:45 MTDiscord is has an abomination and not proper shaders 11:46 MTDiscord whar 11:46 MTDiscord OpenGL 2 shaders are bound to its fixed-function pipeline 11:48 MTDiscord thus very rigid 11:49 MTDiscord and dissimilar to OpenGL ES 2 shaders 11:49 MTDiscord just take a look at the code that makes the same shaders work in both GL2 and GLES2 11:50 MTDiscord ShaderSource::generateShader is only part of it 11:52 MTDiscord while OpenGL 3 was designed with fully programmable pipeline in mind 11:52 MTDiscord (moreover, OpenGL 3 Core lacks fixed-function pipeline entirely) 11:55 MTDiscord so when you render in OpenGL 3, you may pass arbitrary data to your shaders. While in OpenGL 2, you need to stuff it into things fixed-function pipeline supports 11:56 MTDiscord one example is packing node color AND lighting in vertex color, in some weird way 12:01 MTDiscord also, it doesn’t support integer vertex attributes. which would be handy for indexing into a texture array... oops, it doesn’t support these, either 12:02 kilbith maybe it's time to get allergic to 15+ years old hardware 12:21 MTDiscord minetest is allergic to modern hardware too 12:37 * lebruhgamer[m] uploaded an image: (2954KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/dzpeYltaQWKnTfjJgdBKlLlm/7bmde5.gif > 13:19 MTDiscord looks like both prefer the hardware that was good when they were young... 13:20 MTDiscord seriously though, it wasn’t me who offered to drop fixed-function pipeline support 13:20 MTDiscord and the fixed-function pipeline isn’t the worst thing 13:20 MTDiscord the hybrid one is 13:22 MTDiscord it is of course possible to support 3 pipelines: fixed-function, hybrid, and programmable. does Minetest has manpower for that? 13:25 sfan5 @numzero I'd have to dig in the logs to check the recent discussion, not sure 13:26 sfan5 core profile would make it necessary to rewrite the opengl code inside irrlicht 13:26 sfan5 or at least adjust the ogles2 driver to talk desktop gl 13:26 sfan5 while "you need at least opengl 2 shaders" we could do at any moment and it would hopefully(?) bring some benefits 13:45 MTDiscord hardly 13:45 MTDiscord OpenGL 2 shaders are worse than the fixed-function pipeline IMO 13:47 MTDiscord I’d rather keep the fixed-function but limit shaders to OpenGL 3+ 13:49 MTDiscord although using different shaders for GL2 and everything else might be an option too 13:50 MTDiscord it would require keeping twice as much of Irrlicht code though 15:38 sfan5 hm 15:39 sfan5 keeping legacy code is free at first but I'm sure it'd become a bother 15:39 sfan5 merging #13223 and #13219 in like 5 minutes 15:39 pgimeno https://github.com/minetest/minetest/pull/13223 -- Fix typo and missing entry in serveropcodes by paradust7 15:39 pgimeno https://github.com/minetest/minetest/pull/13219 -- Remove dead code behind Irrlicht version checks by sfan5 17:53 kilbith this is a terrific demo of MT running at very long distance: https://i.imgur.com/gXqKLT6.png 17:53 kilbith 1000 nodes of viewing range, high quality shadowmaps w/ bloom, 4x block meshes. 25-27 FPS. 17:53 lhofhansl See #13225 for the infinite viewing_range problem. Quick and dirty, but works. 17:53 kilbith without shadows I'd easily hit 60 FPS, at 1000 nodes (!) I repeat 17:54 pgimeno https://github.com/minetest/minetest/pull/13225 -- Fix infinite viewing_range by lhofhansl 18:31 pgimeno wouldn't removing fast faces enable texture atlases? 18:32 pgimeno enable as in, make them possible 19:02 MTDiscord pgimeno: why do you want texture atlases when OpenGL 3 has texture arrays? 19:03 pgimeno I thought GL 2 support wasn't being removed 19:09 MTDiscord okay, another question then: why do you want texture atlases at all? 19:34 pgimeno to reduce the number of textures sent to the shaders 19:37 kilbith but Irrlicht does not support texture arrays 19:38 MTDiscord kilbith: of course it doesn’t, currently. but what’s the problem with adding such support? 19:39 kilbith yes, if you can pack more materials in a single drawcall 19:39 kilbith per block I mean 19:39 MTDiscord argh, materials... 19:39 MTDiscord yet another API from the fixed-function era 19:40 MTDiscord but wait, why? 19:40 kilbith didn't hecks started to work on a material system? 19:40 kilbith * start, err 19:40 MTDiscord what I mentioned is not texture array, it’s array texture 19:41 MTDiscord it’s a single texture at the API level 19:41 MTDiscord but with many layers out of which the shader can choose any 19:43 MTDiscord so in fact, packing many materials (in Irrlicht sense) is not necessary, nor recommended 19:44 MTDiscord the way is to pack many images in a single array texture, use that in a single material, and render many node types with that material 19:45 MTDiscord thus the actual problem is passing layer number to the shader. that needs an additional vertex attribute... 19:45 sfan5 here's the last time the opengl 2/3 discussion came up btw https://irc.minetest.net/minetest-dev/2022-08-18#i_6008550 19:45 MTDiscord preferably an integral one 19:45 sfan5 the result is basically "make opengl 2 requirement definitely and opengl 3 (core) likely if whoever does the work thinks it's useful" 19:46 kilbith perfectly ok supporting 10 yo GPUs, but line break at that. 19:55 MTDiscord According to Wikipedia, nVidia supports OpenGL 4 since 2010 (GeForce 4xx) Radeon supports OpenGL 4 since 2009 (Evergreen) Intel supports OpenGL 4 since 2012 (Ivy Bridge) 19:56 MTDiscord so 10-year-old Intel GPU supports OpenGL 4 19:57 sfan5 I'd double check that with what Mesa supports in case that somehow differs from the vendor driver, but sure 19:59 MTDiscord Mesa may very well be better than vendor driver 19:59 MTDiscord in this aspect 20:01 MTDiscord according to Wikipedia, Mesa supports OpenGL 4.2 on Ivy Bridge while on Windows, only OpenGL 4.0 is supported on that chip =) 20:04 sfan5 what I'm wondering is what the best way to go about replacing the renderer is 20:05 sfan5 surely we don't want to rewrite the COpenGLDriver.cpp in Irrlicht only to continue to deal with the mis-designed APIs and/or to have lots of work integrating it into MT later 20:05 sfan5 on the other hand not rewriting it means we instantly have to touch all (at least 3d) graphics code in Minetest and fix it up 20:05 MTDiscord I think making GLES2 driver work with GL3 isn’t a big deal 20:06 sfan5 to use our new abstractions or whatever we come up with 20:06 sfan5 hmm 20:06 sfan5 so you'd do that and then when you want e.g. texture array support you'd add the plumbing for that to irrlicht? 20:06 sfan5 or gradually move stuff into MT proper? 20:07 MTDiscord I’d clean Irrlicht first, and then think whether to keep it separate 20:07 sfan5 I see 20:08 MTDiscord so basically: 1. adapt GLES2 driver to support both GLES2 and GL3 2. drop all other drivers 20:08 MTDiscord the same with “Devices”, drop everything but SDL2 20:09 MTDiscord would it ever make any sense to use something like bgfx to support multiple formats? 20:09 MTDiscord and then it will be way clearer what to do next 20:11 MTDiscord @wsor I doubt so 20:12 MTDiscord that would mean rewriting pretty much all rendering at once 20:13 MTDiscord yeah, just wondered since it seems macos is moving away from opengl, and vulkan might become the accepted standard in the future. 20:14 sfan5 macos is "moving away" from opengl but the reality is few people will use their special snowflake API 20:15 MTDiscord and there is ANGLE 20:15 MTDiscord and MetalANGLE, and other forks 20:15 MTDiscord as implementing OpenGL over Metal/Vulkan/likewise is a reasonable thing 20:16 MTDiscord (unlike the other way round) 20:16 MTDiscord thanks for the explanation/reasoning 👍 20:26 Desour speaking about opengl and other graphic apis, did you know that the SDL devs are making a graphics API for SDL3? see . it would be interesting if it would be fitting minetest's needs at some point, at least for newer hardware 20:30 MTDiscord not in foreseeable future 20:32 MTDiscord it is just so much different from OpenGL so adapting it is likely way too much work 20:43 MTDiscord also, their feature set is apparently limited by design. which doesn’t exactly make spending extra effort on it attractive 20:46 MTDiscord I'm gonna come right out of the highway entrance at 200mph and suggest, vulkan render target :p 20:47 MTDiscord I'm gonna have to learn how it works with a D project before I even attempt that though 20:52 Desour thanks for your assessment, numzero. ^^ also, welcome back, btw.! 22:12 ashstar1248 Hi, I'm new to minetest development, is there an easy bug that I could squash without a great understanding of the codebase? 22:17 Desour question: is it save to assume there exists no mod called "group"? x) 22:20 MTDiscord am I right the “Beginner Friendly” issue label is specifically for that? 22:23 MTDiscord ashstar1248: https://github.com/minetest/minetest/issues?q=is%3Aopen+is%3Aissue+label%3A%22Beginner+Friendly%22 IIUC 22:55 MTDiscord Desour: https://content.minetest.net/modnames/group/ would imply yes 22:57 Desour nah, contendb doesn't contain the future, nor all mods ever made 23:36 MTDiscord Hey you need libjpeg-turbo-devel on fedora 36 and 37 or else they won't be able to compile the game!