| Time |
Nick |
Message |
| 00:47 |
|
fluxionary joined #minetest |
| 01:01 |
|
whosit joined #minetest |
| 01:09 |
|
sid0 joined #minetest |
| 01:14 |
|
jistr joined #minetest |
| 01:40 |
|
ireallyhateirc joined #minetest |
| 02:16 |
|
CRISPR joined #minetest |
| 02:27 |
|
SwissalpS joined #minetest |
| 02:39 |
|
CRISPR joined #minetest |
| 03:01 |
|
SFENCE_arch joined #minetest |
| 03:29 |
|
CRISPR joined #minetest |
| 03:38 |
|
SFENCE joined #minetest |
| 04:22 |
|
yezgromafic joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:17 |
|
kamdard joined #minetest |
| 06:05 |
|
YuGiOhJCJ joined #minetest |
| 06:56 |
|
bdju joined #minetest |
| 06:57 |
|
TomTom joined #minetest |
| 08:31 |
sfan5 |
<_devsh_> ------- also do you have a "blackhole render" mode ? |
| 08:31 |
sfan5 |
we don't |
| 09:39 |
|
MacroFaxSax joined #minetest |
| 09:51 |
sfan5 |
the primary problem is that we don't have anyone experienced enough in graphics to implement even half the techniques you have suggested in the last days |
| 09:51 |
sfan5 |
that would normally be the "dedicated graphics person", which we haven't had for years |
| 09:55 |
rubenwardy |
they see 'opengl 1.0' and run away screaming |
| 10:04 |
sfan5 |
after reading https://learnopengl.com/Advanced-OpenGL/Advanced-GLSL it sounds like this would maybe save us 50 glUniform* calls per frame since we don't have a huge amount of unique shaders in use. so good in principle, but won't have much performance impact. |
| 10:05 |
sfan5 |
did I miss something? is this even correct? I can't tell |
| 10:06 |
sfan5 |
(maybe it was meant in context of skinning, idk) |
| 10:15 |
sfan5 |
if it was about skinning then I suppose every model could keep its own UBO with skinning related data and that can simply be used and updated as needed. would be very inefficient with uniforms. |
| 10:20 |
MTDiscord |
<jordan4ibanez> Is that 50 gluniform calls per frame or per mesh? |
| 10:23 |
sfan5 |
frame |
| 10:25 |
sfan5 |
each shader has its own set of uniforms. with the use case described in the article an UBO would make sense for rarely changing global stuff |
| 10:25 |
sfan5 |
so instead of updating stuff per-variable per-shader there'd be just one global UBO with the variables inside |
| 10:25 |
sfan5 |
(rarely changing = once per frame) |
| 10:28 |
MTDiscord |
<jordan4ibanez> How hard would it be to stream all those uniforms for each mesh in one struct array with indirect draw, so it's not clogging the pcie bridge, with how the current landscape is, in the opengl 3.1 driver? |
| 10:32 |
MTDiscord |
<jordan4ibanez> glDrawElementsIndirect is 4.0 hmm |
| 10:32 |
|
gregon joined #minetest |
| 10:32 |
MTDiscord |
<jordan4ibanez> Probably has an extension somewhere |
| 10:33 |
MTDiscord |
<jordan4ibanez> I can already see, the sun position, the camera matrix, stuff like that as ubo |
| 10:38 |
MTDiscord |
<jordan4ibanez> I'm tripping over myself a bit because I am trying to think about the different GL versions support at the same time I am proposing ideas, a bit frustrating |
| 10:54 |
|
erle joined #minetest |
| 10:56 |
|
tarsovbak joined #minetest |
| 13:23 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Refactor ScriptApiSecurity for cleaner separation of concerns 1fd4e0b https://github.com/minetest/minetest/commit/1fd4e0b82dd4e15aef0025eccdcb3bc984f70d9d (2024-11-13T13:22:41Z) |
| 13:23 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Implement script sandboxing for main menu ea4ae55 https://github.com/minetest/minetest/commit/ea4ae55e24d2c27524490cb8e0d3c34aa46e3da3 (2024-11-13T13:22:41Z) |
| 13:23 |
MinetestBot |
[git] grorp -> minetest/minetest: Replace forgotten SEvent memset 11e04ec https://github.com/minetest/minetest/commit/11e04ec1136f9cd37817a2e129770fe463f2aea1 (2024-11-13T13:23:13Z) |
| 13:23 |
MinetestBot |
[git] veprogames -> minetest/minetest: Change minetest.net to luanti.org in 'Further documentation' 0fde9ab https://github.com/minetest/minetest/commit/0fde9ab7e84490914a7e22fe674f1de237c3a674 (2024-11-13T13:23:39Z) |
| 13:26 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Drop fixed pipeline support code (#15421) 794aea8 https://github.com/minetest/minetest/commit/794aea8e92b9f06d3118f65223729b92b505568a (2024-11-13T13:24:01Z) |
| 13:45 |
MTDiscord |
<jordan4ibanez> there we go |
| 13:48 |
|
SFENCE joined #minetest |
| 14:00 |
|
SFENCE_arch joined #minetest |
| 14:05 |
|
simon816 joined #minetest |
| 14:43 |
|
tarsovbak joined #minetest |
| 15:46 |
|
Thermoriax joined #minetest |
| 16:01 |
erle |
end of an era |
| 16:09 |
|
MacroFaxSax joined #minetest |
| 16:19 |
|
sinvet joined #minetest |
| 16:22 |
|
shinbet joined #minetest |
| 16:25 |
|
sinvet joined #minetest |
| 16:53 |
|
sinvet joined #minetest |
| 16:57 |
|
sinvet joined #minetest |
| 17:07 |
|
vampirefrog joined #minetest |
| 17:20 |
[ |
rip luanti |
| 17:21 |
|
est31 joined #minetest |
| 17:24 |
|
SFENCE joined #minetest |
| 17:25 |
|
bwarden joined #minetest |
| 17:27 |
|
SFENCE joined #minetest |
| 17:32 |
SFENCE |
Zughy: I have macOS. |
| 17:44 |
MTDiscord |
<jordan4ibanez> I'm sorry about that |
| 17:45 |
erle |
luatic i believe you are wrong here about “barely playable”. i have gotten better performance than the issue submitter on worse hardware. https://github.com/minetest/minetest/issues/15433#issuecomment-2474309928 |
| 17:46 |
MTDiscord |
<luatic> erle: the "barely playable" remark is about the FPS reported here specifically - i consider 22 FPS barely playable. |
| 17:46 |
[ |
I also got better performance when I tested on 5.6.1 on the other computer |
| 17:46 |
erle |
luatic i got more fps without shaders, but a larger drop. like rendering time 6ms to 60ms. |
| 17:47 |
[ |
It's probably to do with the fact that I tested in different worlds (looking at different things) and it being a debug build |
| 17:47 |
erle |
[ i have an idea |
| 17:47 |
erle |
[ see if you get more performance out of your intel integrated GPU by starting the game with MESA_GL_VERSION_OVERRIDE=1.4 MESA_EXTENSION_MAX_YEAR=2005 |
| 17:48 |
erle |
this should report the bare minimum that makes it runnable (if you have shaders disabled, otherwise you get a crash) |
| 17:48 |
erle |
but it should look the same (if you are not using any fancy effects, which you are not, because you are not using the shaders) |
| 17:48 |
sfan5 |
in the best case we'll make generaly performance improvements in the future, which you will also benefit from |
| 17:49 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Fix mainmenu settings crash caused by last commit 0c3117f https://github.com/minetest/minetest/commit/0c3117f9b32624955846314ebf87f757d124184f (2024-11-13T17:39:10Z) |
| 17:50 |
MTDiscord |
<luatic> [: ideally don't test performance on debug builds. that includes rendering performance, because our rendering may be largely CPU-bound. |
| 17:50 |
MTDiscord |
<warr1024> in my experience, noticeable performance differences between debug and release builds is quite rare, at least. |
| 17:50 |
erle |
luatic 22 to 25fps was in old magazines like “PC games” etc. as “ruckelt, aber spielbar” lol |
| 17:51 |
MTDiscord |
<jordan4ibanez> It can be HUGE |
| 17:51 |
|
SFENCE joined #minetest |
| 17:51 |
MTDiscord |
<warr1024> it could be huge, but it's almost always nothing |
| 17:51 |
sfan5 |
I think our debug builds are not -O0 anymore? |
| 17:51 |
MTDiscord |
<luatic> that's not what i'm feeling tbh, release builds generally feel smooth for me, debug builds don't |
| 17:52 |
erle |
in my experience, everyone who has not tried something is full of shit about performance on some hardware. i have had people ask how i even use firefox with 2GB RAM who only ever used chrome (which will gobble up RAM like it is going out of fashion) |
| 17:52 |
|
m42uko_ joined #minetest |
| 17:52 |
MTDiscord |
<warr1024> Is it fair to say that RelWithDebInfo releases are closer to release than debug builds in terms of performance? |
| 17:53 |
sfan5 |
of course |
| 17:53 |
sfan5 |
because debug information doesn't cost anything except larger binaries |
| 17:54 |
erle |
sanitizers definitely cost something, otherwise i have not noticed anything weird |
| 17:55 |
MTDiscord |
<warr1024> If I make a RelWithDebInfo build and then just strip the binary, does that get me pretty close to what I'd get with a simple Release build? |
| 17:57 |
sfan5 |
yes |
| 17:57 |
erle |
[ given that the game ran better on intel GMA 950 (GMA generation 3) someone is probably doing *something* wrong if you only get 22 fps on intel GMA 4500 (GMA generation 4). unless i am mistaken about chipsets getting better. |
| 17:57 |
erle |
[ have you tried that thing i suggested? |
| 17:57 |
[ |
I'm still compiling a release build |
| 17:58 |
MTDiscord |
<jordan4ibanez> Probably memory latency, needing to go into ram more often |
| 17:58 |
sfan5 |
note that LTO builds generally take more time, so disable that if you have a slow machine |
| 17:58 |
sfan5 |
(we enable that by default) |
| 17:58 |
erle |
[ disable LTO, it takes forever |
| 17:59 |
MTDiscord |
<jordan4ibanez> Try mold |
| 18:09 |
|
YuGiOhJCJ joined #minetest |
| 18:11 |
[ |
erle: what viewrange do you use? |
| 18:11 |
[ |
neither those environment variables nor using a release build seems to help much |
| 18:12 |
[ |
with 50 viewrange I do get 30 fps |
| 18:12 |
erle |
[ 50 to 200, depending on what game i want to play. nodecore does not benefit from a large view range. what do you use? |
| 18:12 |
erle |
in fact, nodecore is the anti-exploration game. i only explore to get some [spoiler] ore |
| 18:12 |
[ |
I was testing with 100 |
| 18:13 |
erle |
do you notice *any* perf impact of the env variables? |
| 18:13 |
|
hunter0one joined #minetest |
| 18:15 |
[ |
no |
| 18:15 |
erle |
[ do you have different performance for joining servers vs playing locally? |
| 18:16 |
erle |
like, on weak machines sometimes the mapgen starves out everythin else for some games that have bad mapgen |
| 18:16 |
erle |
but this has always been the case and is an issue of the game |
| 18:16 |
erle |
not the engine |
| 18:16 |
|
lhofhansl joined #minetest |
| 18:26 |
[ |
erle: it's hard to compare because the worlds are different |
| 18:26 |
erle |
[ you will be able to figure out if you get 20fps (borderline unplayable) or 30fps (what i think you should get) though? |
| 18:27 |
erle |
like use some game that is not very dynamic, like nodecore or so |
| 18:27 |
erle |
or minetest_game without mods |
| 18:28 |
MTDiscord |
<jordan4ibanez> Wait the gma 950 has windows xp drivers available |
| 18:30 |
MTDiscord |
<jordan4ibanez> Dude, that GPU has 4 pixel shaders. I'm not sure how you're even getting that many fps |
| 18:31 |
MTDiscord |
<jordan4ibanez> Are you running a Celeron D? |
| 18:31 |
erle |
LOUD INCORRECT GENDER BUZZER |
| 18:31 |
[ |
it varies |
| 18:31 |
MTDiscord |
<jordan4ibanez> So it's a Celeron D then |
| 18:31 |
erle |
jordan4ibanez, it's a classic gamer thing. you could see that in the mineclone2 issue tracker as well. |
| 18:32 |
erle |
remember the time when i opened an issue about some legit perf issue and everyone started saying “nah, your hardware is garbage” and then it was retitled to “post your computers specs”? gamers, as a group, can't do otherwise. the perf issue was legit and fixed btw. |
| 18:32 |
erle |
(on the mineclone2 issue tracker, mind you) |
| 18:33 |
MTDiscord |
<jordan4ibanez> A classic gamer thing? Then why not retire it to play classic games? |
| 18:33 |
erle |
classic as in “devs who are gamers” |
| 18:33 |
MTDiscord |
<luatic> lol |
| 18:34 |
MTDiscord |
<jordan4ibanez> That hardware is old enough to buy cigarettes |
| 18:34 |
erle |
curiously, i have never seen this for any non-gaming software that people *insist* it can not possible run some software |
| 18:34 |
erle |
hardware |
| 18:34 |
erle |
sorry |
| 18:34 |
erle |
curiously, i have never seen this for any non-gaming software that people *insist* it can not possible run some hardware [fixed the statement] |
| 18:35 |
erle |
or rather, gamers sometimes do |
| 18:35 |
erle |
but not the devs of said software |
| 18:35 |
MTDiscord |
<jordan4ibanez> You're obviously running the game, yes? Maybe you could invest in a raspberry pi model 2 and double your fps lol |
| 18:35 |
erle |
or people intimately familiar with it |
| 18:36 |
erle |
like no one is saying “you can't possibly run wayland on an old thinkpad” (because you can) or “you can't possibly run blender on that hardware” (because blender deprecates stuff so fast that a lot of people basically stay on an old version, so it is clear what works and what not) |
| 18:37 |
[ |
new versions of blender won't run on that hardware (unless you do software rendering) |
| 18:37 |
MTDiscord |
<jordan4ibanez> I think you don't understand, you're basically proposing that we attempt to make a stock Suzuki Cultus run on pikes peak at above 50 kph lol |
| 18:37 |
erle |
jordan4ibanez i am currently waiting for replacement batteries for my reform 2 to be delivered so i can use it again |
| 18:38 |
MTDiscord |
<jordan4ibanez> I'm sure windowmaker will run very well on it |
| 18:38 |
erle |
see, you are doing it again |
| 18:40 |
MTDiscord |
<jordan4ibanez> https://tenor.com/view/dog-eyebrow-funny-eyebrow-raise-gif-13185653 |
| 18:40 |
erle |
jordan4ibanez i think YOU don't understand. if you develop on hardware that is much better (or simply different) than what at least some of your users have, you end up breaking that stuff *unless* you structure your code so that everything is additive (as in progressive enhancement) |
| 18:41 |
erle |
jordan4ibanez as an example, i have built a python-based synthesizer library, called libglitch, many years ago. i used the worst machine i could grab to test it and optimized it, because any lag would create stuttering sound. |
| 18:41 |
MTDiscord |
<jordan4ibanez> Well, I'm sure if it were 2010 I'd greatly consider 950 as part of my target for legacy windows xp users |
| 18:41 |
erle |
i don't actually think you get the same performance on windows as on linux actually |
| 18:42 |
MTDiscord |
<jordan4ibanez> Why did you make something in python if performance was critical? |
| 18:42 |
erle |
because it was easy |
| 18:42 |
erle |
and you can optimize python stuff to make sure the compute intensive things use fast c code |
| 18:43 |
erle |
but mainly, by constraining myself to the shittiest laptop i could find, i made sure i do not accidentally metaphorically paint myself into a corner |
| 18:43 |
erle |
i *could* have made that app with C + SDL |
| 18:43 |
|
kamdard joined #minetest |
| 18:43 |
[ |
GMA 4500 MHD is important because it is the most recent GPU in RYF hardware |
| 18:44 |
erle |
[ important to you. not important to any of the devs, apparently. and this has been a thing for a while. |
| 18:44 |
MTDiscord |
<jordan4ibanez> It's also very easy to go out on trash day and find a pc to upgrade your rig with, that's how I got my first upgrade from an athlon ii 220 to a core 2 duo |
| 18:44 |
[ |
it's important for software freedom |
| 18:44 |
MTDiscord |
<jordan4ibanez> Listen, there is react os and freedos for the ancient hardware, freedom is good |
| 18:44 |
erle |
jordan4ibanez i have core duo! |
| 18:45 |
erle |
jordan4ibanez i gave you the meme, cut the crap. |
| 18:45 |
MTDiscord |
<jordan4ibanez> It's not crap, this is so out of touch I think it might be pulling me into another dimension |
| 18:45 |
[ |
newer hardware is simply not usable without compromising on software freedom |
| 18:46 |
MTDiscord |
<luatic> erle: the people demand more memes |
| 18:46 |
MTDiscord |
<luatic> your hardware was never free to begin with |
| 18:47 |
MTDiscord |
<jordan4ibanez> I can't believe it was said verbatim |
| 18:47 |
MTDiscord |
<luatic> "free software" hardware is an arbitrary puristic requirement |
| 18:47 |
sfan5 |
what's "RYF" hardware? |
| 18:47 |
MTDiscord |
<luatic> like pure functional programming |
| 18:47 |
MTDiscord |
<jordan4ibanez> Just ignore those proprietary bits of firmware in there, you didn't see anything |
| 18:47 |
sfan5 |
If I had that blog post lying around where someone criticized the fsf free software definition I'd post it |
| 18:48 |
ROllerozxa |
"respects your freedom", which is mostly an arbitrary decision from the FSF whether the hardware is rubberstamped by them or not |
| 18:48 |
|
Talkless joined #minetest |
| 18:49 |
MTDiscord |
<jordan4ibanez> Your hard drive control board better have the C code posted on github under a gpl compatible license or I'm going to be very disappointed |
| 18:49 |
erle |
[ going with the theme of jordan4ibanez you should obviously pony up money to buy a MNT reform 2 or MNT reform NXT |
| 18:49 |
erle |
NEXT |
| 18:49 |
sfan5 |
anyway MNT Reform might be more up your alley if you like freedom |
| 18:49 |
erle |
until the devs decide that the MNT reform is “too old” obviously |
| 18:49 |
MTDiscord |
<jordan4ibanez> Literally, any website, 20 dollars, buy something that's about to be thrown away |
| 18:50 |
erle |
jordan4ibanez it's actually not that easy. 4:3 matte monitors in laptops died out around >10 years ago |
| 18:50 |
MTDiscord |
<jordan4ibanez> You're lucky you never got into itanium or you would still be very mad at Linus torvalds |
| 18:50 |
erle |
you either get 16:9 or, rarely (chromebooks) 3:2 |
| 18:50 |
erle |
and almost all glossy |
| 18:51 |
erle |
anyway, “buy new hardware” is almost always the gamer response to removing functionality people use |
| 18:51 |
MTDiscord |
<jordan4ibanez> Literally, first generation i3, bam you have an upgrade for like 10 dollars |
| 18:51 |
erle |
jordan4ibanez wdym? |
| 18:51 |
erle |
i3 is a window manager? |
| 18:51 |
MTDiscord |
<jordan4ibanez> Gamer response? When your hardware is in historical documents it might be time to upgrade |
| 18:52 |
erle |
is it possible to tell the bridge i want to selectively ignore one user? |
| 18:52 |
[ |
ignores are client-side |
| 18:52 |
[ |
some clients have regex filters |
| 18:52 |
MTDiscord |
<jordan4ibanez> The gma 950 is 19 years old :D |
| 18:53 |
[ |
I actually do have a thinkpad t440p which supports opengl 4.6, but unfortunately it requires (neutered) intel ME and so isn't entirely an upgrade |
| 18:56 |
MTDiscord |
<jordan4ibanez> Well without minix there would be no Linux, and ME is Minix, so just think of it as a family reunion |
| 18:58 |
[ |
it's not minix in this generation yet, that started with skylake |
| 18:58 |
erle |
[ don't feed the troll |
| 18:59 |
[ |
it's threadx running on ARC |
| 18:59 |
erle |
[ IIRC when i found a bug in mineclone2 that crashed clamity, jordan4ibanez abused that bug and made a youtube video about it, “crashing clamity like a maniac”. |
| 18:59 |
erle |
(crashing the server is one of the few things that are forbidden on anarchy servers) |
| 19:01 |
erle |
[ given the generally unhelpful responses, i guess forking is the only reasonable response. |
| 19:01 |
|
chilledfrogs joined #minetest |
| 19:09 |
MTDiscord |
<jordan4ibanez> So you're going to redirect the fact that you're getting frustrated that your hardware that came out before windows vista was even a thought doesn't run minetest smoothly because you don't want to run Intel management engine by bringing up a mistake I apologized for? |
| 19:10 |
MTDiscord |
<jordan4ibanez> Let's put it this way, I realized I was erranous in my procedure and moved on, you're still using hardware that was out before "does it run crysis" was a meme, you're stuck |
| 19:12 |
MTDiscord |
<jordan4ibanez> The hypocrisy of using closed source hardware with one strawman in it to stand on your mighty hill and claim fsf approval is very sad |
| 19:13 |
MTDiscord |
<jordan4ibanez> It's quite obvious Intel needed that management engine, look at how their hardware runs without it |
| 19:13 |
[ |
what are you talking about? |
| 19:14 |
[ |
are you confusing the ME with microcode? |
| 19:14 |
MTDiscord |
<jordan4ibanez> You know exactly what I'm talking about, and if you don't, you shouldn't be so concerned about the management engine |
| 19:15 |
[ |
No, I don't. |
| 19:15 |
[ |
It doesn't run without the ME only because they intentionally made it not run without the ME |
| 19:17 |
MTDiscord |
<jordan4ibanez> Well actually, that brings up a great question. Why don't you get AMD hardware then? |
| 19:17 |
[ |
AMD is no better, in fact it's worse because there's no equivalent of me_cleaner for the PSP (AMD's ME equivalent) |
| 19:17 |
[ |
https://libreboot.org/faq.html#amd |
| 19:18 |
MTDiscord |
<jordan4ibanez> Another strawman |
| 19:18 |
[ |
How is that a strawman? |
| 19:18 |
sfan5 |
i think it's safe to say the freedom you're looking for is at a dead end on x86 |
| 19:19 |
MTDiscord |
<jordan4ibanez> Why not use arm64? There's plenty of support |
| 19:19 |
[ |
sfan5: There's a bug in MEv12 that allows arbitrary code execution in the ME. Someone just needs to write a free ME replacement and free raminit for kabylake. |
| 19:20 |
MTDiscord |
<jordan4ibanez> You know, and I know, and the person reading this knows, good luck with getting that in the next few years |
| 19:21 |
|
khimaros joined #minetest |
| 19:21 |
[ |
Most performant ARM hardware requires blobs. RK3399 can run blobless but it has worse single core performance than my core 2 duo and only supports 4GB RAM |
| 19:21 |
MTDiscord |
<jordan4ibanez> Well they're on version 16 of ME now |
| 19:23 |
[ |
The latest intel hardware is even worse: it requires nonfree firmware for the GPU |
| 19:23 |
MTDiscord |
<jordan4ibanez> So, you refuse to enjoy your hardware that can actually play the game, but you still use that hardware anyways |
| 19:23 |
MTDiscord |
<jordan4ibanez> So firmware is now an issue again |
| 19:24 |
MTDiscord |
<jordan4ibanez> Look at the firmware chips inside your current setup and go try to find any source code for them |
| 19:37 |
|
Lunatrius joined #minetest |
| 19:50 |
|
Glaedr joined #minetest |
| 19:56 |
|
ireallyhateirc joined #minetest |
| 19:57 |
ireallyhateirc |
can I do UV animation in Luanti? |
| 19:58 |
ireallyhateirc |
I for example have a color palette and clothes with colorful parts unwrapped in a way that places each part on a single pixel |
| 19:59 |
ireallyhateirc |
so with UV animation I could swap colors |
| 20:01 |
ireallyhateirc |
alternatively I could have atlas with multiple face variants and swap them |
| 20:25 |
MTDiscord |
<luatic> ireallyhateirc: not really, unfortunately. for the future, would you be able to leverage morph animations (https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#morph-targets) if we implemented them? |
| 20:26 |
ireallyhateirc |
I need to understand what they are first |
| 20:28 |
ireallyhateirc |
my use case is animating face textures all inside blender without having to redo the animations in Luanti |
| 20:29 |
ireallyhateirc |
so if the morph thing would allow me to do that then yes |
| 20:57 |
MTDiscord |
<_devsh_> You want programmable pulling for that |
| 20:59 |
ireallyhateirc |
programmable pulling? |
| 20:59 |
ireallyhateirc |
the current plan was to animate in Blender and write an addon to export the animations to Luanti somehow |
| 21:00 |
ireallyhateirc |
alternatively I could hide all eye/face textures in the head and control them with bones |
| 21:02 |
MTDiscord |
<_devsh_> Indirect draw is GL 4.x |
| 21:03 |
MTDiscord |
<_devsh_> In gltf every morph target is a separate set of vertex positions and normals |
| 21:04 |
MTDiscord |
<_devsh_> The animations can access any target arbitrarily and interpolate between them |
| 21:04 |
MTDiscord |
<_devsh_> You will run out of HW vertex attribute bindings |
| 21:05 |
MTDiscord |
<_devsh_> Also it's super wasteful to pump 8 or 16 attributes if you don't need them at a given moment |
| 21:05 |
MTDiscord |
<_devsh_> Hence "programmable vertex pulling" Google it, it's a well known term |
| 21:06 |
MTDiscord |
<_devsh_> You know you could just have a uint8_t vertex coordinate and sample a 1D texture or a texel Buffer instead? |
| 21:08 |
MTDiscord |
<_devsh_> I used to play WoW classic in the gma 950, that GPU is such a piece of shit it couldn't render WoW with a dx9 nor OpenGL backend properly |
| 21:09 |
|
SFENCE joined #minetest |
| 21:11 |
MTDiscord |
<_devsh_> Make a black hole render mode, conditionally omit every call to glDraw, then you'll see pure CPU overhead |
| 21:13 |
MTDiscord |
<_devsh_> Have you actually put a static variable counter next to the glUniform calls to find out how many times they get called per frame? Or a counter next to glUseProgram (or whatever GL 1.4-2.1 uses to bind a shader)? |
| 21:14 |
MTDiscord |
<_devsh_> Unless multiple (all) meshes share a buffer it might be just as bad as sending the bones with glUniform call |
| 21:15 |
MTDiscord |
<wsor4035> irc doesnt get context of what your replying to/edits fyi |
| 21:15 |
MTDiscord |
<_devsh_> That's unhelpful |
| 21:16 |
|
Verticen joined #minetest |
| 21:36 |
|
kamdard joined #minetest |
| 21:39 |
|
greeter joined #minetest |
| 21:57 |
|
lhofhansl joined #minetest |
| 22:03 |
erle |
<ireallyhateirc> alternatively I could hide all eye/face textures in the head and control them with bones |
| 22:03 |
erle |
i love how hacky that is |
| 22:05 |
MTDiscord |
<luatic> you can't because we only support linear animation |
| 22:05 |
MTDiscord |
<luatic> i considered bringing it up but that reason is why it's not an option |
| 22:06 |
MTDiscord |
<luatic> i will probably implement no interpolation for gltf soon though |
| 22:06 |
erle |
you will implement no interpolation? is this like the eastern block joke? |
| 22:06 |
MTDiscord |
<luatic> it's a feature where you can turn interpolation off on some channels |
| 22:07 |
erle |
sales person is asked “you don't have any meat, do you?” and answers “no, this is where we have no fish. the store across the street has no meat.” |
| 22:08 |
erle |
_devsh_ GMA 950 is plenty for rendering some virtual legos though. or playing earth 2150 or quake or whatever. |
| 22:09 |
erle |
luatic have you thought upstreaming your gltf work to irrlicht? not out of the good of your heart, but because then more people take a look at it (and maybe you get sth back) |
| 22:11 |
erle |
i made a self-igniting smelter in nodecore. the lenses redirect the light in a circle (this was difficult to achieve using only lenses) and ignite the fuel by means of focused lenses https://mister-muffin.de/p/YKDs.jpg |
| 22:12 |
erle |
(rendered using opengl 1.4? lol) |
| 22:16 |
ireallyhateirc |
@_devsh_, all that sounds advanced and I'm probably too dumb to comprehend that but sounds like a trouble |
| 22:17 |
erle |
i have also made a coal creation station: the focused lens sets the log on fire. logs float. coal is a falling block. coal falls into water and extinguishes: https://mister-muffin.de/p/fmCW.jpg |
| 22:18 |
ireallyhateirc |
sounds like the best solution for now is going to be waiting for non-linear animation and exporting face data to Luanti so it can then pick the proper face texture |
| 22:19 |
erle |
ireallyhateirc what mod/game are you working on? |
| 22:20 |
ireallyhateirc |
I'm an Exile contributor and the thing I'm working on is going to be for my WIP horror game called "Perfect City" |
| 22:20 |
ireallyhateirc |
there's nothing but a few nodes, a half-working road procedural generator and a story: https://codeberg.org/perfect_city_game_studio/perfect_city |
| 22:20 |
ireallyhateirc |
the story is also 10% finished |
| 22:21 |
ireallyhateirc |
that's one of the characters I'm working on currently: https://files.catbox.moe/icyrm2.png |
| 22:22 |
ireallyhateirc |
eyes and lips are implemented as a separate materials and textures |
| 22:23 |
ireallyhateirc |
(without "a") |
| 22:24 |
ireallyhateirc |
I'm a masochist so even the hoodie is rigged |
| 22:24 |
ireallyhateirc |
there's the "on" state when the hood tracks the head and the "off" state when the hood tracks the torso |
| 22:27 |
MTDiscord |
<_devsh_> @erle nobody will take a look at it except for CuteAlien |
| 22:28 |
erle |
ireallyhateirc what do you think of the mm3d modeler |
| 22:30 |
MTDiscord |
<_devsh_> Yes like 2000 Legos tops, if that's the look and aesthetic you want to stay with forever, that's cool. But don't expect to be able to do huge draw distances or fancy graphics on RTX 4060, ever. |
| 22:31 |
MTDiscord |
<_devsh_> In which case I invite you to delete the Shadow mapping code : P |
| 22:31 |
erle |
_devsh_ sorry, which view distance is like 2000 legos? |
| 22:32 |
ireallyhateirc |
erle, no idea what that is |
| 22:32 |
MTDiscord |
<_devsh_> I'm exaggerating, the gma 950 can probably draw like 200k tris |
| 22:32 |
MTDiscord |
<_devsh_> Let me pull up the spec sheet |
| 22:33 |
erle |
ireallyhateirc a 3d model editing program https://clover.moe/mm3d/ |
| 22:33 |
ireallyhateirc |
I'm using blender |
| 22:34 |
ireallyhateirc |
hard to judge just by looking at it, but looks obscure and most likely doesn't have as many features as blender |
| 22:35 |
erle |
ireallyhateirc definitely not. i just used it for some stuff regarding mineclonia |
| 22:35 |
ireallyhateirc |
blender is pretty straightforward and there is a ton of tutorials for it |
| 22:36 |
erle |
look, i am not trying to convince you to use anything else. i was trying to ask what you think of that program. obviously you think nothing of it. |
| 22:40 |
ireallyhateirc |
yeah, I understand |
| 22:41 |
ireallyhateirc |
looks really basic at first glance and that's it |
| 22:43 |
erle |
i think i used it to automatically merge surfaces |
| 22:43 |
erle |
because i noticed some model having way to many triangles |
| 22:44 |
ireallyhateirc |
yeah it's a common beginner mistake |
| 22:44 |
ireallyhateirc |
I once opened a sofa model from Sweet Home 3D |
| 22:45 |
ireallyhateirc |
the mesh had a really ugly topology and like 10 times the vertices needed |
| 22:45 |
MTDiscord |
<_devsh_> Erle, the gma 950 is a horrible GPU It's actually old enough for "shaders" to be slower than fixed function, because it doesn't have unified shader cores. It kinda claims 62.5M vertices per second peak throughput which mean about 500k block faces at 30 FPS. However such numbers are usually given for the most puny of vertices, so I'm kinda guessing that this 520k number is only valid for something like a position only attribute vertex |
| 22:45 |
MTDiscord |
and probably in some compressed 4 byte format not full 12 bytes per vert. So for crappy irrlicht format vertices this throughput is probably 9x less, and even if you did all the compression "right" you'd still come out at about 8 bytes per vertex. With the default irrlicht vertex format you won't get past a hard 64k Tri limit per frame on a gma 950. |
| 22:46 |
MTDiscord |
<_devsh_> By comparison a recent desktop GPU can draw somewhere in the order of 30-120M tris per frame |
| 22:47 |
MTDiscord |
<_devsh_> Without culling |
| 22:47 |
erle |
_devsh_ that sounds plenty for the amount of surface i am seeing in the game though? |
| 22:47 |
ireallyhateirc |
in blender I simply merge points by distance every now and then |
| 22:48 |
erle |
like, even if i pessimistically assume that 1 node is 6 triangles (because i see 3 faces) or 12 (because i see all the faces), it's plenty? |
| 22:48 |
MTDiscord |
<_devsh_> 64k is the triangle budget for a skinned character model in Gears of War, an Xbox 360 game |
| 22:49 |
erle |
sure buddy, but i am pretty sure that i haven't seen a 64k model in block game world, like, ever |
| 22:50 |
MTDiscord |
<_devsh_> Your worst case scenario is a diagonally sloped terrain which can't be greedy meshed |
| 22:50 |
erle |
also aren't high-poly models compiled down to low-poly models that have bump maps or so? |
| 22:50 |
MTDiscord |
<_devsh_> Yes but the high poly gears models were 12M tris |
| 22:50 |
erle |
actually my worst case scenario is lots of node boxes. i made the “studs” mod. |
| 22:50 |
erle |
it adds 4 small boxes to each node |
| 22:51 |
MTDiscord |
<_devsh_> Well anyway for that slope or checkerboard patter (one block up, one down) you get 3 tris per block |
| 22:52 |
ireallyhateirc |
my character is 17K tris for now, but I didn't remove redundant vertices yet (skin under clothes) |
| 22:52 |
erle |
yeah and at view distance 100 that entire pattern fits in the budget width a lot to spare? |
| 22:52 |
ireallyhateirc |
so I should be able to cut it down to 10K |
| 22:52 |
erle |
with |
| 22:52 |
MTDiscord |
<_devsh_> No your view distance caps out at 50 if you're still using a 36 byte vertex |
| 22:53 |
MTDiscord |
<_devsh_> 100 is best case with optimized vertex format |
| 22:53 |
erle |
_devsh_ guess i never ran into people who make the most pessimistic landscape |
| 22:53 |
erle |
well, people used particle spam lag to lag out clients |
| 22:53 |
erle |
and they used huge glass/water structures to lower fps |
| 22:54 |
erle |
but plain territory? nope |
| 22:54 |
MTDiscord |
<_devsh_> Well whenever your landscape is greedy meshed you have the polycount of mobs, particles and other stuff to worry about |
| 22:55 |
sfan5 |
<_devsh_> Have you actually put a static variable counter next to the glUniform calls to find out how many times they get called per frame? |
| 22:55 |
sfan5 |
just did. it's 750 |
| 22:57 |
MTDiscord |
<_devsh_> That's every glUniform call in the whole frame? |
| 22:57 |
sfan5 |
yes |
| 22:58 |
MTDiscord |
<_devsh_> Not bad, you might actually fit in a single UBO for the whole scene |
| 22:59 |
sfan5 |
nevermind I missed some |
| 22:59 |
sfan5 |
but it's not like most will stay static during the entire frame, will they? |
| 23:00 |
MTDiscord |
<_devsh_> Mind you that you still need to know what offset to use the UBO at, so this can often mean rebinding the buffer at a different offset or having to set at least one glUniform anyway |
| 23:00 |
sfan5 |
okay new figure: it's more like 1200 |
| 23:00 |
MTDiscord |
<_devsh_> No they will not stay static, your largest ones are the MVP and Normal matrices |
| 23:00 |
MTDiscord |
<_devsh_> They change almost every draw |
| 23:00 |
|
jaca122 joined #minetest |
| 23:01 |
MTDiscord |
<_devsh_> Also there's a few nasty thing that irrlicht does like abusing the uniform setting function for texture slot speccing |
| 23:01 |
MTDiscord |
<_devsh_> One should use explicit bindings and locations in the Glsl source |
| 23:04 |
MTDiscord |
<_devsh_> Erle the gma 950 has peak triangle rate of 41 Million, Adreno phone GPUs can routinely do 10-50x more |
| 23:04 |
sfan5 |
to verify my understanding: the main advantage of UBOs is for variables that stay the same when switching between programs? |
| 23:05 |
erle |
_devsh_ given that usually the naive way vs the optimized way to do something is like one or two orders of magnitude, maybe that is not important for a game that looks basically like it did 10 years ago? |
| 23:05 |
erle |
_devsh_ i don't know what you want to convince me of. i know more modern GPUs are faster/better/harder/stronger. |
| 23:06 |
erle |
i'm just not playing gears of war |
| 23:06 |
MTDiscord |
<_devsh_> If you want to keep that look and scale , why are you even looking into doing anything with irrlicht or shaders |
| 23:07 |
MTDiscord |
<_devsh_> Pick your best DirectX 8 or 9 emulator and go brrr |
| 23:08 |
MTDiscord |
<_devsh_> Sfan5 it's complicated, if you only use a few uniforms here and there and you don't dynamically index them, they can get preloaded as registers and GPU is happy and goes brrr |
| 23:08 |
erle |
_devsh_ actually i just want to continue playing one of the few games i enjoy and i hate that this means i have to backport API changes eventually. |
| 23:09 |
MTDiscord |
<_devsh_> In Vulkan land it's more explicit where the line is, you get 128 bytes of push constant data and that's it |
| 23:09 |
erle |
_devsh_ but i hope there are enough CSM API enthusiasts that it can be viable somewhat |
| 23:09 |
MTDiscord |
<_devsh_> Also you can't index arrays of push constants |
| 23:09 |
sfan5 |
I see |
| 23:10 |
MTDiscord |
<_devsh_> However each time you change them before a draw, the driver needs to make temporary copies |
| 23:10 |
MTDiscord |
<_devsh_> So it's kinda building something similar to a UBO behind your back |
| 23:11 |
MTDiscord |
<_devsh_> This is also explicit in vulkan because you have a command buffer and a pool that backs it and grows |
| 23:12 |
MTDiscord |
<_devsh_> But Vulkan is more sane, because the setPushConstans command is actually a memcpy |
| 23:12 |
MTDiscord |
<_devsh_> And in the shader your declare what struct variable lays at what offset |
| 23:13 |
MTDiscord |
<_devsh_> Whereas the dx9-10 and OpenGL way of setting uniforms is kinda like trying to serialise your push constants to JSON and driver unserialising back |
| 23:13 |
MTDiscord |
<_devsh_> As you obviously know you kinda have to call glUniform on each variable identifier separately |
| 23:15 |
sfan5 |
yea |
| 23:15 |
MTDiscord |
<_devsh_> As you can imagine a simple memcpy of 128 bytes (mind you, this is barely enough to fit MVP and Normal matrix) is a lot faster than sending each thing dword by dword or mat4 at a time |
| 23:16 |
MTDiscord |
<_devsh_> The other thing is that in GL driver guesses which uniforms benefit from being in registers more than others |
| 23:16 |
sfan5 |
so what I am gathering is it has advantages even if you have a big burst of changes before every draw |
| 23:16 |
MTDiscord |
<_devsh_> In Vk it's simple, shit with lower byte offset wins |
| 23:16 |
sfan5 |
(unless 20x glBufferSubData is just as bad as 20x glUniform?) |
| 23:16 |
sfan5 |
anyway, bed time for me |
| 23:16 |
MTDiscord |
<_devsh_> It's worse |
| 23:16 |
MTDiscord |
<_devsh_> Far worse |
| 23:17 |
MTDiscord |
<_devsh_> The optimum is actually to manage buffers explicitly |
| 23:17 |
MTDiscord |
<_devsh_> So you build one UBO for whole frame in your app |
| 23:18 |
MTDiscord |
<_devsh_> And you upload the draw data for all draws at once |
| 23:18 |
MTDiscord |
<_devsh_> But this requires rm irr/video/* |
| 23:20 |
MTDiscord |
<_devsh_> Since irrlicht has Uber rtrd coupling between the scene graph and drawing logic |
| 23:21 |
MTDiscord |
<_devsh_> It almost draws in immediate mode, seriously not far off glBegin and glEnd |
| 23:22 |
MTDiscord |
<_devsh_> You have to go in and change the way the drawcalls are emitted during scene graph traversal, sort them properly in the order of state change expense, etc. |
| 23:23 |
MTDiscord |
<_devsh_> Then do multiple passes over the draw lists, e.g. prep the shader constants first, then issue draws |
| 23:23 |
erle |
_devsh_ finally someone who shares my opinion on “changing materials often during drawing” |
| 23:23 |
erle |
(don't do it) |
| 23:23 |
sfan5 |
we do this kind of manual management for the map drawing |
| 23:24 |
MTDiscord |
<_devsh_> The way it's supposed to be done is that you produce a soup of draw call structs, sort, and then do gl calls |
| 23:24 |
MTDiscord |
<_devsh_> https://github.com/Devsh-Graphics-Programming/Nabla/blob/master/include/nbl/video/utilities/CSubpassKiln.h |
| 23:25 |
MTDiscord |
<_devsh_> Just sorting my drawcalls got me 25% FPS increase on a very simple sponza render in GL |
| 23:25 |
MTDiscord |
<_devsh_> And this was no culling, nothing |
| 23:26 |
MTDiscord |
<_devsh_> Even no frustum culling |
| 23:27 |
MTDiscord |
<_devsh_> Erle, that's standard practice and GDC presentations from 15 years ago were quite explicit about the fact your supposed to order your drawcalls by shaderid |
| 23:28 |
MTDiscord |
<_devsh_> Then stuff like textures bound |
| 23:30 |
MTDiscord |
<_devsh_> That way you can also optimise the state changes, like flip flopping between different depth testing modes, etc. |
| 23:31 |
MTDiscord |
<_devsh_> This is also why you should only have 1 or 2 transparent shaders and make sure particles use an array texture |
| 23:32 |
MTDiscord |
<_devsh_> Because if you sort particles (or just emitters), and then have to rebind the texture in between each billboard or even emitter... Rip |
| 23:32 |
MTDiscord |
<_devsh_> Obviously that whole problem goes away if you used order independent transparency |
| 23:33 |
MTDiscord |
<_devsh_> Because you no longer need to sort by depth and can focus on sorting by shader and pipeline state instead |
| 23:33 |
|
panwolfram joined #minetest |
| 23:34 |
MTDiscord |
<_devsh_> But order independent transparency is only possible with MSAA textures and weird sample shding tricks or multiple render target framebuffers for MBOIT or WBOIT |
| 23:35 |
MTDiscord |
<_devsh_> Also they're quite slow compared to the fancy methods in GL 4.3 using atomic images and other fun things |
| 23:47 |
MTDiscord |
<luatic> devsh: speaking of OIT, which methods would you practically suggest we try out? you can comment on #15436 if you'd like |
| 23:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/15436 -- Solving semitransparency: Order-independent transparency |
