Minetest logo

IRC log for #minetest-dev, 2023-02-18

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

All times shown according to UTC.

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:25 lhofhansl joined #minetest-dev
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:29 proller joined #minetest-dev
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:47 lhofhansl joined #minetest-dev
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:16 lhofhansl joined #minetest-dev
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 joined #minetest-dev
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 :)
05:00 MTDiscord joined #minetest-dev
05:36 YuGiOhJCJ joined #minetest-dev
09:34 MTDiscord <luatic> omg the memleaks have finally been fixed?
09:35 MTDiscord <x2048> which memleaks?
09:37 MTDiscord <luatic> the texture modifier memleaks (I hope)
09:37 MTDiscord <luatic> e.g. unused texture modifier images are dropped now, right=?
11:06 MTDiscord <ROllerozxa> we're... removing fast faces now?
11:15 MTDiscord <ROllerozxa> also I think infinite viewing range was broken sometime around octablock (haven't bisected yet)
11:15 MTDiscord <ROllerozxa> it's supposed to show all loaded mapblocks, but now it is restricted to the current viewing range
11:17 MTDiscord <kimapr> no, it's restricted to current view range + a small amount
11:18 MTDiscord <kimapr> (but yea)
11:21 MTDiscord <ROllerozxa> yes, cubic as opposed to circular I think
11:21 MTDiscord <ROllerozxa> but still regressed
11:21 MTDiscord <kimapr> wouldn't removing fast faces fuck over lower-end GPUs that cant handle more faces?
11:22 MTDiscord <ROllerozxa> uh yeah
11:22 MTDiscord <kimapr> imo it should be extended to merge even more faces
11:22 MTDiscord <ROllerozxa> 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 <ROllerozxa> just throwing that out there
11:23 MTDiscord <kimapr> removing fast faces does fix some glitches though
11:23 MTDiscord <kimapr> because it does it wrong
11:23 MTDiscord <kimapr> (i mean the holes at edges)
11:29 MTDiscord <numzero> kimpar: to my experience, face count may be a problem with nouveau. In other cases, fill rate tends to dominate
11:31 MTDiscord <numzero> and note that face merging is very limited anyway:
11:31 MTDiscord <numzero> only flat surfaces, with same lighting, no ambient occlusion, etc.
11:36 MTDiscord <ROllerozxa> ok so bisect reveals https://github.com/minetest/minetest/commit/2715cc8bf68a2cc8cd583cd5b0bb732ee13a1b49 to be the issue of infinite view range being broken
11:39 MTDiscord <numzero> 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 <kimapr> doesnt opengl 2 have shaders too?
11:45 MTDiscord <numzero> is has an abomination and not proper shaders
11:46 MTDiscord <kimapr> whar
11:46 MTDiscord <numzero> OpenGL 2 shaders are bound to its fixed-function pipeline
11:48 MTDiscord <numzero> thus very rigid
11:49 MTDiscord <numzero> and dissimilar to OpenGL ES 2 shaders
11:49 MTDiscord <numzero> just take a look at the code that makes the same shaders work in both GL2 and GLES2
11:50 MTDiscord <numzero> ShaderSource::generateShader is only part of it
11:52 MTDiscord <numzero> while OpenGL 3 was designed with fully programmable pipeline in mind
11:52 MTDiscord <numzero> (moreover, OpenGL 3 Core lacks fixed-function pipeline entirely)
11:55 MTDiscord <numzero> 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 <numzero> one example is packing node color AND lighting in vertex color, in some weird way
12:01 MTDiscord <numzero> 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 <Flamore> minetest is allergic to modern hardware too
12:36 lebruhgamer[m] joined #minetest-dev
12:37 * lebruhgamer[m] uploaded an image: (2954KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/dzpeYltaQWKnTfjJgdBKlLlm/7bmde5.gif >
13:19 MTDiscord <numzero> looks like both prefer the hardware that was good when they were young...
13:20 MTDiscord <numzero> seriously though, it wasn’t me who offered to drop fixed-function pipeline support
13:20 MTDiscord <numzero> and the fixed-function pipeline isn’t the worst thing
13:20 MTDiscord <numzero> the hybrid one is
13:22 MTDiscord <numzero> 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 <numzero> hardly
13:45 MTDiscord <numzero> OpenGL 2 shaders are worse than the fixed-function pipeline IMO
13:47 MTDiscord <numzero> I’d rather keep the fixed-function but limit shaders to OpenGL 3+
13:49 MTDiscord <numzero> although using different shaders for GL2 and everything else might be an option too
13:50 MTDiscord <numzero> it would require keeping twice as much of Irrlicht code though
14:11 Desour joined #minetest-dev
14:34 calcul0n joined #minetest-dev
14:36 LandarVargan joined #minetest-dev
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:37 kilbith joined #minetest-dev
17:38 fluxionary joined #minetest-dev
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 joined #minetest-dev
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:13 lhofhansl joined #minetest-dev
18:31 pgimeno wouldn't removing fast faces enable texture atlases?
18:32 pgimeno enable as in, make them possible
19:02 MTDiscord <numzero> 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 <numzero> 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 <numzero> 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 <numzero> argh, materials...
19:39 MTDiscord <numzero> yet another API from the fixed-function era
19:40 MTDiscord <numzero> but wait, why?
19:40 kilbith didn't hecks started to work on a material system?
19:40 kilbith * start, err
19:40 MTDiscord <numzero> what I mentioned is not texture array, it’s array texture
19:41 MTDiscord <numzero> it’s a single texture at the API level
19:41 MTDiscord <numzero> but with many layers out of which the shader can choose any
19:43 MTDiscord <numzero> so in fact, packing many materials (in Irrlicht sense) is not necessary, nor recommended
19:44 MTDiscord <numzero> 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 <numzero> 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 <numzero> 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 <numzero> 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 <numzero> 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 <numzero> Mesa may very well be better than vendor driver
19:59 MTDiscord <numzero> in this aspect
20:01 MTDiscord <numzero> 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 <numzero> 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 <numzero> I’d clean Irrlicht first, and then think whether to keep it separate
20:07 sfan5 I see
20:08 MTDiscord <numzero> so basically: 1. adapt GLES2 driver to support both GLES2 and GL3 2. drop all other drivers
20:08 MTDiscord <numzero> the same with “Devices”, drop everything but SDL2
20:09 MTDiscord <Jonathon> would it ever make any sense to use something like bgfx to support multiple formats?
20:09 MTDiscord <numzero> and then it will be way clearer what to do next
20:11 MTDiscord <numzero> @wsor I doubt so
20:11 Desour joined #minetest-dev
20:12 MTDiscord <numzero> that would mean rewriting pretty much all rendering at once
20:13 MTDiscord <Jonathon> 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 <numzero> and there is ANGLE
20:15 MTDiscord <numzero> and MetalANGLE, and other forks
20:15 MTDiscord <numzero> as implementing OpenGL over Metal/Vulkan/likewise is a reasonable thing
20:16 MTDiscord <numzero> (unlike the other way round)
20:16 MTDiscord <Jonathon> 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 <https://github.com/libsdl-org/SDL_shader_tools/blob/main/docs/README-SDL_gpu.md>. it would be interesting if it would be fitting minetest's needs at some point, at least for newer hardware
20:30 MTDiscord <numzero> not in foreseeable future
20:32 MTDiscord <numzero> it is just so much different from OpenGL so adapting it is likely way too much work
20:43 MTDiscord <numzero> also, their feature set is apparently limited by design. which doesn’t exactly make spending extra effort on it attractive
20:46 MTDiscord <jordan4ibanez> I'm gonna come right out of the highway entrance at 200mph and suggest, vulkan render target :p
20:47 MTDiscord <jordan4ibanez> 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.!
21:20 Guest2341 joined #minetest-dev
21:20 Guest2341 left #minetest-dev
21:26 ashstar1248 joined #minetest-dev
21:47 proller joined #minetest-dev
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 <numzero> am I right the “Beginner Friendly” issue label is specifically for that?
22:23 MTDiscord <numzero> ashstar1248: https://github.com/minetest/minetest/issues?q=is%3Aopen+is%3Aissue+label%3A%22Beginner+Friendly%22 IIUC
22:55 MTDiscord <Jonathon> 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 <jordan4ibanez> Hey you need libjpeg-turbo-devel on fedora 36 and 37 or else they won't be able to compile the game!

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