| Time |
Nick |
Message |
| 00:20 |
|
OldCoder joined #minetest-dev |
| 01:48 |
Miner_48er |
kaeza any additional info you need to help with that xban2 issue? |
| 02:06 |
|
khonkhortisan joined #minetest-dev |
| 02:08 |
|
zat joined #minetest-dev |
| 02:10 |
|
zat joined #minetest-dev |
| 02:17 |
|
us`0gb joined #minetest-dev |
| 02:25 |
|
zat joined #minetest-dev |
| 02:50 |
|
CraigyDavi`` joined #minetest-dev |
| 02:57 |
|
zat joined #minetest-dev |
| 03:03 |
|
zat joined #minetest-dev |
| 03:06 |
|
diemartin joined #minetest-dev |
| 03:15 |
|
zat joined #minetest-dev |
| 03:52 |
|
CraigyDavi` joined #minetest-dev |
| 05:00 |
|
CraigyDavi joined #minetest-dev |
| 05:03 |
|
CraigyDavi`` joined #minetest-dev |
| 05:17 |
|
CraigyDavi` joined #minetest-dev |
| 05:20 |
|
CraigyDavi joined #minetest-dev |
| 05:42 |
ShadowNinja |
''tell sapier That bug isn't reproducable AFAIK, send me any debug info you can get on it, but it may be beyond my understanding. Also, I'd suggest using distance instead of time for the movement prediction patch to make it more precise. |
| 05:42 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 05:43 |
|
Hunterz joined #minetest-dev |
| 05:46 |
|
hax404 joined #minetest-dev |
| 05:46 |
|
grrk-bzzt joined #minetest-dev |
| 06:12 |
|
CraigyDavi` joined #minetest-dev |
| 06:14 |
|
LemonLake joined #minetest-dev |
| 06:15 |
|
CraigyDavi`` joined #minetest-dev |
| 06:19 |
|
seamus_ joined #minetest-dev |
| 06:20 |
|
Garmine joined #minetest-dev |
| 06:29 |
|
CraigyDavi` joined #minetest-dev |
| 06:31 |
|
harrison__ joined #minetest-dev |
| 06:33 |
|
Kray_ joined #minetest-dev |
| 06:35 |
|
Taoki joined #minetest-dev |
| 06:35 |
|
grrk-bzzt joined #minetest-dev |
| 06:35 |
|
RealBadAngel joined #minetest-dev |
| 06:36 |
|
cheapie joined #minetest-dev |
| 06:37 |
|
VargaD joined #minetest-dev |
| 07:29 |
|
PenguinDad joined #minetest-dev |
| 08:03 |
|
PenguinDad joined #minetest-dev |
| 08:25 |
|
kahrl joined #minetest-dev |
| 08:30 |
|
Calinou joined #minetest-dev |
| 08:33 |
|
CraigyDavi joined #minetest-dev |
| 08:37 |
|
CraigyDavi` joined #minetest-dev |
| 08:50 |
Calinou |
how sane is it to use “dedicated_server_step = 0.01"? |
| 08:53 |
celeron55 |
if you want 100% CPU consumption, i guess that's quite effective |
| 08:55 |
Calinou |
https://forum.minetest.net/viewtopic.php?f=3&t=9766&p=148708#p148684 |
| 08:55 |
Calinou |
this guy's server seems to defy logic then |
| 08:57 |
celeron55 |
it depends on player count of course |
| 09:02 |
|
OldCoder joined #minetest-dev |
| 09:21 |
|
CraigyDavi`` joined #minetest-dev |
| 09:32 |
|
Jordach joined #minetest-dev |
| 09:56 |
|
proller joined #minetest-dev |
| 09:59 |
|
proller joined #minetest-dev |
| 10:16 |
|
CraigyDavi joined #minetest-dev |
| 10:24 |
|
CraigyDavi` joined #minetest-dev |
| 10:26 |
|
CraigyDavi`` joined #minetest-dev |
| 11:04 |
|
Megaf joined #minetest-dev |
| 11:09 |
Megaf |
Minetest is segfaulting so often now a days that we have a server named Meowtest "SEGFAULTY" |
| 11:10 |
Megaf |
and as we know, segfault means code error |
| 11:11 |
Megaf |
19:05:24: ACTION[ServerThread]: FireStar places node wool:red at (479,16,56) |
| 11:11 |
Megaf |
Segmentation fault |
| 11:14 |
VanessaE |
... |
| 11:20 |
|
Megaf joined #minetest-dev |
| 11:27 |
|
Megaf joined #minetest-dev |
| 11:35 |
|
Megaf joined #minetest-dev |
| 11:36 |
|
kaeza joined #minetest-dev |
| 11:37 |
|
CraigyDavi joined #minetest-dev |
| 11:38 |
|
ImQ009 joined #minetest-dev |
| 11:49 |
|
Megaf joined #minetest-dev |
| 11:54 |
|
Megaf joined #minetest-dev |
| 11:57 |
|
smoke_fumus joined #minetest-dev |
| 12:01 |
|
EvergreenTree joined #minetest-dev |
| 12:11 |
|
Megaf joined #minetest-dev |
| 12:12 |
|
Krock joined #minetest-dev |
| 13:23 |
|
vifino joined #minetest-dev |
| 13:41 |
|
AnotherBrick joined #minetest-dev |
| 13:42 |
RealBadAngel |
https://www.youtube.com/watch?v=ixgAxnBTIi4 |
| 13:42 |
RealBadAngel |
any objections on adding param2 to plantlike? |
| 14:00 |
|
PilzAdam joined #minetest-dev |
| 14:09 |
RealBadAngel |
PilzAdam, https://www.youtube.com/watch?v=ixgAxnBTIi4 |
| 14:10 |
RealBadAngel |
how do you like it? |
| 14:18 |
PilzAdam |
why param2? and why are the plants flipping when being placed? |
| 14:19 |
RealBadAngel |
param2 because its made for things like that, and flipping because i just modified grass def, with after_place |
| 14:20 |
PilzAdam |
what are "things like that"? |
| 14:20 |
RealBadAngel |
modifiers |
| 14:20 |
Zefram_Fysh |
in this case controlling the rotation? |
| 14:20 |
RealBadAngel |
its just additional variable we can use |
| 14:20 |
RealBadAngel |
code for that is dead simple |
| 14:20 |
RealBadAngel |
2 lines in core modified |
| 14:22 |
|
smoke_fumus|2 joined #minetest-dev |
| 14:23 |
|
diemartin joined #minetest-dev |
| 14:25 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L1119 ---> http://pastebin.com/m9jdAdrY |
| 14:27 |
|
LemonLake joined #minetest-dev |
| 14:32 |
|
werwerwer joined #minetest-dev |
| 14:37 |
|
AnotherBrick joined #minetest-dev |
| 14:37 |
|
smoke_fumus joined #minetest-dev |
| 14:41 |
PenguinDad |
PilzAdam: #802 seems to be fixed |
| 14:42 |
|
hmmmm joined #minetest-dev |
| 14:46 |
|
Calinou joined #minetest-dev |
| 14:54 |
|
CraigyDavi` joined #minetest-dev |
| 14:54 |
|
Krock2 joined #minetest-dev |
| 14:55 |
|
FungusAdam joined #minetest-dev |
| 14:57 |
|
kahrl_ joined #minetest-dev |
| 15:02 |
|
GhostDoge joined #minetest-dev |
| 15:25 |
|
Garmine joined #minetest-dev |
| 15:43 |
|
Calinou joined #minetest-dev |
| 15:45 |
|
harrison joined #minetest-dev |
| 15:59 |
|
AnotherBrick joined #minetest-dev |
| 16:09 |
|
Hunterz joined #minetest-dev |
| 16:13 |
|
zat joined #minetest-dev |
| 16:15 |
|
grrk-bzzt joined #minetest-dev |
| 16:15 |
|
grrk-bzzt joined #minetest-dev |
| 16:19 |
Krock |
again |
| 16:19 |
Krock |
- Krock quit (*.net *.split) |
| 16:19 |
Krock |
wtf |
| 16:19 |
|
Krock left #minetest-dev |
| 16:20 |
|
Krock joined #minetest-dev |
| 16:38 |
|
paramat joined #minetest-dev |
| 16:39 |
paramat |
RealBadAngel, i made this issue to remind you ;) https://github.com/minetest/minetest/issues/1462 |
| 16:44 |
|
gourytch joined #minetest-dev |
| 17:02 |
|
sapier joined #minetest-dev |
| 17:04 |
sapier |
ShadowNinja: Time is already present in engine, distance would've to be calculated separate and as I mentioned in discussion on minetest would introduce quite some new ways to get inconsistent states. |
| 17:04 |
sapier |
For a bug not beeing reproduceable I had it quite often yesterday .. guess about 40 times |
| 17:04 |
sapier |
within only a few hours |
| 17:05 |
sapier |
I wasn't able to exactly locate it but it somehow seems to be related to punching and dieing |
| 17:06 |
sapier |
another important thing may be that there's no player involved |
| 17:07 |
|
us`0gb joined #minetest-dev |
| 17:11 |
|
ImQ009 joined #minetest-dev |
| 17:13 |
sapier |
megaf could you try to find out what is done to do the segfault? or run in debugger so we get a backtrace |
| 17:18 |
Megaf |
sapier; it happens miliseconds after you start minetest |
| 17:18 |
Megaf |
or right after you put your password and press login |
| 17:22 |
sapier |
no it doesn't |
| 17:23 |
sapier |
just tried didn't happen (for me) |
| 17:32 |
paramat |
Here are 2 proposals for improving my wieldhand texture https://github.com/minetest/minetest_game/issues/266 |
| 17:44 |
|
paramat left #minetest-dev |
| 17:44 |
Calinou |
“mgv6_freq_desert = 0.4†is lower more deserts or less?! |
| 17:44 |
Calinou |
I want a world with a lot of beaches, but less deserts |
| 18:01 |
RealBadAngel |
bump: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L1119 ---> http://pastebin.com/m9jdAdrY |
| 18:02 |
RealBadAngel |
https://www.youtube.com/watch?v=ixgAxnBTIi4 |
| 18:02 |
RealBadAngel |
any objections? :) |
| 18:03 |
sapier |
I don't like "this video isn't available" ;-) |
| 18:04 |
Calinou |
mgv6_np_beach = 0, 1, (250, 250, 250), 59420, 3, 0.5 → WTF does each setting mean? |
| 18:04 |
Calinou |
many values have a similar formatting |
| 18:04 |
RealBadAngel |
sapier, ? |
| 18:05 |
sapier |
hmm ok youtube isn't kompatible to conqueror only |
| 18:05 |
sapier |
what exactly is the change? |
| 18:06 |
RealBadAngel |
make plantlike twisted by holding additional angle in param2 |
| 18:06 |
RealBadAngel |
0 - no change, current behaviour |
| 18:06 |
sapier |
what's param2 usually used for? |
| 18:06 |
RealBadAngel |
many things |
| 18:07 |
RealBadAngel |
level, 6dfacedir, wallmounted dir |
| 18:07 |
|
SoniEx2 joined #minetest-dev |
| 18:08 |
sapier |
so it's not abusing it |
| 18:08 |
RealBadAngel |
each drawtype can do with it whatever it wants to |
| 18:08 |
RealBadAngel |
plantlike had no use for it before |
| 18:09 |
sapier |
well I'd suggest to ask someone else too but I don't see a reason not to add it by now |
| 18:10 |
RealBadAngel |
ok |
| 18:17 |
|
AnotherBrick joined #minetest-dev |
| 18:19 |
RealBadAngel |
and what about https://github.com/minetest/minetest/pull/1487 ? |
| 18:21 |
sapier |
RBA I always wonder why you have to mix in behaviour changes to commits telling something different |
| 18:22 |
sapier |
e.g. the contrast changes... I don't know if they're good or bad I only no they're irrelevant for speed |
| 18:22 |
RealBadAngel |
see the changes |
| 18:22 |
RealBadAngel |
theres no sqrt and x*x there anymore |
| 18:23 |
RealBadAngel |
takin that it was calculated for each vertex, its a speedup, dont you think? |
| 18:24 |
sapier |
sounds even worse you change the behaviour of a function while keeping signature identical ... |
| 18:25 |
RealBadAngel |
contrast? |
| 18:26 |
RealBadAngel |
it does exactly the same thing as before |
| 18:26 |
sapier |
not for what I understand |
| 18:27 |
sapier |
sqrt(0.3) != 0.4 |
| 18:28 |
RealBadAngel |
that idiotic pow and sqrt wasnt my idea, and is completely wrong |
| 18:28 |
sapier |
possible so if you do understand what's done there please explain |
| 18:29 |
sapier |
right now the only thing I can tell for sure it's not a format change only but really changes value |
| 18:31 |
RealBadAngel |
http://irrlicht.sourceforge.net/docu/_s_vertex_manipulator_8h_source.html |
| 18:31 |
RealBadAngel |
see line #97 |
| 18:32 |
RealBadAngel |
this is used only to apply faces shading, so simple contrast change |
| 18:33 |
RealBadAngel |
before there was used SRGB to linear color change so color^2 * factor, then sqrt to get modified value back |
| 18:33 |
sapier |
So what's the result of that change? for what I see it's for 0.3 -> 0.4 effectively changing 0.55->0.4 |
| 18:34 |
sapier |
I don't know the range of that value |
| 18:34 |
RealBadAngel |
it doesnt really matter if result gonna be slightly different |
| 18:34 |
sapier |
if it's 0-100 that change is most likely irrelevant but if it's 0-1 it's more then significant |
| 18:34 |
RealBadAngel |
its used only to make top brighter and faces darker |
| 18:35 |
sapier |
so we will have more or less contrast? |
| 18:35 |
RealBadAngel |
you wont notice a difference |
| 18:35 |
RealBadAngel |
just check it out |
| 18:35 |
sapier |
where do I have to look at? |
| 18:36 |
RealBadAngel |
fire up the game with patch |
| 18:36 |
RealBadAngel |
and look around |
| 18:36 |
RealBadAngel |
it affects all the nodes you can see |
| 18:37 |
sapier |
ok I'll do some screenshots ... hopefully you're right, if not I'll not be amused as it'd be your job to mention significant changes and not silently hide them in a "performance improvement" commit |
| 18:38 |
RealBadAngel |
i cant see any difference, sfan5 and VanessaE neither |
| 18:38 |
sapier |
possible as I said if range of that value is big enough nothing will happen |
| 18:38 |
sfan5 |
if you put before/after side-by-side you can see a small diff |
| 18:38 |
RealBadAngel |
propably yes |
| 18:38 |
sfan5 |
you won't notice otherwise |
| 18:39 |
sapier |
well I don't care about small changes what I don't like is them not beeing mentioned |
| 18:40 |
sapier |
because sometimes they aren't as small as they seem to be in some special cases |
| 18:41 |
VanessaE |
I certainly didn't notice a change when I tested his patch before, only a very slight performance improvement (marginal, hard to be sure if there was any improvement) |
| 18:41 |
VanessaE |
certainly wasn't any *loss* |
| 18:41 |
RealBadAngel |
you have fast box |
| 18:41 |
RealBadAngel |
for me gain is huge |
| 18:41 |
RealBadAngel |
2x better view distance at least |
| 18:42 |
VanessaE |
yeah but Minetest is heavily CPU-bound for me, any improvements in FPS etc are gonna have to happen in whatever parts of its rendering pipeline occur there rather than the GPU |
| 18:42 |
RealBadAngel |
i do have 1.8ghz dual core and older radeon |
| 18:42 |
RealBadAngel |
this is rater CPU change |
| 18:42 |
VanessaE |
ok |
| 18:42 |
RealBadAngel |
not GPU |
| 18:43 |
RealBadAngel |
when i start to think, nothing in this code makes GPU things faster |
| 18:43 |
Calinou |
CPU changes are still good, very useful for gameplay with client + server |
| 18:43 |
Calinou |
it's probably more important than GPU right now |
| 18:43 |
sapier |
removing that sqrt is a good idea for sure what I still don't understand is why the values had to be changed too ... they're not even close to what'd result on just using the original values |
| 18:43 |
VanessaE |
ok then what I saw was legit |
| 18:44 |
VanessaE |
sapier: maybe the same reason people often give measures of 0.1 when designing a nodebox, instead of measures of 0.0625. it's easier to write, even if it's horribly inaccurate. |
| 18:44 |
sapier |
where does minetest save it's screenshots? |
| 18:44 |
VanessaE |
sapier: in the current dir |
| 18:44 |
Calinou |
sadly |
| 18:44 |
VanessaE |
unless you have screenshot path set |
| 18:44 |
Calinou |
should just be ~/.minetest/screenshots by default |
| 18:45 |
VanessaE |
screenshot_path = <foo> in case you want to fix it somewhere sane,. |
| 18:46 |
Krock |
ehm. it saves a white image there when I use F12 |
| 18:46 |
Calinou |
if it's set, can't take screenshots |
| 18:46 |
RealBadAngel |
sapier, i can fine tune the values to be the same as before if you insist |
| 18:46 |
Calinou |
oh, directory must exist |
| 18:46 |
Calinou |
created screenshots dir by hand |
| 18:47 |
sapier |
hmmm for what I see we loose contrast |
| 18:50 |
RealBadAngel |
does it really matter when such gfx freak like VanessaE is ok with it? ;) |
| 18:50 |
VanessaE |
:P |
| 18:50 |
sapier |
yes you should do that RealBadAngel especially as you forgot some values |
| 18:50 |
sapier |
It's quite visible for my wood ceiling at night |
| 18:50 |
VanessaE |
"gfx freak" he calls me :P |
| 18:50 |
RealBadAngel |
ok, i will fine tune the values |
| 18:51 |
RealBadAngel |
please review the rest of the code, now im off to work |
| 18:51 |
sapier |
old version did show wood texture cleanly while new variant is almost stripes |
| 18:51 |
VanessaE |
stripes? |
| 18:51 |
VanessaE |
screenshot? |
| 18:52 |
Calinou |
fix wood texture then |
| 18:52 |
Calinou |
compare using these textures maybe: https://dl.dropboxusercontent.com/u/82342922/minetest/carbone-minetest-pack.zip |
| 18:53 |
sapier |
it's default texture and reduction of contrast is not a texture issue |
| 18:54 |
Calinou |
the game feels pretty contrasted currently; before 0.4.10, it was way less contrasted |
| 18:54 |
sapier |
main difference seems to be downside of nodes is darker while upside seems to be brighter ... http://imgur.com/GRqwqOz,urNcLTW |
| 18:56 |
VanessaE |
sapier: well seems like that should easy enough to tweak in his code. mapblock_mesh.cpp lines 1147 and 1149 |
| 18:57 |
VanessaE |
however it looks like he only changed the bottom, not the top |
| 18:57 |
sapier |
for what I see every node changes |
| 18:57 |
sapier |
well at least some values haven't been changed at all ;-) |
| 18:58 |
VanessaE |
anyway if the bottom is too dark then just raise that value on line 1149 a little further |
| 19:00 |
PenguinDad |
but the bottom face shouldn't be brighter than the top face imo |
| 19:00 |
sapier |
some of the values are quite close to what they used to be I'll check if I get an exact match if I change it to that value |
| 19:01 |
VanessaE |
better change the other figures too then |
| 19:02 |
VanessaE |
I guess 0.71 for those |
| 19:21 |
VanessaE |
any luck? |
| 19:25 |
sapier |
sorry had to do a rescue operation for a sheep ... a real one |
| 19:25 |
VanessaE |
oh? |
| 19:26 |
sapier |
actually a lamb that went into a tube below a street and didn't get out of there on it's own |
| 19:26 |
VanessaE |
wow |
| 19:26 |
VanessaE |
glad you were able to help the poor thing. |
| 19:26 |
sapier |
stupid animal |
| 19:27 |
sapier |
I'm not that sure my mobf animal are really more stupid then real ones ;-) |
| 19:27 |
VanessaE |
haha |
| 19:27 |
Krock |
mobs do what the programmers say, and if the mobs so stupid things, then ... ehm yes |
| 19:27 |
sapier |
http://imgur.com/EqOqG6F,p7LKwLf,lZHDSBE |
| 19:27 |
Krock |
*do |
| 19:28 |
sapier |
better ... but I still seem to have missed something |
| 19:28 |
sapier |
the wall still seems to be more dark then originally |
| 19:29 |
VanessaE |
which one of these images is the original code before the patch? |
| 19:30 |
sapier |
ahh still wrong value |
| 19:32 |
sapier |
the dirty git is the one I fixed, the dark ceiling is rba |
| 19:33 |
sapier |
first=original second=rba third=mine |
| 19:34 |
VanessaE |
hm, yeah that far wall (with the windows) does look just slightly darker in yours |
| 19:34 |
sapier |
I missed some value just trying corrected one |
| 19:34 |
VanessaE |
right wall too. but the left wall and ceiling look the same. |
| 19:34 |
VanessaE |
oh ok |
| 19:35 |
VanessaE |
(compared to the original that is) |
| 19:35 |
sapier |
http://imgur.com/Ed4wiSi,OuXex2u,KnGJ0hH#0 that's back to normal, same first=orig ... |
| 19:36 |
sapier |
https://gist.github.com/sapier/7ccc51c71a31f3ab984c |
| 19:36 |
VanessaE |
I'd call it good. |
| 19:36 |
VanessaE |
certainly good enough to merge anyway as far as the lighting is concerned. |
| 19:37 |
sapier |
I'd like to know why RealBadAngel changed it at all? Was it just beeing to lazy to calculate it correct or intentionally ;-) |
| 19:37 |
VanessaE |
idk, and he's probably gone off to work by now :) |
| 19:37 |
VanessaE |
(probably too lazy to calculate it correctly ;) ) |
| 19:37 |
sapier |
thought rba is in europe too? |
| 19:38 |
VanessaE |
Poland, but he works odd hours |
| 19:38 |
sapier |
I see |
| 19:38 |
sapier |
well my value are rounded to two digits behind comma too but that seems to be close enough |
| 19:40 |
sapier |
conclusion if there's a reason to change it we should talk about it again if not I don't like this to be merged with different values then the original ones |
| 19:41 |
VanessaE |
parse error in function sapier.english(). attempted translation: we should not merge at all, and talk about this regardless. :) |
| 19:41 |
sapier |
almost :-) |
| 19:42 |
sapier |
what I meant is if there's reason to change that contrast numbers I'd like to know them. If there is no reason they should be fixed to result in same contrast as before |
| 19:42 |
VanessaE |
in that case, I say go with the numbers you just came up with |
| 19:43 |
VanessaE |
if they work for you, they work. period. :) |
| 19:43 |
VanessaE |
merge and move on. |
| 19:44 |
sapier |
why do you always expect me to merge everything ;-) |
| 19:44 |
VanessaE |
because you're good at it? :) |
| 19:45 |
sapier |
sounds like a curse |
| 19:45 |
VanessaE |
hahahah |
| 19:56 |
celeron55 |
what |
| 19:57 |
celeron55 |
so you removed my sRGB<->linear space multiplications? |
| 19:57 |
celeron55 |
there's a reason for those you know |
| 19:58 |
celeron55 |
it's an approximation of the 2.2 (1.8 on macs) gamma used on screens |
| 19:58 |
sapier |
you're not talking about the contrast thing aren't you? |
| 19:58 |
celeron55 |
which is applied in order to make vertex color multiplications in linear space and then converted back to screen gamma |
| 19:58 |
celeron55 |
sqrt is 2, which is close enough to those |
| 19:58 |
celeron55 |
yes, i don't understand why it's called contrast |
| 19:58 |
celeron55 |
i'm pretty sure i didn't call it that when it wrote it |
| 19:59 |
sapier |
still what's the difference in specifying to pass the sqrt value instead of calculating it inside? |
| 19:59 |
celeron55 |
? |
| 19:59 |
sapier |
applyContrast second parameter |
| 20:00 |
sapier |
mapblock_mesh.cpp |
| 20:00 |
celeron55 |
it isn't specified that way, right? |
| 20:01 |
sapier |
true but why pass a value just to calculate sqrt from it if the only usage is for compile time known parameters |
| 20:02 |
sapier |
sqrt(x*x*y) == sqrt(x*x) * sqrt(y) == x * sqrt(y) |
| 20:03 |
sapier |
hope I didn't forget to much about math the last years :-) |
| 20:04 |
sfan5 |
sapier: good news ;), MinetestBot just confirmed me that what you said is right |
| 20:05 |
sapier |
what exactly? |
| 20:05 |
sfan5 |
<sfan5> !c math.sqrt(5*5*7), math.sqrt(5*5) * math.sqrt(7), 5 * math.sqrt(7) |
| 20:05 |
sfan5 |
<MinetestBot> (13.228756555322953, 13.228756555322953, 13.228756555322953) |
| 20:05 |
sapier |
ahh ok :-) |
| 20:05 |
celeron55 |
yes it really is so, now i'm wondering why i didn't do it that way originally |
| 20:05 |
|
CraigyDavi` joined #minetest-dev |
| 20:06 |
celeron55 |
this doesn't make intuitive sense to me at all and i need to figure out why |
| 20:06 |
celeron55 |
(i mean, colorspace-wise) |
| 20:06 |
celeron55 |
(math-wise it does) |
| 20:06 |
sapier |
ok then I'm not gonna merge it now maybe there's reason we don't understand yet |
| 20:07 |
VanessaE |
damn it why does RealBadAngel always have to start this stuff right before work :-/ |
| 20:07 |
sapier |
well if he didn't change the values it'd already be merged too ;-) |
| 20:07 |
|
CraigyDavi`` joined #minetest-dev |
| 20:08 |
celeron55 |
oh now i understand why it works that way |
| 20:09 |
celeron55 |
does anyone in here know anything about colorspaces or should i just skip any explanations? 8) |
| 20:09 |
sapier |
I don't have any idea :-) |
| 20:09 |
VanessaE |
I only know a little about it. |
| 20:09 |
celeron55 |
as long as the values are replaced by the sqrt of the previous value, it's fine |
| 20:09 |
VanessaE |
(not enough to speak with any authority on the subject) |
| 20:10 |
celeron55 |
don't change them to any kind of decimal approximations, because those will be wrong even if they look like round numbers |
| 20:11 |
celeron55 |
and also, of course the difference won't be very apparent, but i believe the wrongness will accumulate and make people feel something is not right while they can't see why they feel so |
| 20:11 |
celeron55 |
...now i'm assuming the previous values made sense to begin with |
| 20:11 |
sapier |
http://imgur.com/Ed4wiSi,OuXex2u,KnGJ0hH you did see this? |
| 20:12 |
sapier |
First is original second rba's somehow changed values last is aproximated first numbers |
| 20:13 |
celeron55 |
hmm, no; the previous values don't make sense in any "realistic lighting" sense |
| 20:13 |
sapier |
so we've got values other values and no idea about correct values? :-) |
| 20:13 |
celeron55 |
and also i don't know any immediate way to make them so 8) |
| 20:14 |
sapier |
ok if we don't know the correct ones imho we should stay at the already used values |
| 20:15 |
celeron55 |
so, this has to be either left exactly as it was or a new gut feel has to be taken with each configurable lighting mode |
| 20:15 |
celeron55 |
just put the sqrt()s of the old values there 8) |
| 20:15 |
VanessaE |
sapier: "already used" values is fine but the problem is getting rid of those sqrt()'s. |
| 20:15 |
sapier |
exact with how many digits? :-) |
| 20:15 |
VanessaE |
round to 4 digits. |
| 20:15 |
VanessaE |
:) |
| 20:16 |
VanessaE |
er, 4 decimal places rather. |
| 20:16 |
celeron55 |
well given that we are dealing with 8 bit color here, i guess that works fine |
| 20:16 |
sapier |
ok I'll recalculate my 2 decimals values and add 4 instead |
| 20:16 |
celeron55 |
4 is definitely excessive but that means we are staying true to the original 8-) |
| 20:17 |
sapier |
I'll add a comments why there are those strange numbers ;-) |
| 20:17 |
celeron55 |
anyway i'm guessing better values could be found by careful testing |
| 20:18 |
VanessaE |
I was only kidding when I said 4 digits :P |
| 20:18 |
celeron55 |
basically the old values are the multiplication factors in linear color space, and any new values really get their actual meaning from that too (multiplication in sRGB color space doesn't mean anything useful) |
| 20:19 |
VanessaE |
with 8 bpp color, 3 digits would give you at worst about 1/4 bit rounding error |
| 20:19 |
celeron55 |
and the relation of those is the sqrt |
| 20:19 |
VanessaE |
(so maybe 4 digits IS about right) |
| 20:20 |
sapier |
I'm gonna do 6 digits ... if someone feels this is to much it can be removed later ... but I don't wanna calculate another time :-) |
| 20:20 |
VanessaE |
haha |
| 20:20 |
celeron55 |
also i don't know if the shaders actually mess these up further so that the values in fact mean absolutely nothing no matter what is done to them |
| 20:20 |
VanessaE |
celeron55: good question. |
| 20:20 |
celeron55 |
8D |
| 20:21 |
celeron55 |
also didn't RBA change those values already at some point? |
| 20:21 |
|
Anchakor_ joined #minetest-dev |
| 20:21 |
VanessaE |
er, s/8 bpp color/8 bits ber color channel/ (you know what I meant) |
| 20:21 |
celeron55 |
8bpc! |
| 20:21 |
VanessaE |
celeron55: yeah, to increase the overall contrast relative to the sides of nodes |
| 20:22 |
sapier |
they doo have an effect |
| 20:23 |
sapier |
and considering minetest already being to dark at night I don't like it to become even more dark ... but of course that's a subjective opinion only |
| 20:23 |
celeron55 |
i mean, depending on what the shaders do the effect could become such that if you set a factor of sqrt(0.5) there, the visual brightness wouldn't be halved like it should but instead just lowers by whatever amount the arbitrary calculations result in |
| 20:24 |
celeron55 |
given the amount people probably care about this, this discussion is already useless thoguh |
| 20:24 |
celeron55 |
though* |
| 20:24 |
* celeron55 |
removes himself -> |
| 20:24 |
VanessaE |
celeron55: well for comparison, the original patch that changed the brightnesses is here, https://github.com/minetest/minetest/commit/c9ba92c4ad0b010d6d36890c3b1ddfb2e773560f |
| 20:25 |
celeron55 |
oh there my actually useful function name was removed |
| 20:26 |
celeron55 |
the old values are arbitrary still though |
| 20:26 |
VanessaE |
they were decided kinda by committee |
| 20:27 |
sapier |
to be honest I don't understand the exact meaning of those values but changing them without any explanation doesn't seem to be right |
| 20:27 |
VanessaE |
calinou, RBA, myself, and at least a couple others, via screenshots RBA was passing around. |
| 20:29 |
celeron55 |
i don't think we can construct any kind of useful model for this kind of node shading |
| 20:30 |
celeron55 |
or, well, we could, but it would be just as arbitrary |
| 20:30 |
VanessaE |
lemme check the logs |
| 20:30 |
sapier |
so what's result? stay as close as possible at original values? |
| 20:30 |
celeron55 |
because we would have to define an arbitrary material properties for the faces, arbitrary light angle(s) and possibly other things too |
| 20:31 |
celeron55 |
stay as close as possible to the revised values by RBA that currently exist |
| 20:31 |
VanessaE |
http://irc.minetest.ru/minetest/2014-06-12#i_3757468 |
| 20:31 |
VanessaE |
there's the bulk of the discussion on the brightnesses. |
| 20:31 |
celeron55 |
they have at least some thought put to them even while probably not everyone agrees to them |
| 20:33 |
sapier |
https://gist.github.com/sapier/8a13cd2cbe2cc8e6da74 then I'm gonna use this values for merge |
| 20:33 |
VanessaE |
sapier: go for it. |
| 20:46 |
|
proller joined #minetest-dev |
| 20:50 |
|
pitriss joined #minetest-dev |
| 21:04 |
sapier |
is there any reason to keep default per block entity count at 49 after fixing the duplication issues? |
| 21:06 |
sapier |
what about 1024= 1/4 of nodecount or 512 = 1/8 of nodecount ? |
| 21:06 |
VanessaE |
not especially so - I run with a default of 500 without issues, as long as there isn't some mod glitching out and creating them like crazy |
| 21:06 |
VanessaE |
but bear in mind the usual issue of lower FPS from having lots of entities around |
| 21:07 |
VanessaE |
1024 seems a little excessive, 512 seems about right to me |
| 21:07 |
VanessaE |
it can always be adjusted by the server operator if that's still too low |
| 21:08 |
celeron55 |
i guess it's starting to be the time to raise the limit |
| 21:09 |
sapier |
is there any reason to use pot2 values or would vanessae's tested 500 value be good too? |
| 21:15 |
|
VargaD_ joined #minetest-dev |
| 21:24 |
|
sapier left #minetest-dev |
| 21:47 |
|
OldCoder joined #minetest-dev |
| 22:28 |
celeron55 |
sapier: i personally never use 2^n values unless specifically needed |
| 22:28 |
|
CraigyDavi` joined #minetest-dev |
| 22:32 |
|
CraigyDavi`` joined #minetest-dev |
| 22:50 |
|
CraigyDavi` joined #minetest-dev |
| 22:54 |
|
Megaf joined #minetest-dev |
| 22:54 |
|
khonkhortisan joined #minetest-dev |
| 22:54 |
|
Gethiox joined #minetest-dev |
| 22:54 |
|
ShadowNinja joined #minetest-dev |
| 22:54 |
|
psedlak joined #minetest-dev |
| 22:54 |
|
AnotherBrick joined #minetest-dev |
| 22:54 |
|
kahrl_ joined #minetest-dev |
| 22:54 |
|
vifino joined #minetest-dev |
| 22:54 |
|
Robby joined #minetest-dev |
| 22:55 |
|
sfan5 joined #minetest-dev |
| 22:58 |
|
hax404 joined #minetest-dev |
| 22:58 |
|
rmilan joined #minetest-dev |
| 22:58 |
|
Ritchie joined #minetest-dev |
| 22:58 |
|
celeron55 joined #minetest-dev |
| 22:58 |
|
netchip joined #minetest-dev |
| 22:58 |
|
eeew joined #minetest-dev |
| 22:59 |
|
cheapie joined #minetest-dev |
| 22:59 |
|
BrandonReese joined #minetest-dev |
| 22:59 |
|
HLuaBot joined #minetest-dev |
| 22:59 |
|
catninja_ joined #minetest-dev |
| 22:59 |
|
Anchakor1 joined #minetest-dev |
| 23:17 |
|
kaeza joined #minetest-dev |
| 23:24 |
|
CraigyDavi`` joined #minetest-dev |
| 23:28 |
|
CraigyDavi` joined #minetest-dev |
| 23:32 |
|
CraigyDavi joined #minetest-dev |
| 23:34 |
|
CraigyDavi`` joined #minetest-dev |
| 23:50 |
|
cheapie joined #minetest-dev |
| 23:58 |
|
cheapie joined #minetest-dev |
