Time Nick Message 00:13 hmmmm I believe we decided on a cutoff of high end 12 years ago I guess this is reasonable 00:14 hmmmm removing features just reminds me of nightmares where i needed that feature, and then it has dependencies that require the old version as well... but wait, those don't build because of some other dependencies that broke along the way... but you can't compile a couple of those dependencies because they require an older compiler... et cetera 00:14 hmmmm you need to recreate the entire toolchain from that era to effectively get what you need back 00:15 hmmmm for some applications it's harder, sure, (e.g. try building an old version of Chromium to practice exploit development, it's an adventure all by itself) 00:16 hmmmm it sucks that voxelland is dead because that would have filled the niche i am describing 00:16 hmmmm but yeh most people who would play minetest probably aren't using intel gma graphics anymore 00:18 hmmmm kinda wonder if any of this matters since somebody's gonna come along and rewrite minetest in rust 00:18 hmmmm lmfao 00:27 rubenwardy win32 is often used to play very old games for this reason 00:27 rubenwardy it doesn't break much 00:28 hmmmm well how about a compromise 00:28 hmmmm can somebody start creating/maintaining docker images with old stable releases installed? 00:29 schwarzwald[m] I'm awed that people have the time and dedication to maintain a project like this as is. If someone came and rewrote the thing to the same quality in Rust I would be mindblown. 00:30 hmmmm ohhhh you don't understand the depth of some peoples' obsession with rust 00:31 rubenwardy It doesn't have the same goals, but Veloren exists 00:31 schwarzwald[m] Someday people will hate Rust. 00:32 schwarzwald[m] Well, maybe not... I don't know anyone who hates C, come to think of it. 00:33 rubenwardy Hate is a strong emotion 00:33 hmmmm i hate rust 00:34 rubenwardy Try wk40 00:34 rubenwardy *wd40 00:34 hmmmm but i sorta have to deal with it because the writing's on the wall with linux's adoption of it 00:35 rubenwardy I haven't had much opportunity to use it but I've enjoyed what I've seen 00:36 MTDiscord I believe that minetest will be replaced with other voxel engine written in Rust rather than someone will rewrite it 00:36 MTDiscord It has too much legacy 00:36 hmmmm minetest IS the voxel engine 00:36 MTDiscord Yup, a voxel engine that will die one day 00:37 hmmmm but the games live on? 00:38 MTDiscord Nice of them will be rewritten for other engine 00:38 hmmmm yeah i could see that, but the way the API works might force the engine to work in a specific manner 00:38 MTDiscord Or someone will bother to add a compat layer 00:38 MTDiscord How many minetest games in active development do you know? 00:38 hmmmm not even a slightest clue 00:39 hmmmm the number of revisions i've made to the schematic format was like... 4... yet it required a ton of compatibility support 00:39 MTDiscord Their live cycle is rather small 00:39 MTDiscord *life 00:39 hmmmm it's likely that it would just be recreated using the new api for the new game engine than imported over 00:40 MTDiscord One day, people will consider engines other than minetest, and old games will just die 00:40 hmmmm that's not necessarily a bad thing i suppose 00:41 schwarzwald[m] It'd be nice to have some kind of roadmap for maintenance and feature work with estimates of priority and work required. 00:43 hmmmm as long as somebody makes an attempt to preserve the past (a manner like i described above would be sufficient imho), i guess i would find removing meshgen cache acceptable 00:44 MTDiscord Veloren looks quite nice actually. I'm impressed. 00:44 schwarzwald[m] What's the downside of keeping the feature? 00:44 hmmmm or what if you trim down meshcache for specific common meshes? 2 in particular 00:44 hmmmm a fully solid mapblock, and a fully empty mapblock 00:45 hmmmm downside to keeping the feature? none in my opinion, only time somebody will complain about it is when something doesn't work with it 00:45 MTDiscord Re: docker images with old versions, yeah, a few of us are already doing this. You just have to wait about 10 years for the versions we started on to become "old" too now. 00:46 MTDiscord In princple someone could extend the work backwards in time, but it would have to be somebody passionate about that history. 00:46 hmmmm if there are quirks that it happens with when paired with newer gpus, could just make a disclaimer 00:47 MTDiscord There is the standard downside to keeping any feature, of course, i.e. that you now have one more feature to maintain, work around when adding other things, wait for it to compile, deal with the potential for it to kick out bugs, etc. 00:47 hmmmm that's good that others have the foresight to keep a working copy of past MTs 00:47 hmmmm lmao you've already lost the compilation speed war by virtue of using C++ 00:47 hmmmm and making the system of header files a wreck 00:48 MTDiscord I've only ever seen like one or two really hardcore "archivists" who keep very old stuff in working order going way back in history, but I've seen a few people get really ancient MT versions to compile, and apparently they work fine. 00:48 schwarzwald[m] Why don't we fix the header system instead of axing the feature? 00:48 hmmmm i would begin to worry about compilation speed when it gets actually painful like a web browser 00:49 MTDiscord Even if you delete features or functionality wholesale, it will always be in the history, and deletions can always be reverted. 00:49 hmmmm erm you misunderstand, the header system is one of the systemic issues leading to slow compilation 00:49 hmmmm i'm not saying that's the reason for removing the feature 00:50 hmmmm yeah that's the argument i heard back then as well 00:50 hmmmm the thing is, out of sight == out of mind, and without old code being there (even block commented out with some #if 0s) people tend to forget what was tried, what didn't work, why not, and repeat history again 00:51 hmmmm the lineage of the code gets lost when the file gets split into new files as well 00:51 hmmmm git blame stops working, i've seen it with nerzuhl's first 'contributions' 00:52 hmmmm people run way too fast with scissors imho 00:52 MTDiscord If you're never willing to delete old features, then you basically discourage any developer from adding any new features, because you raise how certain they need to be that the new feature is really exactly what they want. Eventually you raise the bar high enough that you'll ONLY ever have old features. 00:52 schwarzwald[m] I'm suggesting focusing effort on improving the compilation as opposed to removing a feature. Although, improving the compilation probably isn't that pressing either. 00:52 hmmmm isn't that good?? could you imagine the linux kernel being developed like that? 00:53 MTDiscord you mean not developed? 00:53 MTDiscord Of course I can imagine it; I run Debian. 00:54 hmmmm no i mean, people keep repeating mistakes because they didn't know why feature XYZ wasn't that way to begin with 00:54 hmmmm the only reason why linux gets away with it I think is because there's just such a wide body of knowledge 00:54 hmmmm not so much with MT 00:54 rubenwardy It's silly to keep a feature with no affect that no one uses, if that is the case 00:54 schwarzwald[m] I don't care whether the feature is removed, but I'd like to find others who are willing to have some formal organization of work rather than doing things haphazardly. 00:55 hmmmm you need to put rules in place because nobody is going to be principled in their development otherwise 00:55 hmmmm everybody wants to add new stuff, nobody wants to maintain 00:56 hmmmm nobody wants to fix the microstudder they added when they so helpfully "fixed" some STL container usage 00:56 hmmmm nobody wants to write documentation or a story 00:56 MTDiscord Personally, I'd love to see some bugs get fixed, and some features we already have start to work well. I hear a lot of people talk about adding stuff that MT doesn't have, but I'd rather it complete delivery on a selection of existing promises first... 00:57 hmmmm which you won't get from this bazzar model of development 00:58 hmmmm I don't think it'll ever get high quality until there's actual funding behind it 00:59 hmmmm I think the best thing MT could do for itself as a project is to seek industry partners somehow. that one guy who wanted to product-ize MT by creating an educational game with a rich set of game assets seemed to be our closest bet 00:59 MTDiscord Bazzar model doesn't mean everybody develops new features only, it means everybody scratches their own itch. It's basically just a question of whether somebody will be bothered enough by something working half-ass to actually fix it. 01:00 schwarzwald[m] I turn on a couple aggressive warning flags and the list of warnings doesn't fit in my terminal history. People may argue that those warnings aren't indications of errors and some are false positives, but warnings aren't supposed to indicate errors, they're supposed to indicate code that is following patterns that often lead to errors. I think having so many warnings is an indication of sloppy work at a really fine-grained level. 01:00 MTDiscord I came pretty close to attempting a fix of the "ABM scheduler is trash" bug, but it went just a little too deep into the system for me to work on without risking actually learning C++ in the process. 01:00 hmmmm some of those warnings are bollocks though, in which case it's best to add a comiler flag or pragma to ignore them 01:00 schwarzwald[m] At a higher level, there's a big list of Coverity reports. 01:01 hmmmm Warr1024: No, practically speaking, nobody will care about fixing and maintaining aside from the overworked core devs who actually want to see MT succeed 01:01 MTDiscord Gamedevs 01:02 MTDiscord I've got 2 core issues that are holding my game back. 01:02 MTDiscord One of them, at least, it sounds like there's already core dev attention on 01:02 MTDiscord the other one, nobody seems interested in, so I went in to tackle myself, but I'm just not ready for it yet. 01:02 hmmmm gamedevs are gamedevs becaue they want an outlet for their creativity, I think most good ones are going to prefer making their own game instead of fixing somebody elses' 01:02 hmmmm oh, you mean developers for the MT games 01:03 MTDiscord Yeah 01:03 hmmmm yeah, that's one small demographic who would also help 01:03 MTDiscord Haha, how many of us are there? Like, 3 to 5 maybe? 01:03 hmmmm right 01:04 hmmmm you have no idea how guilty it makes me feel to just talk and not put in code myself while talking about how more people need to put in the code 01:04 hmmmm maybe one day after I retire lol 01:04 MTDiscord We periodically get drafted into core roles. Some "stick" and end up focusing on engine dev and then forget about their games, others end up staying with game dev and don't do as much core stuff. 01:05 schwarzwald[m] It comes down to a question of how much we are willing to invest in things like fixing warnings in order to maintain things long term. But I don't think we're putting too much effort into stuff like that rn. 01:05 MTDiscord I've only "soft" given up on fixing the ABM scheduler, myself :-D 01:06 hmmmm you know what I wanna see fixed in my lifetime? 01:06 hmmmm if i could only have one feature 01:06 hmmmm i wanna make envlock mostly go away 01:07 hmmmm maplock i mean 01:07 MTDiscord So, like, parallel access to the map? 01:07 hmmmm ye 01:07 hmmmm see I had this freaky concept long ago on how to make maplocks per-block 01:07 rubenwardy Rejoin as a core dev, fix that, and then retire and sleep happy 01:07 hmmmm using very lightweight sync primitives 01:07 hmmmm that would be something similar to RCU but not quite 01:08 hmmmm had the idea, but never coded it, and then got busy 01:08 MTDiscord Do you need to be a core dev? You can work on it without being a core dev, and you only need the core dev thing if you want to push the PR through with a 50% reduction in red tape. 01:08 hmmmm lol sure 01:08 MTDiscord but if you could eliminate that big of a lock, I think you'd have a pretty good case either way. 01:08 hmmmm yeah, next time I get that itch 01:08 hmmmm so has anybody done the active mapblock idea? 01:09 MTDiscord We got multiple Lua threads now, so I guess it would be interesting if the "worker" lua states could ask for mapblock locks independently 01:10 schwarzwald[m] Warr, I have a little time on Sundays I'd be willing to use for pairing on the ABM scheduler thing. I know the programming language at a basic level, and it sounds like you would have an idea of the algorithm perhaps. 01:10 MTDiscord I think I opened an issue for it long ago. It might be buried. It might have been closed with a half measure. 01:13 MTDiscord I want to stagger ABM runs across multiple globalsteps. Right now, when an ABM's timer goes off, it tries to batch every active mapblock into its queue and process them all in the current globalstep. I'd like to at least allow modders the option of spreading that out. It's a bit tricky because we run all ABMs per mapblock, not all mapblocks per ABM, so spreading them out is not so simple. 01:13 MTDiscord There are also implications, i.e. modders would have to opt IN, because some may have made the assumption that their ABMs run everywhere in one burst the way it is now. 01:14 MTDiscord It seems to me like we might need a queue of some kind, and I don't know the C++ standard library, or the preferred way to declare data structures like that, well enough. 01:14 MTDiscord I think I know the ABM system itself mildly well now; at least, I was able to successfully test my "pass all node positions to Lua in one table instead of calling the callback hundreds of times" thing. 01:15 schwarzwald[m] If the problem and solution are well specified, implementation should hopefully just be busywork. 01:15 MTDiscord Though that was "successful" in the sense of "prove that it actually didn't make a difference." 01:16 MTDiscord I'll have to read through the code again sometime to make sure I remember/understand how ABMs are scheduled right now. If I'm going to defer execution of anything, I need to have a good idea exactly what it is I'm deferring and what I can't. 01:16 schwarzwald[m] What's the behavior right now if the processing of the batched map blocks takes longer than the globalstep? 01:17 schwarzwald[m] Or maybe we don't know? xD 01:17 MTDiscord If you have a globalstep of 0.1, an ABM timer interval of 1.0, and an ABM time budget of 20%, then what happens is most of your globalsteps are 0.1 (assuming no other lag sources) but if you have heavy ABMs, then you'll get one step of like 0.25 or 0.3 when ALL the ABMs fire. I'd much rather use up 20% of each globalstep for ABMs instead, if I can swing it. 01:18 MTDiscord Default ABM time budget is 20%, and default ABM timer interval is 1.0s, so that means that ABMs run one big 200ms chunk once every second. For some servers, that's quite a big lag spike. 01:20 schwarzwald[m] Ah, so what happens is that all the ABMs run in 1 of every 10 globalsteps? 01:20 MTDiscord with default settings, basically, yes. 01:21 schwarzwald[m] And your idea is to spread the ABMs out over all the globalsteps to avoid those big spikes? 01:21 MTDiscord On my server, I run a step of 0.05, so I get most of my steps at that size except one step in the 0.2 to 0.25 range each second, and for some machines you can really see the timing judder, and it's quite distracting, and makes some things harder to do, like debugging in-game circuits. 01:22 MTDiscord Right. 01:22 schwarzwald[m] Sounds like a simple enough feature. "how hard can it be" 01:22 MTDiscord Right now, it runs something like 400 mapblocks in 0.2 seconds or something. If I could run like 50 mapblocks every 0.05 seconds, I'd be in good shape. 01:22 MTDiscord Well, I don't know how hard it can be, but I know at least some of how easy it can't be. 01:23 MTDiscord In theory I guess we could make it a global toggle, even, i.e. we don't need to allow modders to choose per-ABM whether to stagger or not, we could just allow a server owner to turn it on or off for all. Most server owners I know who muck about to try to fix ABM performance issues are making much more drastic changes already. 01:24 MTDiscord I've looked into some of the almost-alternatives for ABMs but they all have failure cases that only an ABM provides the full "eventually-reliable" firing necessary to recover form. 01:25 schwarzwald[m] > 20% of each globalstep for ABMs instead 01:25 schwarzwald[m] Doing literally this in the engine would probably be the simplest solution, right? But would break the behavior for people who want them to run intermittently? 01:26 schwarzwald[m] So we have to keep track of which ABMs use the old behavior, and which ones use the new behavior? 01:30 schwarzwald[m] Is that 20% default time budget already the time budget for ABMs in that particular globalstep run? Maybe this boils down to "do (if there's enough time budget) this ABM every x globalsteps" 01:48 MTDiscord Keeping track per-ABM would probably complicate the ABM system a lot. It might be enough to just make it a single global toggle. Then server owners can turn it on, try it out, and report to us what benefits or breakages they see. 01:49 MTDiscord It's possible that ABMs are written naively enough that they break ... but it's actualy likely that ABMs are generally written SO naively that they DON'T break because their authors never even tried to take the old behavior into account to rely on. 01:49 MTDiscord At least, a single global toggle might be the fastest way to start to get some field testing on it. 10:06 Wuzzy #11115 needs adoption. anyone interested? 10:06 ShadowBot https://github.com/minetest/minetest/issues/11115 -- Add support for single and dead-end raillike textures by Wuzzy2 10:30 Zughy[m] hmmmm: I do agree about the bazaar aspect and the educational funds (see kilbith, probably the one really earning money out of MT), but there is no common will. You ask sfan5 and Krock and they tell you they don't care about money. You ask c55 and you're lucky if they answer in the first place. You ask rubenwardy and he tells you that he'd like to, but that is complicated. You ask a few other core devs, and you realise they're not even 10:30 Zughy[m] active. So in the end things "just go" 10:38 Zughy[m] One positive thing is, at least now we have regular meetings every two weeks (next one is today) and PRs are going down. If we keep up the pace, this should allow the organisation to think about certain aspects within a reasonable future, as the ghost of PRs is a huge toll on development, I think (a ghost we've been exorcising) 10:40 Zughy[m] Talking about that, there are 4 "two approvals" PRs waiting to be merged. That will bring us to 68 PRs, another brand new record :) 11:40 pgimeno We got multiple Lua threads now, so I guess it would be interesting if the "worker" lua states could ask for mapblock locks independently 11:41 pgimeno last time I checked, Lua threads share a common environment and therefore are subject to a global interpreter lock 11:59 jwmhjwmh Lua "threads" share a common interpreter state, but Minetest runs its own async threads which have totally separate Lua states. 11:59 jwmhjwmh Merge #12833, #12810, and #12771 in 5m. 11:59 ShadowBot https://github.com/minetest/minetest/issues/12833 -- DevTest: Explain purpose of most items in tooltips by Wuzzy2 11:59 ShadowBot https://github.com/minetest/minetest/issues/12810 -- Improve documentation for `liquid_alternative_*` by Wuzzy2 11:59 ShadowBot https://github.com/minetest/minetest/issues/12771 -- add an 'equals' method to ItemStack and compatibility w/ lua '==' by fluxionary 12:01 pgimeno are these async threads with separate states a recent addition? 12:02 jwmhjwmh Pretty recent, I think they were added in 5.6. 12:03 pgimeno ok, I've been away for some months 12:12 pgimeno it's not in the changelog >.< 12:23 MTDiscord it is in the changelog: "Add Async environment for parallelized Lua code execution (sfan5) " (https://dev.minetest.net/Changelog#5.5.0_.E2.86.92_5.6.0) 12:34 pgimeno oh right 12:34 pgimeno thanks 14:45 jwmhjwmh Merging #12797 in 5m. 14:45 ShadowBot https://github.com/minetest/minetest/issues/12797 -- Optimize lighting calculation by TurkeyMcMac 14:57 Zughy[m] 68 PRs open. Trivia: last time there were so few PRs was 8 years ago. More precisely, 2014-08-30. That's a big accomplishment, if you ask me 15:11 sfan5 schwarzwald[m]: I don't see a reason to get rid of a reference couting in irrlicht and you also run into problems: in a scene graph that is not loop-free who owns what? 15:14 sfan5 re mesh cache: the mesh cache can speed up meshgen times, amount of vertices uploaded to the GPU doesn't change 15:16 sfan5 but it's also not enabled with smooth lighting so few people will have benefited in the last 5 years 15:17 MTDiscord So you're fine with removing it? 15:24 sfan5 I guess it could be removed 15:24 sfan5 is it broken? 15:30 MTDiscord Likely 16:49 sfan5 ok wtf 16:49 sfan5 can we please stop regressing graphics 16:49 sfan5 the brightness is all bright 16:50 sfan5 @x2048 16:50 sfan5 effectively smooth lighting is broken 16:51 sfan5 nvm just had that turned off 16:59 MTDiscord Can you share a screenshot of what's broken? 16:59 MTDiscord Brightness... 17:00 sfan5 https://a.uguu.se/WotOBUSY.png 17:01 sfan5 probably this https://a.uguu.se/rWATBkMZ.png 17:02 sfan5 (which ironically I approved) 17:11 Krock yes, it's too bright but thought it's due to me messing with the shader files 17:12 sfan5 pushing trivial fix 17:13 sfan5 on another note I don't know who considers that over-bright tonemapping good 17:31 schwarzwald[m] Warr, to clarify, does "global" mean the setting would apply to the entire API? What I'm thinking is that if the reason for having a setting is that we need backwards compatibility, making the setting apply across all mods means that mods that require the old behavior are incompatible with mods that require the new behavior. 17:34 Zughy[m] meeting time, amirite? 17:35 Zughy[m] no I'm not, nevermind 17:35 schwarzwald[m] What is the schedule for the dev meetings? I've observed that they're usually on Sunday. 17:35 Zughy[m] in 25 minutes 17:35 Zughy[m] every two weeks 17:38 jwmhjwmh Merging #12813 in 5m. 17:38 ShadowBot https://github.com/minetest/minetest/issues/12813 -- [NO SQUASH] Remove unused MapBlock functionality, in particular dummy blocks by TurkeyMcMac 17:49 Krock kind reminder that there's a meeting in 15 minutes. jwmhjwmh sfan5 @x2048 (pinging those who recently showed activity). the list is quite short today. 17:53 sfan5 I guess I'm present, haven't looked at the meeting notes yet 17:54 Krock me neither. concept discussion of 4 PRs 17:56 MTDiscord Can we also discuss ^ brightness? 18:00 Krock added 18:03 jwmhjwmh Should we begin? 18:03 Krock > #11432 18:03 ShadowBot https://github.com/minetest/minetest/issues/11432 -- Add support for attached facedir/4dir nodes by Wuzzy2 18:03 Krock First meeting point. Concept discussion? 18:04 jwmhjwmh See my comment there. I was wondering if there should be an attached_node variant based on the facedir axis. 18:04 jwmhjwmh Rather than the facedir face. 18:04 jwmhjwmh This could be useful for attached tree nodes and such. 18:05 Krock why can't it have the same format as facedir? 18:05 jwmhjwmh Then the log nodes would attach to nodes beside them. 18:06 jwmhjwmh Instead of under them. 18:06 Krock hmm 18:06 jwmhjwmh I workaround in this case would be to change the orientation of the tree textures or to use "wallmounted" logs. 18:07 jwmhjwmh But e.g. an attached chest would not work with wallmounted. 18:08 Krock the most generic method I could imagine is to provide a bitfield that specifies where to attach into each axis using the rotated coordinate system 18:08 sfan5 hm 18:08 sfan5 not sure about the feature as a whole but if people think there's enough usecases then that's fine with me 18:08 Desour you can express a rotated coordinate system using a facedir value 18:09 Krock with a bitfield you could attach to multiple nodes 18:10 Krock like a beam that's supported from both sides 18:10 Krock it goes into the direction of what jwmhjwmh suggests, but taking it further to allow any combination 18:11 jwmhjwmh A bit set could be represented in the attached_node group value, with one extra bit set to mark the format. 18:11 Krock why do you need to mark the format? 18:11 jwmhjwmh To distinguish it from other attached_node group settings. 18:12 sfan5 minus the placement prediction games could actually implement all this on their own 18:12 sfan5 so we should be wary of adding flexible but too complex formats 18:12 sfan5 (right?) 18:13 Krock it cannot get more complicated than that, I think. 18:13 Krock also yes, it does not strictly need an implementation in Minetest 18:14 Krock is this PR something that's wanted? 18:15 jwmhjwmh The PR can be left as-is then. I wasn't going to use the feature myself. 18:16 sfan5 I guess we should ask some mod authors to weigh in 18:17 jwmhjwmh This use-case could be solved with the bit set approach, I think: https://github.com/minetest/minetest/pull/11432#issuecomment-876841336 18:18 Krock everything but altering attached modes could be implemented with bitfields 18:20 Krock okay. I'll leave a link to the discussion there. modders are welcome to provide feedback there and proceed with the next topic 18:20 Krock > #12739 18:20 ShadowBot https://github.com/minetest/minetest/issues/12739 -- Add callback on_mapblocks_changed by TurkeyMcMac 18:21 Desour (for full flexibility, you'd also have to support OR, i.e. by using multiple bitfields for cnf or dnf) 18:21 Krock why do we need this? 18:21 sfan5 to reliably track when nodes change 18:22 Krock well yes, but mods trigger node changes themselves 18:22 Krock and there's also on_placenode callbacks 18:22 MTDiscord The linked issue gives you reasons 18:22 jwmhjwmh The example mod mesecons_detector2 is a fast version of the mesecons node detector. It can detect changes from voxelmanips, liquid, etc. 18:22 sfan5 well not for vmanips 18:23 jwmhjwmh Desour proposed an alternative API along the lines of "minetest.watch_area(pos1, pos2, func)" 18:23 jwmhjwmh This could also be used to implement mesecons_detector2 18:23 MTDiscord As someone that has made over 5 iterations of a replay mod for the last 4 or 5 years, I would greatly appreciate a more generic state watcher 18:23 jwmhjwmh Areas could be stored in an AreaStore 18:23 MTDiscord watch area is not generic enough 18:24 jwmhjwmh Is it OK if the API raises false positives? 18:24 MTDiscord The mapblock callback can let me watch any mapblock or I can limit it to an area myself. The inverse is not true for the watch area method 18:25 sfan5 making it not raise false positives is infeasible 18:25 Krock how would mods know what to watch for in these callbacks? 18:25 Krock specific nodes, as an alternative to ABMs? 18:26 jwmhjwmh The mod mesecons_detector2 uses the callback to trigger detector updates. It rechecks the detectors when the callback fires. 18:26 Krock there is no way to figure out what used to be there before the callback is executed without tracking the entire map 18:26 Desour > well not for vmanips are you sure sfan5? It'd make the callback unsuitable for node detectors 18:26 Krock I see. yes, for detectors it could make sense 18:26 sfan5 Desour: that was in response to "on_placenode" 18:26 Krock vmanip marks blocks as dirty 18:26 Krock ah I see 18:27 Desour ahh 18:27 MTDiscord Krock: ideally the callback would begin as soon as a block is slated to change. I would hope thats how it is implemented at least 18:28 sfan5 the callback runs after the fact 18:28 Krock no, mapblocks are already modified at that point 18:28 Krock you cannot trigger something before they're marked dirty 18:28 jwmhjwmh It would be hard to run the callback before modification. 18:29 Krock and somewhat uneffitient on top of that 18:29 MTDiscord Is the returned data only positions? 18:29 sfan5 yes 18:29 sfan5 the idea with the PR is that the engine already tracks this stuff so exposing it to Lua is free and has a great effect in terms of new possibilities 18:29 MTDiscord Alright then I change my opinion to indifference. 18:30 MTDiscord What exactly are the great new possibilities you speak of 18:30 jwmhjwmh In the PR description you can download an example mod mesecons_detector2. 18:31 Krock modders always found something to do with it 18:31 Desour if the callback is only called once per server-step ("at most", I guess the only way for this to be less often is if nothing changed?), does this actually have to be a callback? you could make a function to retrieve all blocks that changed since last server-step. mods can then pull the list of changed blocks on_globalstep 18:31 MTDiscord Is that mod not just a reimplementation of a thing we can already do? 18:31 Desour (+ core.is_block_dirty(pos) -> bool) 18:31 sfan5 it is 18:31 sfan5 for the first time there would be a way to actually receive a callback when a vmanip modifies a block 18:31 MTDiscord Krock: by that logic you should be merging every feature pr without a second thought 18:32 pgimeno what's the API for register_on_mapblocks_changed? it would be nice to mention it in the comments without needing to read the code 18:32 MTDiscord Alright, the vmanip point is a good one 18:32 sfan5 * `minetest.register_on_mapblocks_changed(function(modified_blocks, modified_block_count))` 18:33 sfan5 * `modified_blocks` is the set of modified mapblock position hashes. 18:33 sfan5 * `modified_block_count` is the number of entries in the set. 18:33 sfan5 now we should be on the same page 18:33 pgimeno thanks 18:34 jwmhjwmh Desour: core.is_block_dirty(pos) suggests the dirty marker is cleared at some meaningful point, when in fact it is just cleared on every server step. 18:34 MTDiscord Why do we need the count separately? 18:34 sfan5 lua has no efficient means of counting the number of keys in a table 18:34 Krock Desour: blocks are only dirty for a rather short time, so a normal function could result in missed updates when implementing a rate limit 18:35 MTDiscord Is it not an array? 18:35 jwmhjwmh It is a set of position hashes. 18:35 rubenwardy { [hash] = true } 18:35 MTDiscord Why this over a list, out of curiosity 18:35 rubenwardy I assume. Doc could be more specific 18:35 sfan5 a bit unusual but more efficient 18:36 jwmhjwmh It allows for fast checking of whether a mapblock has been modified. 18:36 Krock faster lookups than integer-indiced tables 18:36 MTDiscord Fair enough 18:36 Krock and yet there's only node hash positions and yet it's used to hash a mapblock 18:36 pgimeno mmm... does that mean it would be triggered for any change anywhere? that sounds busy 18:37 jwmhjwmh All changes on a single server step are collected into one step. 18:37 MTDiscord Thats the point 18:37 Desour jwmhjwmh: then `core.was_block_modified_in_last_server_step(pos) -> bool` (and `core.get_blocks_modified_in_last_server_step() -> map, count`) 18:37 Krock pgimeno: changes are bundled in batch for saving, and that's also where the callback should fire 18:37 jwmhjwmh Into one step, I mean. 18:37 sfan5 any change anywhere per mapblock (including changes that Lua couldn't even see) 18:37 jwmhjwmh One set, I mean, lol. 18:37 Krock (never mind actually it's at most once per server step) 18:38 sfan5 Desour: this has almost no advantages other that being confusing in regards to when do you have to call it 18:38 sfan5 when + how often 18:38 pgimeno providing a range on register sounds more reasonable to me; filling in long hash tables can potentially incur a performance penalty 18:38 MTDiscord Hmm, upon further thought, I realize I can manually track changes as long as I choose the area to watch. I have to save the initial mapblock state and then save the mablock state every time it changes. Could be expensive but it also could be worse 18:39 jwmhjwmh Desour: You could use `local my_modified = {}; core.register_on_mapblocks_changed(function(m) my_modified = m end)`, then use `my_modified` in a globalstep. 18:40 jwmhjwmh GreenXenith: maybe you could use mapblock_lib. 18:40 Desour ok, right, the callback is probably simpler and better 18:41 MTDiscord Once again +1 to the design then from me. Its generic enough and easy enough to understand. 18:41 sfan5 not being able to tell what changed or how the MB was before is indeed annoying 18:42 sfan5 but at least with this you can choose to watch an area and bring your own manual tracking 18:42 MTDiscord I fear tracking the changes themselves is beyond the scope of this feature, or at least the pr 18:43 MTDiscord it is, change tracking can be done in a few ways outside this API 18:43 jwmhjwmh pgimeno: I doubt _that_ many mapblocks will be modified per globalstep, and making mapblock hashes should be fairly cheap. 18:44 Krock hmm. on a busy server with 20 players you surely get at least 20 mapblocks per tick 18:44 Krock be it just for ABMs 18:44 Krock or other metadata updates 18:44 sfan5 maybe ask pandorabox people how many written mapblocks to db they get 18:44 Desour I wonder if it is more performant to build a lua hash table in C++ or to build an array and then make it to a hash table in lua 18:44 sfan5 IIRC there's already stats for this 18:44 pgimeno 20 is reasonable; 500 could be troublesome 18:44 sfan5 via prometheus I mean 18:44 pgimeno on top of that, the table passed is engine-generated, so it generates garbage 18:45 MTDiscord @BuckarooBanzai 18:45 sfan5 and all modified mapblocks get written (instantly?) so that figure should be accurate 18:45 MTDiscord This is a callback you should expect to be called in excess, which is not a bad thing. Just needs to be efficient 18:45 Krock pgimeno: depends on how much the ABMs do. oh right. liquid flow too. and mapblocks with technic nodes will pretty much fire every globalstep unless metadata changes are ignored 18:46 jwmhjwmh Metadata changes are included. 18:46 pgimeno there isn't an option for providing your own table to fill, like some functions (was it noise?) do 18:46 Krock so yes, a hundred mapblocks per tick isn't too far off 18:47 Desour Krock: technic runs on abm step, afaik 18:47 Krock Desour: yes, it's the switching station that does it each second 18:48 Desour (so, once per second by default, not once per server-step) 18:48 rubenwardy builtin could have a table for reducing garbage 18:48 Desour how do you clean the table? 18:49 jwmhjwmh LuaJIT has table.clear() 18:49 sfan5 since the hashtable is the table itself there shouldn't be any garbage except for the table object 18:49 sfan5 would be very different with a list of vectors 18:50 jwmhjwmh Yes, reusing the table might be micro-optimization. Minetest does a bunch of other allocation anyway. 18:50 sfan5 i think we're getting a bit off-topic though 18:51 Krock maybe let's keep this for now and go to the next topic? 18:52 sfan5 sure 18:52 Krock because I do not see any clear progress any more 18:52 Krock > #12611 18:52 ShadowBot https://github.com/minetest/minetest/issues/12611 -- Implement some VoxelManip functionality safely using LuaJIT's FFI library by TurkeyMcMac 18:52 Krock > Decide whether the added complexity is worth it. 18:53 jwmhjwmh I measured a speed up of almost 2x with this change to get_data etc. 18:53 jwmhjwmh But it requires duplicating the implementations. 18:53 sfan5 tending towards -1 from my side 18:53 Krock well I'd say No. the API is supposed to work with LuaJIT and Lua the same way 18:53 Krock also yes, code duplication and hence more maintenance efforts to keep it in sync and working well 18:54 jwmhjwmh It does add pretty extensive unit tests for the API. 18:54 sfan5 hm 18:55 Krock I also implemented functions for FFI into Minetest as an experiment and it did indeed work pretty well 18:55 Desour get_node can be made so fast that checking whether a node is near with get_node is almost as fast as get_nodes_near, last time I tried, btw. 18:56 Desour it would be nice if we had a C api that we call from both C lua and luajit ffi, for consistency 18:59 Krock rubenwardy: if you're around - do you have an opinion on this? 18:59 rubenwardy didn't we try this years ago, and find no performance improvement? 19:00 MTDiscord Q: what is the biggest benefit from the faster voxelmanip? 19:00 jwmhjwmh Mapgen, mesecons 19:00 MTDiscord probably worldedit as well? 19:01 Krock schematic placement relies on it too 19:01 sfan5 schematic placement is C++ 19:01 Krock or was it only trees? well, I don't remember 19:01 sfan5 this is only for voxelmanip interaction with lua, is it? 19:01 Krock ah yes, internal vmanip. I got confused 19:02 jwmhjwmh Their total speed probably would not increase enormously from this change, since get_data is only part of the cost. 19:03 Krock #6863 19:03 ShadowBot https://github.com/minetest/minetest/issues/6863 -- Add LuaJIT FFI-friendly memory-intensive functions 19:03 Krock that was pgimeno's original PR 19:03 Krock well great. the diff is gone 19:03 pgimeno I also made this mod: https://notabug.org/pgimeno/ffi_accel 19:04 pgimeno and the diff is available in notabug I believe 19:04 pgimeno https://notabug.org/pgimeno/minetest/pulls/2 19:06 pgimeno I was told that ffi_accel greatly accelerated mapgen 19:06 pgimeno even though it's very restricted due to security concerns 19:07 jwmhjwmh My PR still requires copying to and from the VM buffer, since it is designed to be used transparently by untrusted mods. 19:09 pgimeno the mod was about transparent replacement; 6863 was about a new faster way of doing things, but the mods using it would need to be trusted 19:10 hmmmm wow :D 19:11 hmmmm what is the security concern in question now? this seems like something new, i guess mods can be 'trusted' or 'untrusted'? what is the privilege trusted mods have exactly? 19:11 Krock restrictions on "os" and "require" functions that could potentially execute harmful code 19:11 hmmmm if it's about writing raw memory to a buffer in the process, it's not like that can't be handled with some bounds checks (but I suppose that defeats the purpose of this PR) 19:12 hmmmm well it's not like the mods that are using this functionality also have privileges to "os" 19:13 pgimeno in raw FFI (6863) there are no possible bounds checks, that's why it's fast 19:13 hmmmm since they are executing in different modules that did not import 19:13 hmmmm i am really glad somebody is making luavoxelmanip better 19:14 Desour hmmmm: 12611 doesn't need trust, it implements part of the API using luajit's ffi lib. the implementation must not have bugs though 19:14 Krock if there's FFI for normal Lua we could switch to the FFI variant althogether? 19:15 hmmmm i support the concept, but id need to put in real work into reading up on the mechanisms being used here to do a code review 19:15 hmmmm sorry i can't be more useful :p 19:15 jwmhjwmh https://github.com/facebookarchive/luaffifb 19:16 Desour Krock: there is, eg. https://github.com/q66/cffi-lua 19:16 hmmmm or was it only trees? well, I don't remember 19:16 pgimeno Krock: technically there is, I believe Facebook implemented one, but it's not worth it - it's about speeding up access, and PUC Lua FFI performs poorly 19:16 hmmmm i'm sure there are mods that use lua for trees that they want to make not using the l-system or schematics 19:16 pgimeno in facebook's implementation there was an incompatibility with nil being the null pointer I believe 19:16 hmmmm i just added those into the core because those seem like the most common use case 19:18 pgimeno I don't have time to look into 12611 for now, maybe I can review it in future 19:18 Krock well I don't know what to do with that PR 19:18 Krock > #12449 one more? 19:18 ShadowBot https://github.com/minetest/minetest/issues/12449 -- [No Squash] Use .md extension for markdown files by rubenwardy 19:18 hmmmm hmmmmmmmmmmmm.... tbh I think the requirement to remain secure should fall onto the mod writers who use FFI 19:19 rubenwardy We have a mod sandbox, it's important not to just add holes in it 19:19 hmmmm if you wanted to exploit minetest clients i'm pretty sure that's easy enough seeing as how you got ppl like nerzuhl running around making packet deserialize functions vuln as fuck 19:20 hmmmm ahaha kidding 19:20 hmmmm but MT seems like such a soft target 19:20 hmmmm ye idk then ruben, but 2x speedup seems too appetizing 19:20 MTDiscord MT makes up for its weakness to attack by offering relatively little value to attackers. 19:21 hmmmm true 19:23 MTDiscord It does not justify designing for vulnerability though. 19:24 hmmmm do we actually know that there is a vulnerability or is the concern with the added surface area? 19:25 rubenwardy This PR looks like it should be fine as it doesn't expose the ffi interface to mods, just upgrades the APIs to use it 19:25 jwmhjwmh AFAIK my PR does not introduce a vulnerability. 19:26 MTDiscord I think the concern is with putting the basic security requirements on the mod authors. This PR does not do that. 19:27 Desour the concern is mostly about attack surface. and minetest makes it hard to securely use the insec env, especially with mods having access to debug stuff, it's a bit less bad in builtin at least because no other mod loaded before 19:28 hmmmm > #12449 good to merge 19:28 ShadowBot https://github.com/minetest/minetest/issues/12449 -- [No Squash] Use .md extension for markdown files by rubenwardy 19:28 hmmmm i don't think increased attack surface alone is reason enough to block something substantial 19:29 hmmmm if there is a vulnerability, it'd get patched, and then we move onward 19:29 hmmmm you don't see people whining about support for emojis because it pulls in libjpeg 19:30 Desour I wish we had something more searchable than txt or md. I hate those `See "Nodes"` comments. without case-sensitivity, there are about 181 matches for "nodes" 19:31 MTDiscord md should allow references 19:31 hmmmm i feel like a lot of these concerns are a bit perfectionist 19:31 hmmmm this is an upgrade from where we are now 19:31 MTDiscord I vaguely remember that [Nodes] might work (if there is an appropriate header); otherwise [Nodes](#nodes) can reasonably be expected to work 19:32 hmmmm as long as you are not working backwards, it's ok if a PR doesn't include the kitchen sink too 19:32 hmmmm maybe you can add the references 19:32 MTDiscord AsciiDoc is the format we went with for the docs project 19:32 rubenwardy Desour: Using MD would allow linking to Nodes directly 19:32 rubenwardy As others have said 19:33 rubenwardy GitHub also lets you search the table of contents, and a lot of IDEs allow that as well (it's often called "structure") 19:33 rubenwardy (or symbols) 19:34 MTDiscord BTW Desour, just grep for # Nodes; as long as the heading doesn't use setext-style you'll be fine 19:34 rubenwardy Most of the doc is setext style lol 19:34 MTDiscord we should also switch all our headings to ATX-style (#) 19:35 MTDiscord rubenwardy: then it's probably poorly structured, because setext-style only works for levels 1 & 2 19:35 MTDiscord that'd be plenty of top level headings 19:35 Desour Nodes is also the text style https://github.com/minetest/minetest/blob/b3503e7853a52a8c16431f6b983e30c9d25951bc/doc/lua_api.txt#L1008 19:36 MTDiscord argh 19:36 Krock it does not matter. you can use [Nodes](#nodes) to link there 19:36 Krock or at least that should work 19:37 Desour I guess md is an improvement ¯\_(ツ)_/¯ after all, we are we are already writing it in markdown format 19:38 Desour but in the long run, I would really like to see something nicer, like ldoc (I've made pretty good experiences with it ) 19:38 hmmmm oh so you're volunteering eh 19:39 Desour not now, but I'm trying to manipulate peoples' minds in the long run 19:40 hmmmm i know that feeling lmao 19:40 MTDiscord ldoc is unfortunately about the only option unless you write your own 19:40 Desour after all, it's not in the roadmap and making a contribution would only lead to wasted work 19:40 hmmmm i was sort of hoping somebody else would make the active mapblock idea a reality 19:40 MTDiscord writing my own is on my TODO list tho hehe 19:41 hmmmm that + fixing mapgen + breaking down maplock were the three big things i wanted to accomplish 19:42 Desour luatic: or fork it to add more features and fix bugs 19:42 MTDiscord Looks like .md extension is accepted. One note though is that Discord bots (and any other bots) will need to be adjusted. 19:42 MTDiscord Do we move on? 19:46 MTDiscord Desour: I don't like the style of it; I want my doc comments to be at the appropriate places (e.g. param comments next to params, return comments next to return statements, function description next to function definitions) 19:46 Krock @luatic: I think it would be best to state your concerns in the PR 19:47 Krock if that's related to the .txt -> md transition 19:47 Krock > final topic: Shader brightness issue 19:47 MTDiscord Krock: I am pro the txt -> md transition 19:47 Krock @x2048 on recent Minetest versions, the terrain is somewhat bright with only shaders enabled 19:48 Krock sfan5 did propose a patch earlier on. is the discussion about this, or am I mistaken? 19:49 MTDiscord > sfan5: on another note I don't know who considers that over-bright tonemapping good 19:50 MTDiscord This is what I want to discuss. 19:50 Krock mhm. yes, it's indeed very bright. the texture colors are no longer reflected properly (at least at sunlight levels) 19:51 MTDiscord IIRC the tone mapping function is literally just a naive color curve applied statically to the rendered scene. When I heard about it, what I had hoped for was something more dynamic, e.g. taking average brightness into account and e.g. auto-adjusting for dim scenes and such. I am not sure what actual use the original shader actually served other than as e.g. a placeholder and proof of concept? 19:52 MTDiscord Bloom PR converts all PP into linear color space, assuming that 3D step rendered in sRGB 19:52 rubenwardy It's probably worth making sure it's implemented correctly, in terms of how it works in other games 19:53 MTDiscord Adding bloom, godrays etc. on top will make some areas overbright, and this is where some tonemapping helps. 19:53 rubenwardy Isn't tone mapping designed to implement fake HDR? Or am I thinking about something else 19:53 MTDiscord Not fake, 19:53 rubenwardy "auto adjusting for dim scenes" sounds like fake HDR 19:53 MTDiscord Fake HDR is what it should have done but I don't think our implementation even attempts that. 19:53 MTDiscord tonemapping maps from HDR colors of rendering into sRGB of the display 19:54 MTDiscord It's "fake" in the sense that we don't actually have enough precision to do it properly 19:54 rubenwardy Software HDR then, as contrasted to hardware/display HDR 19:54 MTDiscord Bloom adds exposure control via settings. You can so /set exposure_factor 0.5 in your single player 19:54 MTDiscord /set exposure_factor auto is what I'd want :-) 19:55 MTDiscord My point: the previous tonemapping code added 2.5 to the exposure, probably to make a fake HDR 19:55 MTDiscord like, sample overall brightness from the scene (possibly smooth it over time) and adjust the tone map to bring the dominant brightness closer to the middle. 19:55 MTDiscord I kept that factor here: https://github.com/minetest/minetest/blob/master/src/client/renderingengine.h#L51https://github.com/minetest/minetest/blob/master/src/client/renderingengine.h#L51 19:55 MTDiscord But I'd like to remove it 19:56 MTDiscord It will make entire scene dimmer by default, i.e. change for the players. 19:56 MTDiscord But it will make my life, gamedev and TP designer life easier 19:56 MTDiscord I currently play with shaders off most of the time. If you had HDR support in screen-space (cheap enough) then that would probably be enough to get me to turn it on. 19:58 MTDiscord Consequently, I have my game tuned based on whatever the rendering looks like with shaders completely off (dunno if that's linear or not?) 19:59 MTDiscord If the game experience got overall darker, that'd force me to redo a bunch of art and make me quite unhappy. If we had HDR and it auto-adjusted for it and boosted stuff back into a good range, then I'd probably be cool with that :-) 19:59 MTDiscord Shaders off is sRGB and weird math around voxel lighting. 20:00 MTDiscord I don't think removing 2.5 factor will be darker than w/o shaders. 20:00 MTDiscord Though, "voxel lighting" would just mean "mulitply colors by some brightness <1" with the brightness function itself being that weird gamma curve thing that MT does, right? 20:01 MTDiscord What setting is that 2.5 thing tied to, just the "Shaders" base option, or tone mapping, or bloom? 20:03 MTDiscord Ideally, regardless of the shader options you pick, the default overall brightness of MT across all scenes shouldn't change compared to the no-shaders option, at least to me. 20:03 MTDiscord If they differ, regardless of which one you consider "correct", people will adjust their images for one way or the other, and it will look wrong to any players who play the other way. 20:04 MTDiscord At least, any settings that we put on the "Settings" panel in the main menu shouldn't so drastically alter the appearance of the game that it would be considered "breaking" for anyone who expects a reasonably faithful rendering of their visual art. 20:05 MTDiscord I'd like to share the screenshots. Can I just paste them in Discord? 20:06 MTDiscord they should just get a discord cdn link they can view 20:06 MTDiscord Thank you 20:08 MTDiscord @Warr1024 It's designed to affect bloom and tonemapping. 20:09 MTDiscord Fector 2.5 w/ tonemapping 20:09 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028761213884182568/Screenshot_20221009_220813.png 20:12 MTDiscord Without tonemapping 20:12 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028761781801328723/Screenshot_20221009_221119.png 20:12 MTDiscord Without shaders 20:12 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028761954396942447/Screenshot_20221009_221226.png 20:14 MTDiscord Factor 1.0 with tonemapping 20:14 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028762338775547914/Screenshot_20221009_221353.png 20:14 MTDiscord what about #12843 ? 20:14 ShadowBot https://github.com/minetest/minetest/issues/12843 -- Add modslist formspec for /mods command. by Andrey2470T 20:16 MTDiscord So the question of brightness is - do we change default tonemapping behavior from image 1 to image 4? Players can use exposure_factor setting to set the exposure correction they want. 20:27 MTDiscord Hmm ... do you have a scene that shows contrast across the spectrum, e.g. a mix of dark and light areas? Tonemapping making things "brighter" is what I basically expected from an already-brighter-than-midtone scene to begin with... 20:27 MTDiscord but out of the ones you posted so far, image 1 does look the "most wrong" to me... 20:45 schwarzwald[m] Has the meeting ended? It's been twenty minutes since the last comment. 20:47 rubenwardy I guess so 20:48 schwarzwald[m] Desour: I made the change across all of Irrlicht to handle mesh lifetimes using a shared_ptr, but it infected the public interface that Minetest uses, and Minetest doesn't build anymore after the change. 20:49 schwarzwald[m] If anything like that is going to be done, it will not be limited in scope just to Irrlicht's internal implementation, unfortunately. 20:52 MTDiscord I would still appreciate opinions from coredevs on the default exposure for tonemapping, now that exposure control is a thing. 20:52 sfan5 2.5 is just too much imo 20:55 MTDiscord I'd suggest going with 1.0 by default, as it matches the no-shader level, and it makes math easier. 20:55 sfan5 wait are we discussing how it should look like with when the user chooses to enable tonemapping? 20:55 sfan5 or new defaults? 20:56 MTDiscord We are discussing how it will look by default with tonemapping. Players can tune exposure_level to make it brighter or darker. 20:57 sfan5 ok 20:57 sfan5 my opinion probably doesn't count for that since I never enable tonemapping nor am I planning to 20:57 MTDiscord The image 1 is the current default, image 4 is the new proposed default for tonemapping. 20:57 MTDiscord 2 and 3 for reference without tonemapping / shaders. 20:58 MTDiscord Tonemapping is a must for bloom, dynamic light, godrays etc. 21:02 MTDiscord Another set of images: 21:02 MTDiscord No shaders: 21:02 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028774431029469194/Screenshot_20221009_230146.png 21:02 MTDiscord Tonemapping, Factor 1.0 21:02 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028774521668386896/Screenshot_20221009_230113.png 21:02 MTDiscord Tonemapping, Factor 2.5 21:02 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028774585451159572/Screenshot_20221009_230122.png 21:03 sfan5 1.0 looks kinda dull, what about 1.5 or such? 21:05 MTDiscord What if the game can control the value? 21:07 sfan5 the game should be able to anyway 21:07 MTDiscord Here is 1.5 21:07 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028775669427097610/Screenshot_20221009_230522.png 21:07 MTDiscord I'd leave 1.5 to MTG then, as it will be different between the games. 21:12 MTDiscord BTW, having a factor of 1.5 is the same as saying that top 33% of all color values is overexposure. 21:19 MTDiscord Here is a different texture pack 21:19 MTDiscord No shaders 21:19 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028778849636450304/Screenshot_20221009_231044.png 21:20 MTDiscord Tonemapping, Exposure 1.0 21:20 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028778946818478121/Screenshot_20221009_231503.png 21:20 MTDiscord Tonemapping, Exposure 1.5 21:20 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1028778992561569842/Screenshot_20221009_231740.png 21:21 MTDiscord Tonemapping will always tone-down colors from textures, because it reserves higher color values for 'HDR' part => tonemapping an SDR image will always make it 'dull'