| Time |
Nick |
Message |
| 00:22 |
|
imi joined #minetest-dev |
| 00:47 |
|
GreenXenith joined #minetest-dev |
| 02:43 |
|
whitepaperkat joined #minetest-dev |
| 03:24 |
|
Noisytoot joined #minetest-dev |
| 03:27 |
|
EthanHunt joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:46 |
|
Warr1024 joined #minetest-dev |
| 08:56 |
|
grorp joined #minetest-dev |
| 09:30 |
grorp |
merging #14636 in 10 min |
| 09:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/14636 -- Fix crash if zip file cannot be opened by grorp |
| 11:34 |
|
GreenXenith joined #minetest-dev |
| 11:47 |
MTDiscord |
<herowl> If any coredevs approve, I'd like #14343 and #14543 to be discussed in the upcoming meeting. |
| 11:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/14343 -- Ambient light and server control for it by Andrey2470T |
| 11:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus |
| 11:59 |
|
MisterE123 joined #minetest-dev |
| 12:01 |
MTDiscord |
<luatic> sure, we will discuss them |
| 12:10 |
sfan5 |
merging #14637, #14641 in maybe 10m |
| 12:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/14637 -- Add option for random mod load order by chmodsayshello |
| 12:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/14641 -- [no sq] GL fixes by sfan5 |
| 12:25 |
MTDiscord |
<luatic> sfan5: you can merge your MTG PRs too btw |
| 12:30 |
sfan5 |
ah yeah I forgot |
| 12:58 |
|
Niklp left #minetest-dev |
| 12:59 |
|
Niklp joined #minetest-dev |
| 14:55 |
|
srifqi joined #minetest-dev |
| 15:02 |
srifqi |
hello |
| 15:02 |
MTDiscord |
<luatic> hi |
| 15:04 |
srifqi |
it's been a while since my last time joining the meeting (synchronously) |
| 15:06 |
MTDiscord |
<luatic> is Krock / SmallJoker present? |
| 15:06 |
MTDiscord |
<luatic> i'll also ping @rubenwardy and @nrz0 / nerzhul in case they'd like to join |
| 15:07 |
srifqi |
Krock is still away since hours ago, it seems like, from the IRC status |
| 15:18 |
MTDiscord |
<luatic> seems it's just us two (?); would you like to start anyways? |
| 15:18 |
srifqi |
yes |
| 15:19 |
srifqi |
should we start by discussing the two PRs mentioned a few hours ago? |
| 15:20 |
MTDiscord |
<luatic> I'd first discuss #14574 since we're both involved there |
| 15:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/14574 -- Translation updater: Add support for function call without parantheses by srifqi |
| 15:20 |
srifqi |
ah, that's true |
| 15:20 |
MTDiscord |
<luatic> you're right that the way captures work makes my suggestion of merging this into fewer patterns awkward to implement |
| 15:21 |
MTDiscord |
<luatic> i'd still like it if the pattern could be constructed out of the "parts" that make it up |
| 15:21 |
MTDiscord |
<nrz0> Sorry doing homework with children |
| 15:22 |
MTDiscord |
<luatic> carry on π |
| 15:22 |
MTDiscord |
<luatic> srifqi: roughly as your comment, but less verbose |
| 15:22 |
MTDiscord |
<luatic> i think this can be achieved by defining one or two functions |
| 15:23 |
srifqi |
functions to construct what? |
| 15:23 |
MTDiscord |
<luatic> the patterns |
| 15:23 |
MTDiscord |
<luatic> i'm thinking something like def parenthesize_pattern(pat): return r'\(\s*' + pat + r'[\s,\)]' for one |
| 15:24 |
sfan5 |
planning to push https://github.com/minetest/minetest_game/commit/1ce48351ea7b1586710c1e60e863e94ed06e2721 to MTG later |
| 15:25 |
MTDiscord |
<luatic> sfan5: π |
| 15:25 |
sfan5 |
also hi |
| 15:25 |
srifqi |
hello |
| 15:25 |
MTDiscord |
<luatic> srifqi: and def compile_func_call_pattern(arg_pattern): return re.compile(r'(?:^|[\.=,{\(\s])' + r'N?F?S\s*' + arg_pattern, re.DOTALL) |
| 15:26 |
MTDiscord |
<luatic> then the 4 regexes can all be constructed using these 2 functions |
| 15:27 |
srifqi |
ah, i see. i will try that |
| 15:28 |
MTDiscord |
<luatic> that'd be all regarding that then |
| 15:29 |
MTDiscord |
<luatic> let's move on to #14343 |
| 15:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/14343 -- Ambient light and server control for it by Andrey2470T |
| 15:30 |
srifqi |
to be honest, i haven't read that two PR mentioned before the meeting |
| 15:31 |
MTDiscord |
<luatic> that's fair |
| 15:31 |
MTDiscord |
<luatic> i assume grorp will serve as a second reviewer for the ambient light PR, given his recent review |
| 15:32 |
srifqi |
he's also assigned himself for that PR |
| 15:32 |
MTDiscord |
<luatic> ah yeah good |
| 15:33 |
MTDiscord |
<luatic> the current status is: there is a bug with hardware colored nodes. and an inconsistency when shaders are disabled. |
| 15:33 |
MTDiscord |
<luatic> herowl / nauta-turbidus has tried to fix the former, but it looks like there may still be an issue if brightness is changed via hardware coloring. |
| 15:34 |
MTDiscord |
<luatic> it seems likely to me that what hybriddog suggests (separating the two variables) is the only way to fix this properly. |
| 15:36 |
srifqi |
so, the formula needs more data for its input? |
| 15:37 |
srifqi |
which variables need to be separated? |
| 15:38 |
MTDiscord |
<luatic> yes, more vertex data specifically. light and hardware color would need to be separated. (see hybriddog's comment: https://github.com/minetest/minetest/pull/14343#issuecomment-2106196902) |
| 15:39 |
MTDiscord |
<luatic> we could consider packing them in the same variable if precision allows however. hardware color should be 8-bit per component; the precision of light color could be reduced. |
| 15:40 |
sfan5 |
wouldn't we have to use a custom vertex type for that? |
| 15:40 |
sfan5 |
not that irrlicht can't do it but it drags a looong tail of adjustments with it |
| 15:41 |
MTDiscord |
<luatic> yeah that's why i'm trying to avoid it |
| 15:43 |
MTDiscord |
<luatic> though wait; if the C++ calculates light * hardware color already, can't we factor ambient light in there on the C++ side of things? |
| 15:44 |
sfan5 |
then it wouldn't be hardware coloring anymore |
| 15:45 |
sfan5 |
in theory there is nothing preventing us from moving relevant stuff back to C++ |
| 15:45 |
sfan5 |
but that walks back the performance improvements doing it in a shader has |
| 15:45 |
MTDiscord |
<luatic> i don't think it's ever been "fully" hardware coloring |
| 15:45 |
MTDiscord |
<luatic> note that the expensive texture coloring would still happen in the fragment shader |
| 15:50 |
srifqi |
has anybody test/profile that approach? the performance loss might be small enough and could justify moving the calculation to C++ side |
| 15:53 |
sfan5 |
just moving a calculation from the shader to c++ should be very minor |
| 15:53 |
sfan5 |
(unless that means you constantly have to re-generate map block meshes or so) |
| 15:55 |
MTDiscord |
<luatic> yeah changing the ambient light would then require changing the vertex color data as well. which is why this is a bit impractical. |
| 15:55 |
sfan5 |
that would be an understatement, sounds like a dealbreaker to me |
| 15:56 |
MTDiscord |
<luatic> i don't think that would render this unusable as a feature, since ambient light usually shouldn't change too frequently and if it does, it's often accompanied by changing "dimensions" or similar. |
| 15:57 |
MTDiscord |
<luatic> but trying to pack both into the color vec is probably a more sensible approach. |
| 15:58 |
sfan5 |
that works as long as nobody makes a disco lights mod :) |
| 15:58 |
MTDiscord |
<luatic> a 32-bit float should be enough to contain an 8-bit hardware color + a <= 16 (?) bit light color |
| 15:59 |
MTDiscord |
<luatic> (16 bit should be enough for the light color, right?) |
| 15:59 |
sfan5 |
you can fit 24 bits of integer in a float in a way that's easy to extract |
| 15:59 |
MTDiscord |
<luatic> yes |
| 16:00 |
sfan5 |
someone should check what the actual storage format is because I think vertex color might just be rgba32 and internally converted into float for shader usage |
| 16:00 |
sfan5 |
anyway if all else fails and you need more numbers S3DVertex2TCoords could be helpful |
| 16:02 |
MTDiscord |
<luatic> it's SColor indeed. but should be easy to change to SColorf or similar, i hope. |
| 16:02 |
sfan5 |
i don't think so |
| 16:03 |
sfan5 |
SColor is 4 bytes, SColorf is 16 |
| 16:05 |
MTDiscord |
<luatic> yes, it will come with an increase in size |
| 16:05 |
MTDiscord |
<luatic> do you think that will pose a big problem? |
| 16:07 |
sfan5 |
if you want to change S3DVertex to fit some usecase, at that point why not just invent a new vertex type? |
| 16:09 |
MTDiscord |
<luatic> might be a good idea |
| 16:09 |
sfan5 |
...actually |
| 16:09 |
sfan5 |
can't you reduce light into an u8 and put into the alpha channel of the vertex color? that's not used, right? |
| 16:10 |
sfan5 |
or do we need an actual light color and not just the light level (which could be turned back into a color in the shader)? |
| 16:13 |
MTDiscord |
<luatic> hmm that might work. i'm not sure whether hardware coloring supports alpha; i haven't seen it used that way yet. |
| 16:13 |
MTDiscord |
<luatic> will look into it. |
| 16:14 |
sfan5 |
https://github.com/minetest/minetest/blob/master/client/shaders/nodes_shader/opengl_vertex.glsl#L211 someone already had the same idea :D |
| 16:15 |
MTDiscord |
<luatic> lol |
| 16:15 |
MTDiscord |
<luatic> 'nother vertex type it is then i guess |
| 16:21 |
MTDiscord |
<luatic> okay, any opinions on #14543? i'd give it another review round and then wait for ruben to review it. |
| 16:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus |
| 16:24 |
sfan5 |
no concept complaints from my side |
| 16:27 |
srifqi |
idem with sfan |
| 16:34 |
srifqi |
i guess, that is all for today? |
| 16:35 |
srifqi |
luatic: the revised code is already posted as a reply comment |
| 16:37 |
MTDiscord |
<luatic> srifqi: looks good to me |
| 16:38 |
MTDiscord |
<luatic> let's end the meeting then |
| 16:38 |
srifqi |
great, i'll make a commit after this |
| 16:39 |
sfan5 |
different thing: it's been a while and I think we should refresh the translation files |
| 16:39 |
sfan5 |
does anyone want to do that? |
| 16:39 |
srifqi |
someone please edit the dev wiki page. i do not have an account there |
| 16:40 |
srifqi |
sfan5, seeing that the feature freeze is in around three weeks, we should update the translation files |
| 16:41 |
srifqi |
but not by me probably since it's already 23:41 here |
| 16:43 |
sfan5 |
not necessarily today :) |
| 16:45 |
srifqi |
i'll try when i'm available. i have never run the update po script |
| 16:45 |
srifqi |
luatic: the commit has been pushed |
| 16:47 |
srifqi |
alright then, thank you for participating in today's meeting |
| 16:47 |
srifqi |
see you |
| 16:47 |
sfan5 |
π |
| 17:10 |
sfan5 |
feedback wanted on #14451 |
| 17:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/14451 -- Allow passing arbitrary data to mapgen Lua env (also at runtime) |
| 18:57 |
|
Desour joined #minetest-dev |
| 19:06 |
Krock |
oh. looks like I totally missed this meeting. sorry for that. I'll set a reminder for the next one |
| 19:10 |
Krock |
sfan5: I think that the metatable __newindex caveat happens way too quickly. at this point it might be better to have a getter and setter function which make sure that the data passed to them is what you want |
| 19:11 |
Krock |
or at least for writing - assuming that read operations work OK |
| 19:11 |
Krock |
seems like grorp also mentioned the same thing (just scrolled down in the conversation) |
| 19:14 |
sfan5 |
read ops work ok but modifying the any references will do nothing |
| 19:14 |
sfan5 |
-the |
| 19:15 |
Krock |
right. unless you'd attach a specific metatable to it |
| 19:25 |
Krock |
about #14543. I find it somewhat interesting that game.conf `name` is deprecated, whereas we decided on forcing the very same `name` setting on mods to allow any directory names |
| 19:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus |
| 19:35 |
MTDiscord |
<grorp> they're not the same. in mod.conf, name is the technical name. in game.conf, name is the human-readable title. it's deprecated since you're supposed to use title instead. #12030 |
| 19:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/12030 -- Deprecate game.conf name, use title instead by rubenwardy |
| 19:40 |
Krock |
ah right. legacy reasons. |
| 19:41 |
Krock |
almost exactly 2 years ago I had the exact same thought. there we go again. |
| 19:55 |
MTDiscord |
<herowl> Ambient light is per-player, aren't the vertex colors global? |
| 19:56 |
MTDiscord |
<luatic> we're talking about the vertex colors on the client here |
| 19:57 |
MTDiscord |
<herowl> Anyway, alpha in the vertex color is used |
| 19:57 |
MTDiscord |
<herowl> For... |
| 19:57 |
MTDiscord |
<herowl> day/night ratio? |
| 19:57 |
MTDiscord |
<herowl> something like this |
| 19:57 |
MTDiscord |
<herowl> but it isn't used properly and ain't consistent |
| 19:59 |
MTDiscord |
<herowl> tbh, could as well improve its usage... |
| 22:00 |
|
dv^_^ joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:36 |
MTDiscord |
<herowl> The encode_light() function throws "average light" into r, g and b channels of the color, and "ratio of sunlight" (essentially, information whether the light applied should be natural or artificial) into the alpha channel. Β It looks like the two don't need that much precision and could both be compressed into the alpha channel, allowing actual vertex colors to be encoded in rgb channels. |
| 23:41 |
MTDiscord |
<luatic> thanks for looking into this. would you be willing to take a stab at implementing this? |
| 23:42 |
MTDiscord |
<herowl> I tried and failed miserably. |
| 23:42 |
MTDiscord |
<herowl> Not sure what's wrong exactly |
| 23:42 |
MTDiscord |
<herowl> but converting u8 to float and back is a bad idea |
| 23:43 |
MTDiscord |
<luatic> beware that irrlicht uses SColor for its vertices, so there's no way to have more than 8 bits in any of the channels currently, even if 16 or 32 bit floats get sent to the graphics card. |
| 23:44 |
MTDiscord |
<herowl> yeah, that's the point |
| 23:44 |
MTDiscord |
<luatic> this likely needs to be changed to make this work |
| 23:44 |
MTDiscord |
<herowl> I thought that 4 bits would be enough to compress it, and it probably would be enough |
