| Time |
Nick |
Message |
| 02:54 |
|
Taoki joined #minetest-dev |
| 04:21 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:02 |
|
Icedream joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 11:13 |
|
calcul0n__ joined #minetest-dev |
| 11:45 |
|
calcul0n_ joined #minetest-dev |
| 12:01 |
|
Fixer joined #minetest-dev |
| 12:16 |
|
MTDiscord joined #minetest-dev |
| 12:48 |
|
Megaf joined #minetest-dev |
| 13:32 |
|
Wuzzy joined #minetest-dev |
| 13:36 |
Wuzzy |
Bugfix PR that will fix tiled nodes rendering: #10742 |
| 13:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/10742 -- Fix world-aligned node rendering at bottom by Wuzzy2 |
| 15:07 |
|
olliy joined #minetest-dev |
| 16:25 |
|
Taoki joined #minetest-dev |
| 17:17 |
|
ivanbu joined #minetest-dev |
| 18:05 |
|
numzero joined #minetest-dev |
| 18:24 |
|
TechDude joined #minetest-dev |
| 19:01 |
|
systwi joined #minetest-dev |
| 19:35 |
Krock |
rubenwardy: for some reason there's a tailing newline when it's using the "description" nodedef field |
| 19:36 |
rubenwardy |
that's not something I've changed |
| 19:36 |
rubenwardy |
the code uses std::getline(sstr, desc, '\n'); |
| 19:36 |
rubenwardy |
to get the first line |
| 19:37 |
rubenwardy |
is it \r\n? |
| 19:37 |
Krock |
https://pastebin.com/raw/D50ZpgcM |
| 19:37 |
|
beit joined #minetest-dev |
| 19:37 |
Krock |
there's no newline in tools.lua (MTG) |
| 19:39 |
Krock |
I thought enchantment used itemmeta, but apparently this is the same case all over again: "description" itemdef field |
| 19:40 |
beit |
hello, I would like to go over the code of mindtest, is there some design document? |
| 19:40 |
MTDiscord |
<srinivas> uh |
| 19:40 |
Krock |
mindtest |
| 19:40 |
MTDiscord |
<srinivas> github.com/minetest/minetest |
| 19:40 |
Krock |
dev.minetest.net as well, though not very detailed and possibly outdated |
| 19:40 |
rubenwardy |
beit: https://dev.minetest.net/Engine |
| 19:41 |
MTDiscord |
<srinivas> or, the doxygen docs |
| 19:41 |
MTDiscord |
<srinivas> of whose location, i am unsure of |
| 19:41 |
rubenwardy |
you'd generate those yourself locally |
| 19:41 |
MTDiscord |
<srinivas> ah, minetest is not hosting its own? |
| 19:41 |
Krock |
do you mean this? http://doxy.minetest.net/ it's ancient |
| 19:42 |
rubenwardy |
not that |
| 19:42 |
MTDiscord |
<srinivas> oh deat |
| 19:42 |
rubenwardy |
that really should be removed from the DNS |
| 19:42 |
MTDiscord |
<srinivas> *dear |
| 19:42 |
Krock |
sort of a wayback machine |
| 19:43 |
MTDiscord |
<srinivas> also, is there any technical limitation in increasing the max nodes |
| 19:43 |
rubenwardy |
yes, networking compat and integer size |
| 19:44 |
Krock |
rubenwardy: this only happens when the string is translated |
| 19:44 |
Krock |
weird |
| 19:44 |
rubenwardy |
my tests don't include translations |
| 19:44 |
MTDiscord |
<srinivas> so, can we hope to get it in mt6? |
| 19:44 |
Krock |
apparently |
| 19:44 |
beit |
is there some block diagram? |
| 19:44 |
Krock |
srinivas: yes sure if you begin coding now |
| 19:45 |
rubenwardy |
https://dev.minetest.net/Engine/Structure |
| 19:45 |
rubenwardy |
there's a diagram there |
| 19:45 |
Krock |
first time seeing this. Minetest 0.3. |
| 19:45 |
rubenwardy |
it's still _mostly_ correct |
| 19:45 |
rubenwardy |
only because it's not very detailed |
| 19:46 |
MTDiscord |
<srinivas> > srinivas: yes sure if you begin coding now hm, what are the parts i would have to tweak? i am not very familiar with the internals |
| 19:46 |
rubenwardy |
content_id and the node def manager |
| 19:46 |
MTDiscord |
<srinivas> and, only have a very very rough understanding of what does what |
| 19:46 |
Krock |
srinivas: nodedef manager, mapblock serialization, database migration code |
| 19:47 |
rubenwardy |
there's already an issue to raise the limit up to 65536 without breaking compat. Currently, half the IDs are reserved by unknown nodes |
| 19:47 |
Krock |
for a good reason |
| 19:47 |
MTDiscord |
<Jonathon> https://github.com/minetest/minetest/issues/6101 and https://github.com/minetest/minetest/issues/10916 for reading material |
| 19:47 |
Krock |
coincidence, there's an issue where running out of free content ids results in stalls and other side-effects |
| 19:48 |
Krock |
speaking of the devil |
| 19:48 |
rubenwardy |
if you run out of free content IDs, it should either replace with air or crash |
| 19:48 |
MTDiscord |
<srinivas> also, are there any ideas of a release timeframe 6.0? |
| 19:48 |
rubenwardy |
not plained at all currently |
| 19:48 |
MTDiscord |
<srinivas> ah i see |
| 19:49 |
MTDiscord |
<Jonathon> also https://forum.minetest.net/viewtopic.php?t=20052 by krock is another thing to read about increasing the limit |
| 19:49 |
MTDiscord |
<srinivas> thanks wsor |
| 19:50 |
MTDiscord |
<Jonathon> this topic has been rehashed so many times while ive been around i practically have the reading material memorized lol |
| 19:50 |
MTDiscord |
<srinivas> also, thanks krock, ruben for your time |
| 19:50 |
Krock |
you're welcome |
| 19:50 |
MTDiscord |
<srinivas> > this topic has been rehashed so many times while ive been around i practically have the reading material memorized lol |
| 19:50 |
MTDiscord |
<srinivas> hehe |
| 19:50 |
MTDiscord |
<josiah_wi> I've got a question about PRs but don't wann to interrupt while you're in the middle of something else, is this an ok time or should I wait a bit? |
| 19:50 |
MTDiscord |
<srinivas> go ahead |
| 19:51 |
MTDiscord |
<josiah_wi> I'm doing a fairly large PR and I want to know whether it's worth my time, whether there's interest in it. What process should I follow? Do I make on issue? Or draft a PR now with a (working) part that I've finished? |
| 19:52 |
rubenwardy |
an issue is the best way to get feedback for that |
| 19:52 |
MTDiscord |
<josiah_wi> Thanks. |
| 19:53 |
rubenwardy |
I wonder if the problem with the short_description thing could be that it's processing a utf8 string rather than utf16 |
| 19:53 |
Krock |
rubenwardy: the newline issue only affects translations; colors are fine. weird. |
| 19:55 |
Krock |
I'm also a bit confused why the "first line" actually consists of multiple lines, for example : |
| 19:55 |
Krock |
> description = minetest.colorize("red", "Copper\n rail"), |
| 19:55 |
rubenwardy |
https://gist.github.com/rubenwardy/1e185f940262c39f98d0d8dcc6e0d366 |
| 19:56 |
rubenwardy |
might help |
| 19:57 |
rubenwardy |
I imagine this will break if a translation contains a new line |
| 19:57 |
Krock |
error: corrupt patch at line 20 ah whatever. gonna copypaste |
| 19:58 |
Krock |
that made no difference. same output |
| 20:00 |
Krock |
"getline" includes the tailing \n |
| 20:01 |
Krock |
i.e. needs trim() |
| 20:02 |
MTDiscord |
<srinivas> hm, i may have an idea to make increasing the size of the content_id non breaking for maps 1. let legacy maps continue using old size (by simply enforcing the limit of 32k even though the engine supports more 2. Provide a conf option to set the size for new maps 3. provide migration scripts to migrate from old to new |
| 20:03 |
MTDiscord |
<srinivas> so, as a result, only the client should break (if my understanding is correct) |
| 20:03 |
rubenwardy |
the size is compiled it, so you'd need to choose one size |
| 20:04 |
rubenwardy |
you could convert from and to when dealing with map storage and network |
| 20:04 |
MTDiscord |
<srinivas> nono, while the size can be suitably large, provide a soft limit |
| 20:04 |
rubenwardy |
you'd still need to convert |
| 20:04 |
Krock |
this sort of tweak should really not be a setting. rather find a solution that works well for all use-cases |
| 20:05 |
Krock |
it's mostly a per-world setting and needs more tweaking efforts than it's worth |
| 20:06 |
MTDiscord |
<srinivas> hm, true |
| 20:06 |
Krock |
in 5.5.0-dev, per-world settings could be implemented but not for that reason |
| 20:08 |
MTDiscord |
<srinivas> but what are the main usecases i should support? I see the following 1. large server hosting (with significant maps) 2. small server hosting (smaller mapsizes, but still headless & over network) 3. home client-server pairs (variable maps, but all localhost) |
| 20:09 |
Krock |
excuse me? I thought the content_id limit discussion was about the number of enabled mods or registered nodes, rather than server type |
| 20:10 |
MTDiscord |
<srinivas> hm, that was concerning migration, looks like i misunderstood what you meant by usecase |
| 20:11 |
MTDiscord |
<srinivas> i was under the (mistaken?) impression that you were talking about "end-user" usecases (as in the types of users and their needs) |
| 20:12 |
Krock |
no sorry, I meant various scenarios that might happen. for example maps that were downloaded, but without any active mods -> many unknown nodes |
| 20:13 |
MTDiscord |
<srinivas> ah i see |
| 20:13 |
Krock |
problem here is that it's a sort of "pool" where the final size is yet not known. if there were a map-specific list of nodes that were ever placed, you could predict the limit and adjust that accordingly |
| 20:14 |
Krock |
however, keeping track of such a list is perhaps insane and error-prone |
| 20:14 |
Krock |
the only known thing is that there's a limit of 65k node IDs that can be given away |
| 20:14 |
Krock |
s/node/content/ |
| 20:15 |
celeron55 |
i'd say it would be stupid to create some crazy contraption just to double the node id space |
| 20:15 |
MTDiscord |
<srinivas> hm, the alternate solution could be just reserving approx half of the new content id's for unknowns (like what is currently done) |
| 20:15 |
celeron55 |
either it stays like it is, or people accept some performance degradation and it's increased considerably |
| 20:15 |
celeron55 |
then don't complain MT is getting slower |
| 20:16 |
celeron55 |
due to all these little things people keep asking for piling up |
| 20:16 |
MTDiscord |
<srinivas> if you go with uint64 which will leave upto 9.223372036854776e+18 for unknowns (and the same for known nodes) |
| 20:16 |
MTDiscord |
<srinivas> which is a large enough number that the ipv4 like scare will not happen for quite some time |
| 20:16 |
celeron55 |
eh, what |
| 20:17 |
MTDiscord |
<srinivas> uh, the shortage of ipv4 addresses |
| 20:18 |
celeron55 |
it's a large enough number for people to notice an increase in RAM usage, then you'll have to explain to them that yeah, it's for this thing you'll never use and now half of the bits in your memory are used for nothing |
| 20:18 |
Krock |
I wouldn't say RAM usage is a concern, but saved mapblocks |
| 20:19 |
MTDiscord |
<srinivas> hm, in this era where 8gb+1tb is increasingly common, i wouldnt worry too much about ram? |
| 20:19 |
celeron55 |
just look up how much RAM, say, a raspberry pi has |
| 20:20 |
celeron55 |
or a phone that a parent might buy for their kid |
| 20:20 |
celeron55 |
MT isn't just for gaming PCs |
| 20:20 |
MTDiscord |
<srinivas> uh, my laptop from 2013 has about 6 gigs in it... I rarely cross 4 |
| 20:21 |
rubenwardy |
I think making the known/unknown ID barrier dynamic already gives a considerably higher limit on node ids with very little performance impact |
| 20:21 |
MTDiscord |
<srinivas> my phone a ~100$ chinese one, has 4gigs |
| 20:21 |
MTDiscord |
<srinivas> the cheapest raspi4 has 4? gigs |
| 20:21 |
MTDiscord |
<srinivas> or was it 2 |
| 20:22 |
Krock |
model 2b has 1 GiB |
| 20:23 |
celeron55 |
everything before rpi4 has 1 GiB |
| 20:23 |
celeron55 |
and even that's beside the point |
| 20:23 |
celeron55 |
people use VPSes and whatnot |
| 20:23 |
celeron55 |
memory isn't free |
| 20:23 |
MTDiscord |
<srinivas> hm, fair |
| 20:23 |
celeron55 |
not RAM, not disk |
| 20:24 |
celeron55 |
and people use mobile connections, so network isn't free either |
| 20:24 |
MTDiscord |
<srinivas> but certainly cheaper than when the 65k limit was thought of |
| 20:24 |
MTDiscord |
<srinivas> fair, but again, cheaper |
| 20:25 |
celeron55 |
there needs to be a proper reason for increases in memory usage, it can't be done just for a few users so that it degrades the experience for others |
| 20:25 |
MTDiscord |
<srinivas> but hey, that was for uint_64, even going with u_int 32 can work pro tempore? |
| 20:25 |
celeron55 |
make a similar desicion 20 times and you'll make it actually unusable for some |
| 20:26 |
MTDiscord |
<srinivas> well, if it made right, it will not need to be made for a long time |
| 20:26 |
rubenwardy |
lol, 64bits would be ridiculous |
| 20:26 |
MTDiscord |
<srinivas> true |
| 20:27 |
celeron55 |
i think making the unknown id barrier dynamic is a workaround that will last maybe a year or less |
| 20:27 |
MTDiscord |
<srinivas> and, with moores law, you can safely make your changes again, and again |
| 20:27 |
MTDiscord |
<srinivas> simply because tech upgrades |
| 20:27 |
celeron55 |
then you're back to the same issue and have to support a useless system in addition to increasing the bit space |
| 20:27 |
rubenwardy |
the system is pretty trivial and means you can use all of the ID space, not just half |
| 20:28 |
MTDiscord |
<srinivas> and if we can do it once, it certainly can be done again, and again, sure it may be a pita, but it can be done |
| 20:28 |
MTDiscord |
<srinivas> the only thing is, will it be done |
| 20:28 |
celeron55 |
rubenwardy: ok even then, you pretty much have to already decide what to do after a year, when the same users come back with the same problem again |
| 20:28 |
celeron55 |
it needs to be decided what the final bit width of the node id is, and stick to it |
| 20:30 |
MTDiscord |
<srinivas> hm, you should remember that over time sensibilities change what was too much 10 years ago, will be stifling today, case point, ipv4 was once thought to be very plentiful, yet look at us today |
| 20:30 |
celeron55 |
of course keeping in mind that increasing it at all will mess up the current 4 byte length of each node |
| 20:30 |
MTDiscord |
<srinivas> migration scripts can be provided |
| 20:31 |
celeron55 |
compilers and processors won't like a 5, 6 or 7 bit length |
| 20:31 |
celeron55 |
*byte |
| 20:31 |
celeron55 |
in an array |
| 20:31 |
celeron55 |
they'll probably pad it to 8 or so anyway |
| 20:32 |
MTDiscord |
<srinivas> hm, arent most processors 64bit these days |
| 20:32 |
MTDiscord |
<srinivas> with the exception of some cheap phones and ancient tech |
| 20:32 |
MTDiscord |
<srinivas> that still run windows 98 :p |
| 20:35 |
celeron55 |
to be fair i don't really understand this level of optimization like some people do, but i do know that cache misses ruin your day, and compilers pad structs if they don't like the field lengths |
| 20:35 |
celeron55 |
an i3 has 32 kiB of L1 cache |
| 20:36 |
celeron55 |
the current mapblock node array size is 4B*4096 = 16384 B |
| 20:36 |
celeron55 |
if it's increased to 8B, nothing else will fit in the cache in addition to it |
| 20:36 |
celeron55 |
which generally seems like a pretty bad idea |
| 20:37 |
celeron55 |
altough it may have no effect also, who knows; it's mostly a matter of trying to maintain good odds |
| 20:37 |
|
Megaf_ joined #minetest-dev |
| 20:38 |
MTDiscord |
<srinivas> hm, although, i dont know which scheduler will let a single prog take up all of cache |
| 20:38 |
celeron55 |
for me there are many unknowns though, for example i don't know how compilers actually handle the u16+u8+u8 structure that a node is |
| 20:38 |
celeron55 |
it could be that it's already padded to something else |
| 20:39 |
MTDiscord |
<srinivas> tbh, i am not sure my self, i should read up that |
| 20:39 |
celeron55 |
or reordered to something else |
| 20:39 |
Krock |
weren't there a few re-ordering PRs a while ago, either by s0far or numzer0. I don't remember. |
| 20:40 |
celeron55 |
in any case i think this is what increasing the node id space comes down to |
| 20:40 |
celeron55 |
the u16 is currently the id |
| 20:40 |
celeron55 |
and MT completely relies in everything related to this to be fast |
| 20:41 |
celeron55 |
go ahead change it and test, and report what kind of performance loss you get on old and new hardware |
| 20:41 |
MTDiscord |
<srinivas> mhm |
| 20:41 |
celeron55 |
just switch it to u32 and see |
| 20:41 |
MTDiscord |
<srinivas> although, progress will be slow, as i have major exams coming up one in 10 days from today too |
| 20:42 |
celeron55 |
https://github.com/minetest/minetest/blob/master/src/mapnode.h#L122 |
| 20:42 |
celeron55 |
that line |
| 20:42 |
MTDiscord |
<srinivas> mhm |
| 20:43 |
celeron55 |
if someone has time to do it, collect some benchmark of changing that to u32 and u64, and also the u16 baseline |
| 20:43 |
MTDiscord |
<srinivas> uh, whats the util to use/ |
| 20:43 |
celeron55 |
https://github.com/minetest/minetest/blob/master/src/mapnode.h#L36 |
| 20:43 |
celeron55 |
i guess also this one |
| 20:44 |
celeron55 |
not sure, that's part of the task 8) figure out what the benchmark needs to be |
| 20:44 |
Krock |
also use a new map for that. it would either cause errors or corrupt existing maps |
| 20:44 |
MTDiscord |
<srinivas> > if someone has time to do it, collect some benchmark of changing that to u32 and u64, and also the u16 baseline also, what are the test cases to be used? |
| 20:44 |
MTDiscord |
<srinivas> > also use a new map for that. it would either cause errors or corrupt existing maps was planning on a fresh run in place |
| 20:49 |
celeron55 |
maybe measuring how long the worldedit //fixlight command takes for a certain large volume could be a usable benchmark |
| 20:49 |
celeron55 |
that's backed by quite some node data crunching |
| 20:50 |
MTDiscord |
<srinivas> and how do i time worldedit? i am not very well versed in this, so i hope you will pardon me |
| 20:50 |
celeron55 |
you'll have to add some time measurement to its lua code |
| 20:50 |
MTDiscord |
<srinivas> ah i see |
| 20:51 |
MTDiscord |
<srinivas> a call to minetest.get_ustime before and after execution and subtract the results? |
| 20:51 |
MTDiscord |
<srinivas> + divide by 1000 to get time in seconds |
| 20:51 |
celeron55 |
just collecting statistics of world generation performance works too and could be a more relevant benchmark actually |
| 20:52 |
MTDiscord |
<srinivas> uh, i use the profiler for that right? or is there a different method? |
| 20:59 |
celeron55 |
not many directly useful values there, but maybe if you write down the "EmergeThread: Mapgen::makeChunk" millisecond values in a new world until the mapgen stops, always using the same seed for a new world, and take an average of those, that's a reasonable value to compare |
| 21:00 |
celeron55 |
of course doing the same using some added logging code would be more robust but doing that by hand should work fine enough |
| 21:01 |
celeron55 |
also record the final memory consumption when generation stops |
| 21:01 |
MTDiscord |
<srinivas> mhm, would yall accept a debug build only pr that logs these values? may be useful? |
| 21:01 |
celeron55 |
and don't move the mouse |
| 21:37 |
celeron55 |
ok, did that myself just to see if there's a difference |
| 21:38 |
celeron55 |
i measured the total Mapgen::makeChunk time in a new map with the same seed in u16, u32 and u64 content_t/param0 builds |
| 21:39 |
celeron55 |
the results are: u16: 23635ms, u32: 24060ms, u64: 25564ms |
| 21:40 |
celeron55 |
the cpu in this system is i7-4800MQ |
| 21:42 |
celeron55 |
so the difference is visible |
| 21:47 |
celeron55 |
did a third test for u32, the average time went down to 23569ms |
| 21:47 |
celeron55 |
based on these it seems u32 isn't slower than u16, but u64 is slower |
| 21:48 |
celeron55 |
that's weird and begs the question what does the MapNode structure actually look like in memory |
| 22:00 |
celeron55 |
using the -Wpadded g++ option it seems the compiler wants 32-bit positions for pointers and integers, but char/bool is fine at 8-bit positions |
| 22:00 |
celeron55 |
it doesn't say anything about MapNode which should mean that it stays intact |
| 22:01 |
celeron55 |
yeah, if i move param0 after param1, it will say it will be padded |
| 22:01 |
celeron55 |
so u16, u8, u8 is optimal |
| 22:02 |
celeron55 |
u32, u8, u8 however says "padding struct size to alignment boundary" which means it's probably extendng the size of MapNode to 64 bits |
| 22:03 |
celeron55 |
u64, u8, u8 also says the same, but 64+8+8 is 80 bits so it's padding the size to 32*3 = 96 bits probably |
| 22:05 |
celeron55 |
oh, it's padding it to 128 bits |
| 22:05 |
celeron55 |
u32, u8, u8 is 64 bits like i expected |
| 22:05 |
celeron55 |
and u16, u8, u8 is 32 bits, confirmed |
| 22:06 |
celeron55 |
so on this processor it doesn't matter speed-wise if MapNode is 64 bits instead of 32 bits total |
| 22:06 |
celeron55 |
that also means if the id was 32 bits, there would be room for 16 extra bits after param1 and param2 |
| 22:08 |
sfan5 |
param1 could be made rgb565 for colored light |
| 22:19 |
celeron55 |
or u16 for light to go much further |
| 22:19 |
celeron55 |
however nobody knows how computing intensive that would be |
| 22:20 |
celeron55 |
well rgb565 of course has one bit more already |
| 22:20 |
MTDiscord |
<Flamore> Doesn't irrlicht have colored lighting? |
| 22:20 |
sfan5 |
well hmm |
| 22:20 |
sfan5 |
if you use rgb565 what about the day and night bank? |
| 22:21 |
sfan5 |
(or artificial / natural bank as someone once proposed IIRC) |
| 22:21 |
celeron55 |
well, then you just have two of them |
| 22:22 |
celeron55 |
it's 3x the lighting calculation, plus 2x more for the double distance |
| 22:22 |
celeron55 |
so 6x |
| 22:22 |
celeron55 |
it would be interesting but possibly unusable |
| 22:23 |
celeron55 |
also, double distance means 8 times the volume... so maybe more like 24x computation |
| 22:23 |
numzero |
is distance larger than mapblock size feasible at all? |
| 22:24 |
celeron55 |
no idea, it's true that just the distance could create some kind of unrepairable hell of glitches |
| 22:25 |
celeron55 |
Flamore: of course, but it's just the simple lighting you see in any game, not node volume based |
| 22:26 |
numzero |
rgb444 would fit MT better than rgb565 |
| 22:27 |
numzero |
and would fit these additional bits after proposed content_id expansion to 32 bits |
| 22:27 |
numzero |
(64bit content_id is nonsensical) |
| 22:27 |
celeron55 |
nothing stops you from cutting rgb565 short at 4 bit distance and just mapping the brightness appropriately |
| 22:27 |
numzero |
nevertheless, 32 bits is too much for content_id IMO |
| 22:27 |
celeron55 |
you get more dim colors that way |
| 22:28 |
celeron55 |
or... does something stop one from doing that? |
| 22:28 |
celeron55 |
actually |
| 22:28 |
celeron55 |
rgb is a bad idea |
| 22:28 |
celeron55 |
at least in theory |
| 22:28 |
numzero |
if you mean using only 4 high-order bits for spread and low-order bits for more levels, that’s okay |
| 22:29 |
numzero |
rgb? it won’t look perfect but is the only viable colorspace for MT-ish light spread |
| 22:29 |
numzero |
(out of 3-channel colorspaces ofc) |
| 22:30 |
celeron55 |
what about hsl? |
| 22:31 |
numzero |
how to spread hsl from several sources? |
| 22:31 |
celeron55 |
mixing colors can be a bit tricky but at least the L component can be handled with just as many bits as we want which is 4 |
| 22:31 |
numzero |
yeah ofc |
| 22:31 |
numzero |
mixing is the problem |
| 22:32 |
numzero |
it’s not a big problem to mix 2 colors, if you know the colors |
| 22:32 |
celeron55 |
and L could be mixed just like now, that is, just take the brighter from the two colors |
| 22:32 |
numzero |
but how to mix H? |
| 22:34 |
numzero |
more precisely, how to *spread* H? |
| 22:34 |
celeron55 |
when spreading it just stays the same |
| 22:34 |
celeron55 |
but when mixing i'm not sure |
| 22:34 |
numzero |
er, I mean, spreading H from several sources |
| 22:35 |
numzero |
of different colors |
| 22:35 |
celeron55 |
also S is problematic |
| 22:35 |
celeron55 |
HSL or HSV directly works like paint while we're dealing with light, which would be better directly represented by RGB |
| 22:35 |
rubenwardy |
RGB has problems but it's by far the simplest |
| 22:35 |
MTDiscord |
<exe_virus> true |
| 22:36 |
numzero |
the great thing in the current light spread is that as soon as it meets a brighter node, it can stop |
| 22:36 |
celeron55 |
but rgb colors at low bit depths look terrible |
| 22:36 |
numzero |
with HSL that won’t be the case as that would mean no mixing at all |
| 22:37 |
celeron55 |
well the thing about light is that in nature the brightness dynamic is so huge that if you take two lights, chances are one of them is so much dimmer it doesn't practically change the overall color of the lighting |
| 22:37 |
celeron55 |
so one could get away with just not mixing unless L is the same or something almost equally silly sounding |
| 22:39 |
celeron55 |
but also just using rgb444 and hoping for the best could work just as well |
| 22:40 |
numzero |
I saw screenshots of rgb444, it looks okay (albeit imperfect) |
| 22:40 |
celeron55 |
personally i'd really like more control on the hue and saturation, even while we can't have a huge range of lightness |
| 22:40 |
celeron55 |
i could have very subtle colors of light |
| 22:40 |
numzero |
heh, that’s where your proposal could work |
| 22:40 |
celeron55 |
i mean, it would allow stuff like actually having the color of the light coming from a blue sky as a node lighting color |
| 22:41 |
celeron55 |
in rgb444 i'm not sure there's a subtle enough blue available |
| 22:41 |
celeron55 |
it would have to be 14, 14, 15 |
| 22:41 |
numzero |
um... but currently the same light value is used for skylight and sunlight |
| 22:42 |
celeron55 |
what that actually looks like depends on the gamma and other mapping of course |
| 22:42 |
celeron55 |
yeah, and there's clever shader code for coloring natural/sunlight a bit differently at different times of day |
| 22:43 |
celeron55 |
wait |
| 22:43 |
celeron55 |
was it time dependent or constant |
| 22:43 |
numzero |
and that *should* be in the shader, just a bit differently |
| 22:43 |
celeron55 |
i think it's constant actually |
| 22:45 |
numzero |
hm... not sure of what *should* be there, actually |
| 22:46 |
numzero |
currently the shader does smooth day/night transition as well as tints artificial light |
| 22:46 |
numzero |
but due to lack of data, the tint is often wrong at daytime |
| 22:46 |
numzero |
it tints *all* artificial light even if there is full daylight at the time |
| 22:47 |
numzero |
as it can’t know that |
| 22:47 |
numzero |
without #5155 |
| 22:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/5155 -- Change light banks meaning |
| 22:47 |
celeron55 |
14,14,15 (#eef) in rgb444 is #eeeeff in rgb888, and if that's rendered directly on this sRGB-ish screen it actually is a reasonable shadow blue, same goes for #dde, #ccd, #bbc and all the way down to #778 and #223 it does transition into a blue shadow |
| 22:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/778 -- Fixed wrong output from dump() by kaeza |
| 22:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/223 -- Game doesn't always disregard image filename extensions in the context of a mod's code |
| 22:47 |
celeron55 |
so it is capable of a subtle enough color |
| 22:48 |
numzero |
heh |
| 22:48 |
celeron55 |
lol |
| 22:48 |
numzero |
the remaining thing is to change spread mechanics |
| 22:48 |
numzero |
to make direct sunlight become (15,15,14) and skylight become (14,14,15) |
| 22:49 |
celeron55 |
i'm not sure if that's actually doable otherwise |
| 22:49 |
celeron55 |
i just want the colorspace to be capable of it regardless |
| 22:49 |
celeron55 |
btw, i want to see what it looks like if rgb444 is handled as simply three separate channels of the current light handling code |
| 22:49 |
celeron55 |
no changes whatsoever otherwise |
| 22:50 |
celeron55 |
dimmer color channels stopping at brighter ones has a chance of being a reasonable effect and it would be very simple and fast |
| 22:51 |
celeron55 |
that means if there are two colors of similar brightness, they tend to mix towards white light of the same brightness |
| 22:51 |
celeron55 |
which is realistic |
| 22:54 |
numzero |
additive lighting is realistic. MT only needs to look good |
| 22:56 |
numzero |
anyway, the question was on increasing content_id size, not on lighting at all) |
| 22:57 |
celeron55 |
well, it all goes hand-in-hand |
| 22:57 |
numzero |
somewhat |
| 22:57 |
celeron55 |
if there are multiple well researched proposals that need more bits for nodes and the next node size in memory is double the current one regardless of what's added to it, it's more likely to happen |
| 22:58 |
numzero |
I think doubling the node size is to happen eventually |
| 22:58 |
celeron55 |
there's the everpresent question of "what about fields for node physics" too |
| 22:59 |
celeron55 |
currently the only physics field is liquid level |
| 22:59 |
numzero |
there is also a question: *why* are more content_ids necessary? |
| 23:00 |
celeron55 |
i think they are not necessary and could be avoided by map management tools |
| 23:00 |
celeron55 |
and mod management tools |
| 23:00 |
numzero |
WDYM? |
| 23:00 |
celeron55 |
it is an alternative to said tools though |
| 23:00 |
sfan5 |
another example #9193 |
| 23:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/9193 -- Add paramtype2 for node texture variants |
| 23:01 |
celeron55 |
well, if users could easily determine which mods are adding way too many nodes, they could disable them, or if the tools even had the option of disabling some nodes without disabling the mods that would be even better |
| 23:01 |
celeron55 |
and for maps that have unknown nodes that aren't used there could be clean up tools and node usage counters to help with cleaning up |
| 23:02 |
numzero |
um... am I right node names are stored in each mapblock (on disk)? |
| 23:02 |
celeron55 |
yes |
| 23:02 |
numzero |
I just realized the on-disk format doesn’t need to change |
| 23:02 |
celeron55 |
the disk format allows infinite node names in each map |
| 23:03 |
numzero |
it renumbers nodes for each mapblock already IIRC |
| 23:03 |
sfan5 |
yes |
| 23:03 |
numzero |
and there may never be more than 4096 different nodes in a mapblock |
| 23:03 |
numzero |
since there are just 4096 nodes in said block |
| 23:03 |
numzero |
so the overall node type limit is irrelevant for on-disk format |
| 23:04 |
numzero |
oh, network serialization uses the same format, doesn’t it? |
| 23:04 |
sfan5 |
yes |
| 23:05 |
|
TechDude joined #minetest-dev |
| 23:06 |
celeron55 |
i guess it doesn't even take advantage of the fact that the client and server actually have synced node ids |
| 23:07 |
numzero |
so it should be possible to experiment reasonably safely |
| 23:07 |
numzero |
btw does the client need different node ids for different unknown nodes? |
| 23:08 |
numzero |
(if it doesn’t doing map save ofc) |
| 23:09 |
celeron55 |
the client and server of course otherwise do need synced node ids |
| 23:09 |
celeron55 |
all commands rely on them being in sync |
| 23:09 |
celeron55 |
oh actually |
| 23:10 |
celeron55 |
the mapblock network serialization format does actually skip the mapping |
| 23:10 |
sfan5 |
huh |
| 23:10 |
sfan5 |
didn't know that off the top of my head |
| 23:11 |
celeron55 |
and the client will not deserialize the mapping from the network data even if the data had it |
| 23:11 |
celeron55 |
well good, at least that's optimized |
