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