Time |
Nick |
Message |
00:12 |
|
alket joined #minetest-dev |
02:01 |
|
nolsen joined #minetest-dev |
02:03 |
sofar |
where is the default plantlike mesh defined? |
02:04 |
|
Supertan1er2 joined #minetest-dev |
04:18 |
hmmmm |
content_mapblock.cpp line 1109 |
04:26 |
|
Player2 joined #minetest-dev |
05:53 |
|
Supertanker2 joined #minetest-dev |
06:00 |
|
Supertanker2 joined #minetest-dev |
06:26 |
sofar |
hm, now I have to figure out what an S3DVertex is :) |
06:39 |
|
Hunterz joined #minetest-dev |
07:03 |
sofar |
hmmmm: https://github.com/minetest/minetest/issues/1589 |
07:58 |
sofar |
I think we can make especially grass look a lot better. Even if this could be done just for default:grass_*, it would be a major visual improvement |
08:01 |
|
troller joined #minetest-dev |
08:39 |
|
jin_xi joined #minetest-dev |
09:06 |
|
nrzkt joined #minetest-dev |
09:39 |
|
RealBadAngel joined #minetest-dev |
09:42 |
RealBadAngel |
sofar, here? |
10:23 |
|
kilbith joined #minetest-dev |
10:23 |
kilbith |
paramat, look what i found : https://lut.im/ePUpE4a7Y9/KCu0cNmnHLnBOTvm.png |
10:26 |
|
Calinou joined #minetest-dev |
10:37 |
RealBadAngel |
acaccia zipped? ;) |
11:08 |
nrzkt |
kilbith, great |
11:09 |
Hunterz |
it is monument of aliens |
11:20 |
kilbith |
"monument of aliens" is a good excuse for all mapgen craps... |
11:34 |
Hunterz |
hehe |
11:53 |
|
Fixer joined #minetest-dev |
12:30 |
|
behalebabo joined #minetest-dev |
13:45 |
Taoki |
RealBadAngel: Any updated news on minimap and realtime lighting BTW, now with holidays approaching and all? Not expecting things to happen overnight of course, just curious if you have any plans expected on a timelmine :) |
13:45 |
RealBadAngel |
rather not any soon, those are things i cant handle alone |
13:46 |
RealBadAngel |
i keep asking for help when i see the wall but theres no response |
13:46 |
RealBadAngel |
ive chosen to go back to the field i know good enough to be the only one there |
13:47 |
RealBadAngel |
instead of sitting 2-3 weeks in front of rather trivial problem (but not in my area) i can code something else |
13:48 |
RealBadAngel |
those who could help me chosen to sit and watch |
13:54 |
RealBadAngel |
taoki, anyway, you will love next PR, thats a promise |
13:55 |
RealBadAngel |
its gonna be kinda compilation of the few ideas that were here already |
14:11 |
RealBadAngel |
https://github.com/minetest/minetest/pull/3442 |
14:12 |
Taoki |
Awesome... can't wait :) |
14:12 |
RealBadAngel |
can somebody give it one more +1 and merge it? |
14:14 |
|
zat joined #minetest-dev |
14:14 |
* Taoki |
hopes the speedup means there won't be FPS hiccups with relief mapping enabled any more. IIRC that was a problem in the past |
14:15 |
RealBadAngel |
this should speed up relief mapping quite a bit |
14:15 |
RealBadAngel |
theres less iterations |
14:15 |
Taoki |
Awesomeness. |
14:15 |
RealBadAngel |
not to mention end effect is way nicer |
14:20 |
RealBadAngel |
https://github.com/minetest/minetest/pull/3391 , any more comments on this PR? |
14:22 |
RealBadAngel |
without 3391 in i cannot make PRs with liquid shaders (or any other ones) |
14:25 |
RealBadAngel |
for 3391 i need more folks to test sample shaders... |
14:28 |
Fixer |
any windows binaries? |
14:34 |
RealBadAngel |
ask sfan5 |
14:35 |
RealBadAngel |
http://i.imgur.com/smyD4M8.png |
14:35 |
RealBadAngel |
(playin with relief mapping to the max, checkin how far we can get now) |
15:09 |
|
jin_xi joined #minetest-dev |
15:12 |
|
younishd joined #minetest-dev |
15:15 |
sofar |
RealBadAngel: was asleep... |
15:27 |
RealBadAngel |
sofar, see my comnment on plants |
15:31 |
sofar |
I saw |
15:31 |
sofar |
mapgen should certainly do that |
15:32 |
sofar |
but the offset random x,z works even better |
15:49 |
|
Obani joined #minetest-dev |
15:58 |
|
CraigyDavi joined #minetest-dev |
15:59 |
|
Hunterz joined #minetest-dev |
16:05 |
|
Darcidride joined #minetest-dev |
16:11 |
|
Darcidride joined #minetest-dev |
16:20 |
|
younishd_ joined #minetest-dev |
16:20 |
|
hmmmm joined #minetest-dev |
16:33 |
|
alket joined #minetest-dev |
16:33 |
|
younishd joined #minetest-dev |
16:39 |
RealBadAngel |
hmmmm, can you vote #3442? |
16:41 |
RealBadAngel |
sofar, such modifications are very specific (i mean those you have proposed) while whats already in the engine is generic |
16:42 |
|
CraigyDavi joined #minetest-dev |
16:44 |
|
est31 joined #minetest-dev |
16:45 |
est31 |
RealBadAngel, I've read through the pr to use binary search |
16:45 |
est31 |
I now wonder: why make a linear search before the binary one? |
16:45 |
RealBadAngel |
and? |
16:45 |
est31 |
why not one single binary search? |
16:45 |
est31 |
it would spare 12 more iterations |
16:45 |
est31 |
or 11 |
16:46 |
RealBadAngel |
linear is to find something thats near a hit |
16:46 |
RealBadAngel |
binary is to get to it as close as possible |
16:47 |
RealBadAngel |
more linear steps you get better accuracy |
16:47 |
est31 |
what precisely should the algorithm do |
16:48 |
RealBadAngel |
find exact interesction eye ray and depth field at texture space |
16:48 |
RealBadAngel |
but we dont need perfect one |
16:48 |
RealBadAngel |
something close is enough |
16:49 |
RealBadAngel |
do you want to read papers on it? |
16:49 |
|
proller joined #minetest-dev |
16:50 |
est31 |
yes |
16:50 |
RealBadAngel |
hold on |
16:52 |
RealBadAngel |
est31, ur email plz |
16:53 |
est31 |
RealBadAngel, its in info tab in the client |
16:54 |
est31 |
Credits tab* |
16:54 |
RealBadAngel |
ok |
16:54 |
|
zupoman joined #minetest-dev |
16:54 |
|
zupoman joined #minetest-dev |
16:55 |
est31 |
so I wonder, why not something like this instead? https://gist.github.com/anonymous/beed54f9e6d64c99e389 |
16:56 |
RealBadAngel |
sent |
16:57 |
RealBadAngel |
code you highlighted will create 8 visible depth layers |
16:58 |
RealBadAngel |
those could be eliminated with filtering |
16:58 |
RealBadAngel |
but thats not the point, it will be fuzzy and setting dependent |
16:59 |
RealBadAngel |
and will look just WRONG |
16:59 |
est31 |
but the depth can have more than just 8 values |
16:59 |
RealBadAngel |
yes |
16:59 |
* est31 |
tries his code |
16:59 |
est31 |
q |
16:59 |
est31 |
wrong window lol |
17:00 |
RealBadAngel |
you can divide it into lets say 256 |
17:00 |
RealBadAngel |
you will jamm your gpu |
17:00 |
RealBadAngel |
wiser is to get close and look for most accurate one |
17:02 |
RealBadAngel |
old code was using 25 steps (value picked from testing) |
17:02 |
RealBadAngel |
new one has 16 + 6 steps |
17:02 |
est31 |
no |
17:02 |
RealBadAngel |
and is WAY more accurate |
17:02 |
est31 |
it has 15 + 6 |
17:02 |
est31 |
not 16+6 |
17:04 |
RealBadAngel |
preli,inary step is not counted in, right |
17:04 |
RealBadAngel |
but math is made for such steps |
17:05 |
RealBadAngel |
thats why decrement is first thingy in the loop |
17:08 |
RealBadAngel |
anyway, binary search eliminates visible displacement layers |
17:09 |
RealBadAngel |
higher the scale of the effect, u notice it more |
17:09 |
Fixer |
RealBadAngel, sfan5 does not have any win binaries with your shaders |
17:10 |
RealBadAngel |
with the change you can try enormous scales and still get correct effect |
17:10 |
est31 |
Fixer, you dont need to change any binaries |
17:10 |
est31 |
Fixer, the shaders are not in the binary, but "in the open" |
17:10 |
est31 |
just apply the patch manually |
17:10 |
RealBadAngel |
est31, for last PR yes |
17:11 |
RealBadAngel |
but i do have many waitin in line |
17:11 |
RealBadAngel |
custom shaders patch is just happily hanging around :P |
17:13 |
Fixer |
but it says Grab the branch with PR and compile: |
17:13 |
Fixer |
https://github.com/RealBadAngel/minetest/tree/new_shaders |
17:14 |
RealBadAngel |
Fixer, that branch need compiling, yeah |
17:14 |
RealBadAngel |
relief mapping patch doesnt, since its altering only GLSL shaders code |
17:14 |
est31 |
That's what I'm getting with your PR RBA http://pasteboard.co/2LXQwEXa.png |
17:15 |
RealBadAngel |
est31, scale? |
17:16 |
est31 |
RealBadAngel, what scale should I set? |
17:16 |
RealBadAngel |
0.08 is default |
17:16 |
RealBadAngel |
make it 0.8 |
17:16 |
est31 |
is it "parallax occlusion scale"? |
17:17 |
RealBadAngel |
yes |
17:18 |
RealBadAngel |
its overall scale of the effect |
17:18 |
est31 |
this is the scene with my "whole" binary search http://pasteboard.co/2LY66Cvq.png |
17:19 |
RealBadAngel |
look at bricks edges |
17:20 |
RealBadAngel |
you have fucked it up |
17:20 |
est31 |
yeah |
17:20 |
RealBadAngel |
you made layers |
17:20 |
est31 |
you are right |
17:20 |
est31 |
+1 to the pr |
17:20 |
est31 |
can I merge it or do you want to change sth? |
17:20 |
est31 |
also, the paper recommends to do linear search firt |
17:20 |
RealBadAngel |
with your vote it has 2 |
17:20 |
est31 |
first |
17:21 |
RealBadAngel |
i do |
17:21 |
est31 |
yeah, therefore I can merge |
17:21 |
RealBadAngel |
linear search is simple -0.1 |
17:21 |
est31 |
so, you want to change nothing anymore, I'll merge it then |
17:21 |
RealBadAngel |
or whatever step |
17:21 |
RealBadAngel |
funny name for just - |
17:22 |
RealBadAngel |
no changes requsted |
17:22 |
RealBadAngel |
its rdy |
17:23 |
|
proller joined #minetest-dev |
17:24 |
|
Krock joined #minetest-dev |
17:24 |
Fixer |
congrats |
17:25 |
est31 |
merge |
17:25 |
est31 |
d |
17:26 |
est31 |
will push commit like this in 10 minutes https://github.com/est31/minetest/commit/e8053dd781b2c8da40fc8cf5c786947dbfaa3ff6 |
17:26 |
est31 |
copy paste mistake |
17:27 |
Fixer |
can developers consider changing autorange view system? it is crappy :( |
17:28 |
|
celeron55 joined #minetest-dev |
17:28 |
Fixer |
when you walk somewhere it constantly adjusts and trees or other objects in front off you show or dissapear all the time, it is noticable and annoying |
17:38 |
|
celeron55 joined #minetest-dev |
17:42 |
|
rubenwardy joined #minetest-dev |
17:45 |
* Fixer |
looks at http://dev.minetest.net/TODO |
17:51 |
|
nrzkt joined #minetest-dev |
17:51 |
Fixer |
RealBadAngel, "RealBadAngel is currently working on shader-based lighting. " you are? |
17:56 |
sofar |
RealBadAngel: if I can choose shaders for nodes in lua, can I use that to fix this: http://i.imgur.com/BgPdJ16.png - note the color/light difference between the two plants - same texture one is just a mesh node other plantlike |
17:57 |
|
Obani joined #minetest-dev |
17:57 |
RealBadAngel |
Fixer, i do have hw lights workin, main problem is that irrlicht can have up to 8 light sources |
17:58 |
RealBadAngel |
so we have to combine our system with irr |
17:58 |
RealBadAngel |
mt has to prepare pure lightmap for the whole scene |
17:58 |
RealBadAngel |
then irrlicht can lit it and combine |
17:58 |
Fixer |
RealBadAngel, 8 light sources? I think that was forever and everywhere, or I'm wrong? |
17:59 |
RealBadAngel |
in mt you can have each node in mapblock be the light source |
17:59 |
RealBadAngel |
whole mt world is single irrlicht scene node |
18:00 |
RealBadAngel |
so while its easy to do sun, its impossible to do torches |
18:00 |
Fixer |
from stackoverflow "8 lights is the limitation of fixed GL pipeline, where you enable each of them, set mode, parameters, etc. Now you have pixel shaders, and lighting is done within shader. There you can use large number of dynamic (not backed into textures) lights. You only need to supply all these lights' parameters sufficiently (maybe, in a texture), and test how many lights your shader is able to process. Also, in shader you can |
18:00 |
Fixer |
cull too weak lights (contributing too little into pixel value) or just too distant ones." |
18:01 |
RealBadAngel |
yeah |
18:01 |
RealBadAngel |
mt has to prepare lightmap texture for the scene |
18:01 |
RealBadAngel |
with own multiple lighht sources |
18:01 |
Fixer |
RealBadAngel, oh wait, TODO has this: "Irrlicht does support occlusion culling. If enabled, it culls scene nodes which are entirely out of the camera's view fulcrum. |
18:01 |
Fixer |
Problem: The entire map is an Irrlicht scene node. Solution: Make scene nodes per MapBlock." |
18:02 |
Fixer |
hmm |
18:02 |
RealBadAngel |
could be done |
18:02 |
RealBadAngel |
but limit of light sources still applies |
18:03 |
RealBadAngel |
so no point to rework it |
18:04 |
RealBadAngel |
for the world like ours only solution is to prepare lightmaps and then count in sun |
18:04 |
Fixer |
except for culing? |
18:04 |
RealBadAngel |
idc bout culling |
18:04 |
RealBadAngel |
not my interest |
18:04 |
Fixer |
RealBadAngel, btw why it is not complete darkness in caves? |
18:05 |
RealBadAngel |
gamma levels |
18:05 |
RealBadAngel |
see light.cpp |
18:05 |
RealBadAngel |
we do have many fancy gimmicks bout light |
18:06 |
RealBadAngel |
atm mt lighting is per vertex lighting |
18:06 |
RealBadAngel |
see irr docs about that |
18:06 |
RealBadAngel |
irr doesnt calculate it, we set it |
18:10 |
nrzkt |
RealBadAngel, if i remember 8 light source is a hardware limitation not irrlicht, it's normal |
18:11 |
Calinou |
nrzkt, lots of games have > 8 light sources in view… |
18:11 |
Calinou |
(real-time) |
18:12 |
Calinou |
all with shadows |
18:12 |
Calinou |
but yeah that's with shaders |
18:12 |
Calinou |
nobody should use fixed-function anymore ( ͡° ͜ʖ ͡°) |
18:13 |
nrzkt |
Calinou, it's not real time it uses deferred shading |
18:15 |
RealBadAngel |
or lightmaps |
18:15 |
RealBadAngel |
which are used to bake in lights into rendered scene |
18:16 |
RealBadAngel |
we are not mature enough for such tricks yet ;) |
18:19 |
Calinou |
don't lightmaps take seconds to bake? |
18:21 |
kahrl |
I remember creating lightmaps for quake2 levels, that process took many hours |
18:21 |
|
nrzkt joined #minetest-dev |
18:22 |
Calinou |
yeah, depends on games |
18:22 |
Calinou |
Cube 2 can do it in seconds |
18:22 |
Calinou |
q3map2 is more like hours :) |
18:27 |
sofar |
RealBadAngel: any idea about my comment on mesh vs. plantlike shader choice fixing that issue I posted earlier? |
18:27 |
sofar |
RealBadAngel: also, I assume placing a torch would cause the engine to regenerate the lightmap then |
18:29 |
RealBadAngel |
sofar. with first please hold on for a few days, i already did 3d plants before, im doing now something WAY better |
18:29 |
RealBadAngel |
on 2nd, yes |
18:30 |
RealBadAngel |
old code have to do lightmaps |
18:30 |
RealBadAngel |
then we need rendering passes |
18:31 |
RealBadAngel |
and combine hw and our artificial lights,, aswell other effects (like reflections, refractions, and post process ones) |
18:31 |
RealBadAngel |
i guess first step should be introduce rendering phases |
18:32 |
RealBadAngel |
and turn off our lights ;) |
18:32 |
RealBadAngel |
then, fiat lux |
18:32 |
sofar |
RealBadAngel: (about the plants placement) oh, I'm not in a hurry, I was just excited to see that I could make a very cool visual change that is highly impactful |
18:33 |
sofar |
will be happy to test what you are cooking |
18:35 |
sofar |
I was thinking of adding a flag to nodedef that would force randomized x,z placement, e.g. placement = "randomxz", or just a boolean |
18:36 |
sofar |
but since scene updates require plants to not move randomly (like I implemented) I'd use some sort of x,y,z based fake noise to vary plant placement |
18:37 |
sofar |
RealBadAngel: what about the stretch part? I do think that's really badly needed |
18:38 |
est31 |
ShadowNinja, congrats to commit #200 btw |
18:49 |
RealBadAngel |
sofar. please do try setting param2 of plants |
18:49 |
RealBadAngel |
it works pretty nice imho |
18:49 |
sofar |
RealBadAngel: I do think that the plantlike mesh being 0.7x1.0x0.7 is incorrect |
18:50 |
RealBadAngel |
sofar, what im coding right now is totally different approach |
18:50 |
sofar |
I'm listening |
18:50 |
RealBadAngel |
imagine moretrees one, l-system plant |
18:50 |
RealBadAngel |
one node sized |
18:50 |
sofar |
(and I will certainly use the param2 setting - I should modify at least mgv7 to use it) |
18:51 |
RealBadAngel |
no more flat textures |
18:51 |
RealBadAngel |
instead real 3d plant |
18:51 |
sofar |
oh the pixel blocky thing you posted earlier? |
18:51 |
RealBadAngel |
kinda like extruded one |
18:51 |
sofar |
right |
18:52 |
RealBadAngel |
but 16x16x16 texture |
18:52 |
sofar |
as long as you don't make the size of it 0.7x1.0x0.7 |
18:52 |
sofar |
;^) |
18:53 |
sofar |
16 bitmaps stacked? |
18:53 |
sofar |
e.g. vertically like animations? |
18:53 |
sofar |
or, can I even animate it? |
18:54 |
sofar |
16x horizontal tiles for each "pane", vertical for animations? |
19:00 |
RealBadAngel |
16x16x16 texture |
19:00 |
RealBadAngel |
stored in meta |
19:00 |
|
zupoman joined #minetest-dev |
19:00 |
|
zupoman joined #minetest-dev |
19:01 |
RealBadAngel |
and each "pixel" of it will be a node, just 1/16th of the size |
19:01 |
RealBadAngel |
hardcoded for best possible performance |
19:02 |
RealBadAngel |
then waving 3d plants wont be any problem |
19:02 |
RealBadAngel |
i will just move 3d pixels |
19:02 |
RealBadAngel |
that was the main reason is stopped developing extruded plants |
19:03 |
RealBadAngel |
i have stopped |
19:03 |
sofar |
IC |
19:03 |
RealBadAngel |
each pixel gonna become a cube |
19:04 |
RealBadAngel |
so i wont be moving planes, just those 3d pixels |
19:04 |
RealBadAngel |
and that will look fucking great. i know that |
19:06 |
|
PenguinDad joined #minetest-dev |
19:06 |
|
luizrpgluiz joined #minetest-dev |
19:10 |
|
Darcidride joined #minetest-dev |
19:13 |
luizrpgluiz |
news which will have the new version of minetest? Version 0.4.14? |
19:14 |
Krock |
We aren't a company with fixed release termins |
19:14 |
VanessaE |
luizrpgluiz: it'll be ready when it's ready |
19:15 |
RealBadAngel |
lol |
19:15 |
VanessaE |
and PLEASE work on your english grammar! |
19:15 |
VanessaE |
half the time, we can't understand a fucking thing you're saying :P |
19:15 |
RealBadAngel |
"when its done" is reserved and trademarked |
19:15 |
Krock |
VanessaE, are you mad or just rude? :( |
19:16 |
VanessaE |
Krock: both :P |
19:16 |
Krock |
RealBadAngel, lol serisously? |
19:16 |
nrzkt |
what else is also trademarked, stop use it |
19:16 |
RealBadAngel |
yeah, and she bites, so watch out :P |
19:16 |
VanessaE |
RealBadAngel: at least that comes sooner than "Real Soon Now"â„¢ :) |
19:16 |
RealBadAngel |
Krock, see DukeNukem Forever story |
19:17 |
|
H-H-H joined #minetest-dev |
19:17 |
* sofar |
quietly steps backwards |
19:17 |
VanessaE |
RAWWWR |
19:17 |
VanessaE |
*chomp* |
19:17 |
* sofar |
throws a raw steak |
19:17 |
VanessaE |
lol |
19:18 |
* RealBadAngel |
can see a steak flyin back - medium roasted please |
19:19 |
sofar |
my charcoal grill is in winter sleep, sorry |
19:21 |
VanessaE |
sofar: at least you don't use propane. :) |
19:21 |
|
Darcidride joined #minetest-dev |
19:21 |
sofar |
duh, I'm not an idiot. Even an oven is better than propane |
19:21 |
VanessaE |
heh |
19:22 |
RealBadAngel |
nothing like propane lighter, and piece of meant fried in seconds |
19:22 |
RealBadAngel |
that smell ;) |
19:22 |
|
zupoman joined #minetest-dev |
19:22 |
|
zupoman joined #minetest-dev |
19:22 |
RealBadAngel |
*meat |
19:22 |
sofar |
you haven't had my slow-smoked tri-tip yet |
19:23 |
RealBadAngel |
folks at construction places are having weird ideas |
19:23 |
sofar |
haha, yeah |
19:23 |
RealBadAngel |
ive seen a lot, believe me |
19:24 |
sofar |
I did some odd jobs over summers, I believe you |
19:24 |
RealBadAngel |
you know what is the best glue for example? |
19:24 |
sofar |
not wood putty |
19:24 |
RealBadAngel |
better than composite ones, harder than concrete |
19:25 |
RealBadAngel |
milk with cornflakes |
19:25 |
sofar |
that what I eat for breakfast |
19:25 |
Krock |
You eat glue for breakfast |
19:25 |
RealBadAngel |
make a test |
19:25 |
sofar |
glue my bowels shut so I can stand to last until lunch |
19:25 |
RealBadAngel |
leave it for a week or two in a dish |
19:26 |
RealBadAngel |
you will never take the spoon out of it |
19:26 |
sofar |
does it polymerize? |
19:26 |
RealBadAngel |
there was a tv programme, myth busters i think about it |
19:27 |
RealBadAngel |
they tried to blow it out with dynamite i think |
19:30 |
VanessaE |
seriously? |
19:31 |
RealBadAngel |
look for "myth busters" series |
19:31 |
VanessaE |
we're all familiar with Mythbusters |
19:31 |
Calinou |
systemd busters! |
19:32 |
VanessaE |
Calinou: no, that needs something a lot better than Mythbusters :) |
19:32 |
VanessaE |
like "this week in high explosives" :P |
19:33 |
|
Kray joined #minetest-dev |
19:34 |
RealBadAngel |
anyway, im off to coding, still have lotsa to do |
19:46 |
|
zupoman joined #minetest-dev |
19:46 |
|
zupoman joined #minetest-dev |
20:36 |
|
luizrpgluiz left #minetest-dev |
20:49 |
|
zupoman joined #minetest-dev |
20:49 |
|
zupoman joined #minetest-dev |
20:57 |
sofar |
Calinou: I've contributed significantly to systemd... lol. blowing that up? over my dead... well just go easy on it |
21:00 |
* sofar |
logs in on a 40-core machine, and goes "wheeeeeee!" |
21:08 |
VanessaE |
it's systemd..... lots of geeks hate it :) (I don't care too much either way, actually, unless the maintainers start enforcing the idea of binary logs etc) |
21:08 |
VanessaE |
(at which point, it crosses the line) |
21:09 |
exio4 |
VanessaE: they're already doing so, anyway, 'cause they love the idea of some kind of unification of the linux core packages into systemd, I guess that is what keeps their NIH syndrome going on |
21:10 |
VanessaE |
*groan* |
21:10 |
VanessaE |
what we had worked well enough .... |
21:10 |
est31 |
yet another systemd discussion on the internet |
21:23 |
|
Robert_Zenz joined #minetest-dev |
21:24 |
VanessaE |
est31: well it IS systemd, so it's a fair target for jokes :) |
21:25 |
est31 |
sofar, what did you contribute? |
21:26 |
|
nolsen joined #minetest-dev |
21:26 |
sofar |
est31: various fixes, but most importantly systemd-bootchartd in it's entirety |
21:26 |
|
Kray joined #minetest-dev |
21:27 |
sofar |
VanessaE: you're entirely right that "it worked well enough", the problem is that it only worked well enough for the people in the ecosystem that had been around for 20 years |
21:28 |
VanessaE |
I suppose so |
21:28 |
sofar |
lack of progress == deterioration |
21:28 |
sofar |
just look at US politics |
21:28 |
sofar |
;^) |
21:28 |
VanessaE |
heh |
21:29 |
sofar |
btw, the same goes for minetest. if minetest development would stagnate, then that's going to be the end of it, really fast |
21:33 |
sofar |
I'm not the doomtalker kind. I'm the "let's prevent this" type who hopes people can abandon their fear of change type |
21:45 |
est31 |
minetest development does stagnate |
21:46 |
est31 |
tons of stuff gets proposed all the time |
21:46 |
est31 |
and lots of it cant be merged |
21:46 |
est31 |
or just people missing to look at it |
21:46 |
est31 |
and we perform quite badly |
21:46 |
est31 |
server is essentially single threaded |
21:47 |
est31 |
emerge threads have huge bureocracy overhead |
21:47 |
sofar |
nod |
21:47 |
est31 |
map that gets sent is re-compressed for every single player |
21:47 |
est31 |
if there are 20 players, it recompresses the same map for all 20 of them |
21:47 |
sofar |
even if they're in the same area? |
21:47 |
est31 |
and if its a mapblock filled with all air, it still gets recompressed |
21:47 |
est31 |
yes |
21:47 |
est31 |
even then |
21:47 |
sofar |
can you compress in a separate thread? |
21:48 |
est31 |
at least I think so |
21:48 |
est31 |
you could yes |
21:48 |
est31 |
but that would require to copy the map over |
21:48 |
sofar |
mmap? |
21:48 |
est31 |
or to have smarter locking mechanisms |
21:48 |
sofar |
copy on write? |
21:48 |
est31 |
can mmap do COW stuff |
21:48 |
sofar |
linux kernel can handle that |
21:49 |
est31 |
ohhhh |
21:49 |
est31 |
cooool! |
21:49 |
sofar |
I have smart colleagues that do stuff like that |
21:49 |
est31 |
is that unix thing, or torvalds one? |
21:49 |
sofar |
not sure, actually |
21:50 |
sofar |
man 7 mmap-> MAP_PRIVATE |
21:50 |
Fixer |
that is offtopic, please fix liquids over ignore :} |
21:50 |
sofar |
Fixer: very on-topic. go chase your fluids for a bit :P |
21:51 |
Fixer |
sofar, there is minetest for a offtopic disscussion |
21:51 |
Fixer |
#minetest |
21:52 |
est31 |
Fixer, we do talk about minetest development. |
21:52 |
sofar |
Fixer: cow for map updates would be higly beneficial for minetest-core |
21:54 |
sofar |
est31: you can do CoW stuff in C++, it wouldn't be too hard either, not sure how the data model looks whether how hard it would be |
21:55 |
sofar |
BSD mmap() has supported MAP_PRIVATE for decades |
21:57 |
nrzkt |
sofar and what about windows ? |
21:57 |
sofar |
est31: since we're talking about in-memory map data, I think you'll end up having to mmap() it to shmem, and from there you can re-mmap() with MAP_PRIVATE to all consumers |
21:57 |
nrzkt |
and compression on a separate thread is useless if you spawn thread only for it. You will generate overhead for nothing. Better is to switch from zlib to lz4 |
21:57 |
sofar |
nrzkt: they'd fall back to the memcpy() code that is slow, likely |
21:58 |
nrzkt |
i changed my mapblock database compression from zlib to lz4 and i don't see any compression overhead now |
21:58 |
sofar |
nrzkt: not if that thread is already running and ready to go, and mmap()'s the result back to the sender |
21:58 |
sofar |
plus minetest's zlib probably needs cpu acceleration |
21:58 |
Fixer |
help RBA to code last bit of 3199 that can reduce bandwidth usage so you will not need to change anything :} |
21:59 |
nrzkt |
Fixer, this PR with meta changes ? I had it on my server it's good for clients, server don't care about it |
21:59 |
Fixer |
yeah |
21:59 |
Fixer |
clients care :} |
21:59 |
sofar |
https://github.com/jtkukunas/zlib/commit/d306c75d3bb36cba73aec9b3b3ca378e31d1799e |
21:59 |
nrzkt |
my client thanks me about this fix |
21:59 |
sofar |
stuff like that |
21:59 |
Fixer |
i mean people who play it |
21:59 |
sofar |
(jkukunas is one of my colleagues) |
22:00 |
nrzkt |
using LZ4 is better than added patched to patched to patches to zlib |
22:00 |
nrzkt |
lz4 CPU usage is nothing |
22:00 |
sofar |
but breaks protocol |
22:00 |
Fixer |
but is it a main problem? |
22:00 |
est31 |
yes |
22:01 |
est31 |
protocol breaks should be avoided |
22:01 |
nrzkt |
no need to break the protocol, just bump |
22:01 |
est31 |
but we can bump it |
22:01 |
nrzkt |
mapblocks are versionned |
22:01 |
est31 |
exactly |
22:01 |
est31 |
just have to keep old code around for legacy clients |
22:01 |
nrzkt |
exact |
22:02 |
est31 |
soooo wikipedia says lz4 is in fact slower than gzip |
22:02 |
est31 |
not faster? |
22:02 |
sofar |
compression algorithms are all the rage, but the question is fast vs. small. and zlib still beats everything overall |
22:03 |
sofar |
you want fast? you get less compression |
22:03 |
sofar |
you want small? you get less speed |
22:03 |
sofar |
you want the best mix of fast and small? for all different types of data? you'll end up with zlib as the best choice when you look at the data |
22:03 |
est31 |
usual tradeoff of information technology |
22:03 |
sofar |
(I'm quoting Jim here) |
22:04 |
sofar |
jim = jkukunas |
22:04 |
est31 |
ok |
22:04 |
nrzkt |
est31 for linux kernel and ZFS datasets LZ4 is better than GZIP |
22:04 |
est31 |
sofar, this his blog? http://jkukunas.blogspot.com/ |
22:04 |
sofar |
yes, it's a specific data set |
22:04 |
sofar |
lz4 for linux kernels is good because of high decompression speed |
22:04 |
est31 |
you work at intel? |
22:05 |
sofar |
since you compress once, and thousands of people decompress |
22:05 |
sofar |
est31: yes. auke-jan.h.kokintel.com |
22:05 |
nrzkt |
in MT you do less writes than read |
22:05 |
est31 |
O.o |
22:05 |
sofar |
I just had pizza for lunch with Jim. He's moving states. |
22:06 |
sofar |
est31: well, I should be working right ... well now... cough |
22:06 |
est31 |
but still the count of writes is comparatively large nrzkt. compare minetest with youtube video that gets encoded at upload, then gets watched millions of times |
22:06 |
nrzkt |
est31 in singleplayuer read ~= write, with 20 players it's not the same case. |
22:07 |
sofar |
well you're symmetrical - each mapblock gets compressed and decompressed once |
22:07 |
nrzkt |
i should go |
22:07 |
* sofar |
waves... thinking he should go back to work as well ;^) |
22:07 |
* est31 |
should not waste time on irc either ... :) |
22:08 |
* est31 |
presses the button with the little cross |
22:08 |
sofar |
studies? wife? work? jail time? |
22:08 |
sofar |
lol |
22:18 |
|
nolsen_ joined #minetest-dev |
22:40 |
|
Terusthebird joined #minetest-dev |
22:47 |
|
nolsen joined #minetest-dev |
23:03 |
|
DFeniks joined #minetest-dev |
23:23 |
|
Terusthebird joined #minetest-dev |