| 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! |
