| Time |
Nick |
Message |
| 00:26 |
|
luizrpgluiz joined #minetest-dev |
| 00:26 |
|
luizrpgluiz left #minetest-dev |
| 00:29 |
Taoki |
Hey. Anyone know why finite liquid was removed? I didn't really use it but still sorta sad news. |
| 00:29 |
Taoki |
I assume it was too buggy and no one cared to improve it? |
| 00:36 |
|
literaryraven joined #minetest-dev |
| 00:47 |
|
sfan5_ joined #minetest-dev |
| 00:58 |
Taoki |
Well, that seems to be a question no one has an answer to :P |
| 01:15 |
|
us`0gb joined #minetest-dev |
| 02:13 |
ShadowNinja |
Gah, I'm trying to fix builtin's organization but I keep changing things that will comflict with my async pull. Can someone look at it? celeron55, hmmmm, kahrl? #1226 |
| 02:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/1226 -- Remove dependency on marshal and push the Lua error handler only once by ShadowNinja |
| 02:14 |
ShadowNinja |
Simply moving files should be handled pretty well by git, but I have to do more than that to tryto unifiy builtin. |
| 02:15 |
ShadowNinja |
Eg minetest.get_modpath("__builtin") / engine.get_scriptpath() / SCRIPTPATH. |
| 02:29 |
|
dzho joined #minetest-dev |
| 02:46 |
|
Ritchie joined #minetest-dev |
| 02:47 |
|
CraigyDavi joined #minetest-dev |
| 03:55 |
|
CraigyDavi joined #minetest-dev |
| 05:14 |
|
CraigyDavi joined #minetest-dev |
| 05:15 |
|
OldCoder joined #minetest-dev |
| 06:12 |
celeron55 |
Taoki: i don't know, but i think it's for the best; it wasn't going to be fixed in an adequate way so better take it out, and the design of it didn't really fit with minetest's direction in any case |
| 06:13 |
celeron55 |
if you want the finite liquid + weather integration, freeminer does provide continued development on that |
| 06:17 |
VanessaE |
Taoki: and if all you really need is temperature/humidity controls, plants_lib can do that much already. |
| 06:17 |
VanessaE |
(add the snowdrift mod and you more or less have the same damn thing) |
| 06:18 |
VanessaE |
(I'm assuming mgv7 is not being used) |
| 06:40 |
|
VargaD_ joined #minetest-dev |
| 07:31 |
|
diemartin joined #minetest-dev |
| 07:43 |
|
darkrose joined #minetest-dev |
| 08:26 |
|
BlockMen joined #minetest-dev |
| 08:26 |
BlockMen |
i gonna push this fix in a few minutes https://github.com/BlockMen/minetest/commit/31af5dc55ad5fefc33c75e94b39323b36274e527 |
| 08:39 |
BlockMen |
umm, no, this. s8 is enough https://github.com/BlockMen/minetest/commit/c5324015bc70488c8b6d68d83ca7d963a5e6c62f |
| 09:22 |
|
Hiradur joined #minetest-dev |
| 09:30 |
|
PilzAdam joined #minetest-dev |
| 10:13 |
|
Hiradur joined #minetest-dev |
| 10:30 |
|
smoke_fumus joined #minetest-dev |
| 10:33 |
celeron55 |
here's some AI stuff that might interest somene: http://www.altdevblogaday.com/2011/02/24/introduction-to-behavior-trees/ http://web.media.mit.edu/~jorkin/gdc2006_orkin_jeff_fear.pdf |
| 10:33 |
celeron55 |
someone* |
| 10:39 |
|
proller joined #minetest-dev |
| 10:41 |
Anchakor |
"My name is Björn Knafla. I am parallelizing computer and video games with a strong focus on artificial intelligence (AI)." |
| 10:41 |
Anchakor |
sure does not sound like the computers I know |
| 10:44 |
|
rdococ joined #minetest-dev |
| 10:49 |
celeron55 |
your english parser is broken 8) |
| 10:53 |
Taoki |
celeron55: Well, I can't say I miss finite liquid much. But I really suggest bringing weather back! I don't see any reason why water sources can't be turned to ice blocks when temperature is smaller than 0*, and back to water source again once it's over 0* |
| 10:54 |
Taoki |
Of course, we can't have rain generating water on the surface any more. But freezing / unfreezing should really still work |
| 10:55 |
Taoki |
Well, even if minetest_game won't re-add that, I'm going to add it in my own games, so it's still fine in a sense |
| 10:56 |
proller |
placing one ice you will flood all around |
| 10:57 |
Taoki |
proller: But you could do the same by placing a water source there |
| 10:57 |
Taoki |
If you mean that someone could use this to troll |
| 10:57 |
celeron55 |
Taoki: ask minetest_next about that, or whatever your preferred still-developed game is |
| 10:57 |
Taoki |
I mean, someone could take 10 water buckets and place them all over if they're not responsible. Same with ice |
| 10:58 |
Taoki |
ok |
| 10:58 |
celeron55 |
(and note VanessaE's comments) |
| 11:39 |
|
Shardvexz joined #minetest-dev |
| 12:15 |
|
proller joined #minetest-dev |
| 12:17 |
|
werwerwer joined #minetest-dev |
| 12:26 |
|
Megaf left #minetest-dev |
| 12:49 |
|
ImQ009 joined #minetest-dev |
| 12:57 |
|
pi1 joined #minetest-dev |
| 13:00 |
Megaf |
Hi everyone any word on #1243 ? |
| 13:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/1243 -- /clearobjects spams errrors |
| 13:03 |
PilzAdam |
Megaf, seems to be fixed by https://github.com/minetest/minetest/commit/41bc24477b732b74bd18839a9742d32bd85d1b44 |
| 13:03 |
PilzAdam |
can you confirm? |
| 13:04 |
Megaf |
PilzAdam: if you give me a couple of hours I will confirm |
| 13:09 |
Megaf |
It's 10:10 AM here, I will get home at 12:00 |
| 13:12 |
|
grrk-bzzt joined #minetest-dev |
| 13:24 |
|
troller joined #minetest-dev |
| 13:26 |
|
Zeitgeist_ joined #minetest-dev |
| 13:26 |
|
Zeitgeist_ joined #minetest-dev |
| 13:32 |
PilzAdam |
~tell sapier why does pressing Esc while connecting to a server print an error message? |
| 13:32 |
ShadowBot |
PilzAdam: O.K. |
| 13:34 |
|
troller joined #minetest-dev |
| 13:34 |
|
Garmine joined #minetest-dev |
| 13:44 |
|
hmmmm joined #minetest-dev |
| 13:59 |
|
PenguinDad joined #minetest-dev |
| 14:08 |
|
RealBadAngel joined #minetest-dev |
| 14:10 |
RealBadAngel |
hi folks |
| 14:13 |
RealBadAngel |
PilzAdam, i have finally figured out problems with mergeing pulls, i can do that all in GUI, all i had to do was adding remote branches |
| 14:14 |
|
NakedFury joined #minetest-dev |
| 14:14 |
RealBadAngel |
now i kinda like it ;) |
| 14:17 |
Megaf |
Hi RealBadAngel |
| 14:18 |
Megaf |
I'm looking forward to see water reflections |
| 14:18 |
Megaf |
that is the only shader I really care for |
| 14:19 |
Megaf |
real time shadows would be cool too, but I think that's quite impossible at the moment |
| 14:19 |
Megaf |
real time water reflections and real time shadows would brin minetest to a whole new level |
| 14:19 |
Megaf |
bring* |
| 14:20 |
RealBadAngel |
it is definitely possible, i do have irrlicht code for that, have just to copy that into our code |
| 14:20 |
Megaf |
RealBadAngel: Would I be asking too much if you did a minetest branch or fork with that? |
| 14:21 |
Megaf |
so we don't mess with minetest itself |
| 14:21 |
Megaf |
I would happily test that |
| 14:21 |
RealBadAngel |
check out my shaders branch, i am pushing there all the code |
| 14:21 |
Megaf |
ok |
| 14:22 |
Megaf |
my girlfriend almost broke with me yesterday because I'm giving more attention to minetest than I'm giving to her... |
| 14:22 |
RealBadAngel |
atm theres pushed change that unites nodes shaders, picking shaders per tile, not the node, and introduced water surface shader |
| 14:23 |
Megaf |
That's about my gf is a joke... |
| 14:23 |
ShadowNinja |
Comments?: http://ix.io/bTD/diff |
| 14:23 |
|
troller joined #minetest-dev |
| 14:24 |
Megaf |
ShadowNinja: I'm not really sure about that notification "A sapling grows into a tree" |
| 14:24 |
Megaf |
Is that something really important that an admin shoud be awere of? |
| 14:24 |
Megaf |
aware* |
| 14:25 |
RealBadAngel |
ShadowNinja, why not using l-systems birches? |
| 14:25 |
ShadowNinja |
Megaf: Yes, it told me what was happening when my server started eating CPU. |
| 14:25 |
RealBadAngel |
theyre way nicer |
| 14:26 |
Megaf |
do saplings eat CPU now? |
| 14:28 |
ShadowNinja |
RealBadAngel: Thet could probably be done. Can you give me a treedef that is almost exactly identical? (They were a bit bigger last I checked) I'll also need a jungletree one. |
| 14:30 |
|
proller joined #minetest-dev |
| 14:34 |
RealBadAngel |
ShadowNinja, sure, hold on |
| 14:36 |
RealBadAngel |
https://github.com/VanessaE/moretrees/blob/master/tree_models.lua#L1 |
| 14:36 |
RealBadAngel |
and i meant beeches not birches ;) |
| 14:36 |
RealBadAngel |
and thats for jungle trees |
| 14:36 |
RealBadAngel |
https://github.com/VanessaE/moretrees/blob/master/tree_models.lua#L185 |
| 14:37 |
RealBadAngel |
and yes, beeches are 2-3 nodes higher than default sticks with leaves |
| 14:40 |
|
CraigyDavi joined #minetest-dev |
| 14:43 |
ShadowNinja |
RealBadAngel: axiom=nil |
| 14:43 |
ShadowNinja |
For the jungletree. |
| 14:44 |
RealBadAngel |
ouch, thats because there are several possible types |
| 14:45 |
RealBadAngel |
https://github.com/VanessaE/moretrees/blob/master/init.lua#L199 |
| 14:45 |
RealBadAngel |
theyre here |
| 14:49 |
ShadowNinja |
RealBadAngel: Which one is most similar to the default one? |
| 14:50 |
RealBadAngel |
default one has extra nodes at bottom, none of l-systems one have them |
| 14:51 |
RealBadAngel |
i can make a model that will copy default one |
| 14:52 |
|
CraigyDavi joined #minetest-dev |
| 14:53 |
RealBadAngel |
on the other hand, thats whats done in moretrees is good, it brings variety to jungle trees, they can grow different sizes |
| 14:53 |
RealBadAngel |
from single nodes trunks, small to double and very high |
| 14:56 |
RealBadAngel |
going out shopping, brb |
| 15:05 |
|
Jordach joined #minetest-dev |
| 15:45 |
|
tomreyn joined #minetest-dev |
| 15:46 |
|
twoelk joined #minetest-dev |
| 15:50 |
|
CraigyDavi joined #minetest-dev |
| 15:52 |
twoelk |
I think the "default" trees should be harvestable without any help. So no building stairs or such but everything reachable from the ground, afterall they are normally the first tree a newbie encounters |
| 15:55 |
|
Calinou joined #minetest-dev |
| 15:59 |
|
Zeitgeist_ joined #minetest-dev |
| 15:59 |
|
Zeitgeist_ joined #minetest-dev |
| 16:08 |
|
Eater4 joined #minetest-dev |
| 16:17 |
|
PilzAdam joined #minetest-dev |
| 16:30 |
|
jin_xi joined #minetest-dev |
| 16:31 |
RealBadAngel |
twoelk, lsystem beech is "reachable" but way nicer |
| 16:31 |
RealBadAngel |
it is meant as replacement for default ones from the very start |
| 16:35 |
twoelk |
I am pretty much a fan of more_trees, actually that was the mod that made me join a public server for the first time. Was just reading the 2-3 nodes higher part and remembering my first steps in singleplayer long befor I played online and could ask for help |
| 16:35 |
Megaf |
PilzAdam: I will try that commit in a couple of minutes, backing up my server now |
| 16:36 |
|
pi1 joined #minetest-dev |
| 16:37 |
|
Megaf joined #minetest-dev |
| 16:37 |
|
rubenwardy joined #minetest-dev |
| 16:39 |
twoelk |
Having played on VE-Minetest for a while I keep repairing the jungle trees that are allready too difficult to harvest for the new/casuall/veryyoung player, leaving lots of floating trees around |
| 16:39 |
RealBadAngel |
who said cuttin the jungle is easy? |
| 16:42 |
|
proller joined #minetest-dev |
| 16:54 |
Megaf |
PilzAdam: spamming is gone indeed |
| 16:54 |
|
proller joined #minetest-dev |
| 16:54 |
twoelk |
the first game should be easy or the newbie will be lost in some dark corner under a jungle tree sobbing, never to be seen again |
| 16:56 |
Megaf |
I wish a tree would fall down when we cut it's trunk |
| 16:57 |
twoelk |
there are several mods that do that iirc |
| 16:59 |
Megaf |
I want to open a new issue but I'm not sure if it's an issue or a "feature" |
| 16:59 |
Megaf |
when |
| 17:00 |
Megaf |
when you ran /clearobjects server do stop responding to any request. I couple of folks attemped to connect to my server now while It's doing the clearing and they could not complete the request |
| 17:00 |
Megaf |
13:57:42: ERROR[ConnectionSend]: con(4/1)RunTimeouts(): Peer 5 has timed out. (source=peer->timeout_counter) |
| 17:00 |
Megaf |
13:58:53: ERROR[ConnectionSend]: con(4/1)RunTimeouts(): Peer 6 has timed out. (source=peer->timeout_counter) |
| 17:01 |
Megaf |
I don't understand this behaving |
| 17:02 |
|
troller joined #minetest-dev |
| 17:03 |
Megaf |
http://paste.debian.net/95720/ |
| 17:03 |
Megaf |
troller: does clearobjectes freezes freeminet too? |
| 17:03 |
troller |
yes |
| 17:04 |
troller |
its stupid feature |
| 17:05 |
troller |
useless |
| 17:05 |
Megaf |
The way it works is not right |
| 17:05 |
troller |
why you use it? |
| 17:05 |
celeron55 |
https://github.com/minetest/minetest/pull/490 |
| 17:05 |
Megaf |
troller: becuase a lot of objects floating around wil decrease performance |
| 17:06 |
celeron55 |
does this conflict with something in the works at the moment? if not, is there a reason to never merge it if it is rebased? |
| 17:06 |
troller |
Megaf, in freeminer it not decreases performance, and no need to run it |
| 17:07 |
troller |
and it works only with 4096 blocks - no sense on big server |
| 17:07 |
Megaf |
celeron55: That's a little scary actually |
| 17:07 |
celeron55 |
Megaf: it's unarguably useful for certain interesting things |
| 17:08 |
celeron55 |
i think it needs a server-wide configurable whitelist and in singleplayer games it should interactively ask for permission |
| 17:08 |
celeron55 |
after that, the security issues are small enough |
| 17:08 |
Megaf |
What about some official thing from minetest.net? I mean, a whitelist on minetest.net, like, whitelist.minetest.net where the mods could get data from |
| 17:09 |
Megaf |
it could be something integrated with mods githubs |
| 17:09 |
celeron55 |
the mods are likely to want to eg. post schematics and other creations to somewhere, and download similar things |
| 17:10 |
celeron55 |
and there could be uses for eg. synchronizing something between server instances (whatever an admin can come up with) |
| 17:10 |
Megaf |
I'm not sure, that could generate much overhead, in network and cpu |
| 17:11 |
Megaf |
Don't get me wrong, that's really useful and quite fantastic, but so can be the drawbacks |
| 17:12 |
celeron55 |
useful and fantastic drawbacks 8) |
| 17:14 |
|
troller joined #minetest-dev |
| 17:16 |
|
rsiska joined #minetest-dev |
| 17:24 |
|
CraigyDavi joined #minetest-dev |
| 17:25 |
|
troller joined #minetest-dev |
| 17:31 |
Calinou |
https://forum.minetest.net/viewtopic.php?f=15&t=9116 → the term “Vote†is not that good |
| 17:31 |
Calinou |
it's a consensus |
| 17:32 |
BlockMen |
im moving the rest of /old to "/doc/old" now |
| 17:41 |
Megaf |
Calinou: that voting should take longer, my game is not ready yet |
| 17:41 |
Megaf |
I'm making a game for Raspberry Pis and really low end computers |
| 17:42 |
Calinou |
"Minetest 8086" |
| 17:43 |
Megaf |
heh |
| 17:43 |
Megaf |
That could be a good name |
| 17:43 |
RealBadAngel |
celeron55, https://www.youtube.com/watch?v=hubBBzh_190 |
| 17:43 |
Megaf |
It's called rpi at the moment |
| 17:43 |
|
iqualfragile joined #minetest-dev |
| 17:43 |
RealBadAngel |
^^^ up to date shaders |
| 17:45 |
RealBadAngel |
Megaf, offtopic, can RPI run android? |
| 17:45 |
Calinou |
I don't think so |
| 17:45 |
Calinou |
it would need suitable drivers |
| 17:45 |
sfan5 |
it can |
| 17:45 |
Megaf |
RealBadAngel: Yes it can |
| 17:46 |
Megaf |
there are somebuilds for it |
| 17:46 |
RealBadAngel |
cool |
| 17:46 |
Megaf |
but they are really slow due the GPU blob |
| 17:46 |
RealBadAngel |
i was thinkin about some business |
| 17:46 |
sfan5 |
that has nothing to do with gpu being in a blob |
| 17:47 |
RealBadAngel |
putting rpi into keyboard case, giving it an os and selling it |
| 17:47 |
BlockMen |
fuck, why is the doc folder not removed? |
| 17:47 |
Megaf |
RealBadAngel: http://androidpi.wikia.com/wiki/Android_Pi_Wiki |
| 17:47 |
BlockMen |
oh, it is |
| 17:47 |
BlockMen |
lol |
| 17:47 |
BlockMen |
*and i ment the old folder^^ |
| 17:47 |
Megaf |
RealBadAngel: what for? It's really slow as desktop when running Linux |
| 17:48 |
Megaf |
It's pretty fast using ReactOS |
| 17:49 |
celeron55 |
22 |
| 17:49 |
celeron55 |
oops |
| 17:50 |
Megaf |
RealBadAngel: http://www.raspberrypi.org/android-4-0-is-coming/ http://androidpi.wikia.com/wiki/Android_Pi_Wiki |
| 17:50 |
Megaf |
That's it |
| 18:02 |
Megaf |
the /clearobjects still running... |
| 18:03 |
Calinou |
your PC works with ReactOS? :o |
| 18:03 |
Megaf |
Calinou: oops |
| 18:03 |
Megaf |
wait a minute, |
| 18:04 |
Megaf |
s/It's pretty fast using ReactOS/Raspberry Pi as desktop is pretty fast using RiscOS |
| 18:11 |
Megaf |
Calinou: and yes, a computer can work with ReactOS |
| 18:11 |
Megaf |
but earlier on I meant RiscOS on Raspberry Pi |
| 18:48 |
|
BrandonReese joined #minetest-dev |
| 18:52 |
|
Megaf joined #minetest-dev |
| 19:01 |
|
BrandonReese joined #minetest-dev |
| 19:12 |
RealBadAngel |
celeron55, have you saw the video? |
| 19:19 |
celeron55 |
RealBadAngel: the water should get an orange in place of the white when the sun is setting |
| 19:20 |
celeron55 |
or in place of blue |
| 19:20 |
VanessaE |
follow the tint of the tone map |
| 19:20 |
VanessaE |
maps* |
| 19:24 |
celeron55 |
(in reality practically all of water's color comes from the sky and clouds and sun and whatever else that it reflects) |
| 19:24 |
celeron55 |
in minetest it tends to be painted blue no matter what's above it 8) |
| 19:25 |
RealBadAngel |
this is temporary |
| 19:25 |
RealBadAngel |
water will have reflections |
| 19:26 |
RealBadAngel |
now reflection texture is just set to all blue |
| 19:27 |
VanessaE |
did you fix that glitch with animated water textures throwing off the speed of the water rippling shader? |
| 19:28 |
RealBadAngel |
huh? |
| 19:28 |
Anchakor |
I wonder how crappy will flowing water look compared to this :) |
| 19:29 |
RealBadAngel |
crappy ;) |
| 19:29 |
VanessaE |
remember, the thing where the water rippling shader would go apeshit under minetest_game (except when paused) but not under minimal because _game has animated textures? |
| 19:29 |
|
Shardvexz joined #minetest-dev |
| 19:29 |
RealBadAngel |
but i started to read about Bezier curves to implement real flowing liquids |
| 19:31 |
RealBadAngel |
VanessaE, with the changes i made this has no effect on shaders |
| 19:31 |
VanessaE |
ok good. |
| 19:31 |
VanessaE |
also, did you fix the issue with the *bottom* surface of the water being moved around via the "waving" shader? |
| 19:31 |
|
kaeza joined #minetest-dev |
| 19:31 |
RealBadAngel |
when water surface is detected the tile for it uses own shader with disabled animations |
| 19:32 |
VanessaE |
(I mean the -Y side of the block) |
| 19:32 |
RealBadAngel |
and pause doesnt stop shaders animations timers |
| 19:33 |
RealBadAngel |
hold ur horses |
| 19:33 |
RealBadAngel |
shaders now work per tile, not the node |
| 19:33 |
VanessaE |
ok |
| 19:34 |
RealBadAngel |
water surface shader is supposed to work only on [0] tile |
| 19:34 |
VanessaE |
ok ok, do this: |
| 19:34 |
VanessaE |
build a 3x3x3 cube of glass. hollow the center out and fill it with water. |
| 19:34 |
VanessaE |
turn on the waving water shader and observe the bottom/-Y surface of the water |
| 19:35 |
RealBadAngel |
you mean that water node that have another one over it shouldnt be affected by waving? |
| 19:36 |
VanessaE |
no. I mean that the bottom-most -Y surface of the water node, under the current version of the shader, will also move up/down to match the top +Y surface |
| 19:37 |
VanessaE |
what should happen is that the bottom shouldn't move at all if there's no more water below it. |
| 19:38 |
celeron55 |
there should also be some kind of logic for not making water underground be in the sky's colors but instead something more like stone and dirt |
| 19:38 |
RealBadAngel |
without it we wont get "waves at beachside" effect |
| 19:38 |
celeron55 |
and not wave around |
| 19:38 |
VanessaE |
celeron55: +1 |
| 19:39 |
RealBadAngel |
theres such logic already |
| 19:39 |
RealBadAngel |
sunligt_seen or so |
| 19:39 |
VanessaE |
I thought the same |
| 19:39 |
celeron55 |
does it work? that's good |
| 19:39 |
VanessaE |
RealBadAngel: wait nonono, you're talking about the +Y side of the node |
| 19:39 |
VanessaE |
that's fine |
| 19:40 |
VanessaE |
I'm talking about the -Y side, or really the -Y edges of the X/Z sides since there is no -Y face on a water source anyway |
| 19:40 |
VanessaE |
those edges should *not* move if there's no more water below them |
| 19:40 |
VanessaE |
but the top surfaces and edges should move. |
| 19:40 |
RealBadAngel |
btw, lava: https://www.youtube.com/watch?v=zxUXNNFpPpc |
| 19:42 |
|
BlockMen joined #minetest-dev |
| 19:42 |
Anchakor |
like there is no sense in having waves and tiny pocket of air at the bottom of glass of water |
| 19:43 |
VanessaE |
Anchakor: exactly. |
| 19:43 |
Anchakor |
(when it is full) |
| 19:46 |
PenguinDad |
RealBadAngel: just noticed that waving water is broken on your shaders branch http://ix.io/bVL |
| 19:48 |
RealBadAngel |
PenguinDad, i know, i have this fixed on local already |
| 19:48 |
VanessaE |
RealBadAngel: I mean this issue: http://digitalaudioconcepts.com/vanessa/extra/Screenshot%20-%2004252014%20-%2003%3a47%3a27%20PM.png |
| 19:49 |
VanessaE |
the red wavy lines should imply the motion of the water, the }--- implies how much overlap there should not be with the space the water sits in :P |
| 19:49 |
RealBadAngel |
that was an issue with #define variables not being able to use with #if |
| 19:50 |
RealBadAngel |
VanessaE, splitting face shaders should do the trick i think |
| 19:50 |
VanessaE |
ok |
| 19:50 |
RealBadAngel |
so bottom cannot wave |
| 19:50 |
VanessaE |
but it's a solvable issue without taking a performance hit? |
| 19:50 |
RealBadAngel |
am i correct? |
| 19:51 |
VanessaE |
yes, bottom should never wave |
| 19:51 |
VanessaE |
and if possible, bottom should be exactly aligned to the bottom of the node where it belongs. |
| 19:51 |
RealBadAngel |
actually sorting out shaders before game starts speeds things up |
| 19:51 |
VanessaE |
because honestly, this looks weird :P |
| 19:52 |
RealBadAngel |
and thats the main change in the forthcoming shaders update |
| 19:52 |
RealBadAngel |
shaders are being compiled on textures build |
| 19:52 |
RealBadAngel |
ONCE |
| 19:53 |
RealBadAngel |
not per every mesh update, which was just sick |
| 19:53 |
RealBadAngel |
also i have trashed the code that allowed for asynced shaders requests |
| 19:54 |
RealBadAngel |
so, no more timed out errors |
| 19:55 |
RealBadAngel |
sorry karhl, but gfx is not as easy as two threads calculating something |
| 19:56 |
RealBadAngel |
current situation can be compared to the situation when you went outside and waiting for a miracle to get dressed |
| 19:56 |
RealBadAngel |
before someone noticed youre naked |
| 20:00 |
RealBadAngel |
atm compiling of all nodes shaders takes circa 1.5s, thats 5(materials)x16(drawtypes) |
| 20:00 |
RealBadAngel |
so many instances |
| 20:01 |
RealBadAngel |
shaders are not using drawtypes by now but ive allowed them to do so |
| 20:02 |
RealBadAngel |
so torches, rails or fences can have own shaders |
| 20:02 |
RealBadAngel |
within one source shader ofc |
| 20:05 |
RealBadAngel |
celeron55, you havent commented the vid... and im really curious what do you think about it |
| 20:07 |
celeron55 |
i did comment |
| 20:08 |
RealBadAngel |
oh, indeed |
| 20:09 |
RealBadAngel |
but youre next that expected water reflections |
| 20:10 |
RealBadAngel |
shit i cant code everything at once ;) |
| 20:13 |
|
us`0gb joined #minetest-dev |
| 20:13 |
|
hmmmm joined #minetest-dev |
| 20:20 |
|
Guest38529 joined #minetest-dev |
| 20:23 |
Guest38529 |
RealBadAngel: You are doing well, you can code all at twice |
| 20:23 |
|
Shardvexz joined #minetest-dev |
| 20:30 |
RealBadAngel |
yeah sure. but seriously changes ive made lately let shaders work on the nodes. |
| 20:30 |
RealBadAngel |
and the other shaders work on smthg else |
| 20:31 |
RealBadAngel |
so, in the near future all kind of postprocess shaders will become possible |
| 20:35 |
Megaf |
RealBadAngel: I'm looking forward for water reflections and real time shadows |
| 20:37 |
Megaf |
RealBadAngel: If we do realtime shadows, would those shadows be shadows from anything that emits light or only sun shadows? |
| 20:37 |
RealBadAngel |
oh, another qest given... |
| 20:38 |
RealBadAngel |
Quest |
| 20:38 |
RealBadAngel |
but seriously. i was thinkin about implementing ray marching here |
| 20:39 |
RealBadAngel |
but atm im not quite sure what will be the best in sense of performance |
| 20:39 |
Megaf |
RealBadAngel: I'm talking so much about water reflections and real time shadows because they will make the game looks much cooler and real and beautiful and less artificial, and you dont like that, you could just disable it |
| 20:40 |
Megaf |
RealBadAngel: ray marching could be interesting too |
| 20:40 |
RealBadAngel |
taoki suggested using current lights as shadows map |
| 20:41 |
RealBadAngel |
which makes a lot of sense, since server have to calculate light level anyway |
| 20:41 |
Taoki |
RealBadAngel: My suggestion is using the current lighting (param2 geometry coloration map) as a black and white image, as a pass in deferred lighting. You can then extract dynamic lights from it |
| 20:41 |
Taoki |
As in, use it as a mask for lights |
| 20:42 |
RealBadAngel |
so deffered light map |
| 20:42 |
Taoki |
But yeah. Using it is needed both because visible light must match the value of param2 (eg: fetching light value at node position in Lua), and so sunlight doesn't shine in caves |
| 20:42 |
Taoki |
Yeah |
| 20:42 |
Taoki |
I think deferred lighting is best choice |
| 20:43 |
Taoki |
Oh... and I think two deferred maps like this need to be made. One for sun / moon light, and another for local lights (possibly one per local light, not sure how much FPS that would cost though). Depends on what's needed however |
| 20:44 |
RealBadAngel |
we will see |
| 20:44 |
Megaf |
WHat about player shadows? |
| 20:45 |
RealBadAngel |
thats pretty trivial |
| 20:45 |
RealBadAngel |
it is post process effect |
| 20:45 |
RealBadAngel |
once sun is here it can be made |
| 20:46 |
RealBadAngel |
notice that in my branch sun is already there as light source |
| 20:46 |
RealBadAngel |
always 900 nodes higher |
| 20:46 |
RealBadAngel |
thats used for bumpmapping |
| 20:47 |
VanessaE |
Ok, Dreambuilder Game is updated. |
| 20:47 |
VanessaE |
so now if there's any inclination to add it (my) game to the official builds, well at least it finally has a name now :) |
| 20:47 |
VanessaE |
I just need to make a title card for it. |
| 20:50 |
Taoki |
RealBadAngel: Any idea when there will be any code for basic dynamic lighting? Don't wish to rush, just eager... it will probably be the most awesome thing in Minetest since Minetest was created :) |
| 20:51 |
RealBadAngel |
well, engine allows that already |
| 20:51 |
RealBadAngel |
it is our code that misses that feature |
| 20:51 |
Taoki |
Irrlicht uses dynamic lighting, yes. It's actually the Minetest code that currently uses an ugly hack for lighting (vertex colors) |
| 20:52 |
RealBadAngel |
actually, our code can be disabled easily |
| 20:53 |
RealBadAngel |
oneliner in mapblock_mesh |
| 20:53 |
RealBadAngel |
and adding sun |
| 20:53 |
RealBadAngel |
i mean set all the material's lighting to true |
| 20:54 |
RealBadAngel |
and put there omnidirectional lightsource |
| 20:55 |
RealBadAngel |
ive used fixed one for testing purposes |
| 20:55 |
Taoki |
Not that easy sadly. First we need to disable vertex colors set by param2... this part is easy itself. Then we need to add an Irrlicht light source for both sun / moon and any light node like torch... also not the hardest thing. However, we need to bake the geometry with param2 for each light, and send it to the shader core to extract the dynamic light from it. Which must then be added on top of.. |
| 20:55 |
Taoki |
.. the textured geometry |
| 20:55 |
VanessaE |
ok, title card created and uploaded. |
| 20:55 |
VanessaE |
I think that should do it for my game. |
| 20:56 |
RealBadAngel |
Taoki, sun is easy |
| 20:56 |
RealBadAngel |
local lighsources are pain in the ass |
| 20:56 |
Taoki |
Yeah |
| 20:56 |
Taoki |
Well, |
| 20:57 |
RealBadAngel |
but hell, for that we do already have the logic |
| 20:57 |
Taoki |
We can make it so only sun / moon light are masked by the param2 map. But then light sources will shine through walls, and might not always match the value returned by getLight() in Lua (or what that function is) |
| 20:58 |
Taoki |
After all, sun and moon are lights with infinite radius... local lights would have finite distance |
| 20:58 |
RealBadAngel |
yeah |
| 20:58 |
Taoki |
Still, that means local lights will shine through walls. I don't think that's very acceptable |
| 20:58 |
RealBadAngel |
and for finite and local ones current logic will do |
| 20:59 |
Taoki |
So best way is to generate the param2 geometry map image for each local light, and use that to mask it... the light itself having an infinite distance past that. |
| 20:59 |
Taoki |
But what if there are 20 local light in view? How much can the video card handle mixing black & white images per frame without very low FPs |
| 20:59 |
RealBadAngel |
that would cost us too much |
| 20:59 |
Taoki |
yeah |
| 21:00 |
RealBadAngel |
2-3 lights sources are enough |
| 21:00 |
Taoki |
Best way might be two param2 passes. One for sun / moon light, other for local lights if any are present. Local lights might still shine in each other's raduis, but it's a much cheaper way |
| 21:00 |
Taoki |
If there will be a finite number of lights, it should certainly be a setting IMO |
| 21:01 |
Taoki |
Peple can set it based on video card performance |
| 21:01 |
RealBadAngel |
hold on |
| 21:01 |
Taoki |
yes |
| 21:01 |
RealBadAngel |
my idea is a bit different |
| 21:01 |
* Taoki |
listens |
| 21:01 |
RealBadAngel |
use real, hardware light from irrlicht |
| 21:01 |
RealBadAngel |
sun/moon |
| 21:01 |
RealBadAngel |
as basis |
| 21:02 |
RealBadAngel |
then add ours, but not as real light sources |
| 21:02 |
RealBadAngel |
but usual way, as gl_color |
| 21:02 |
Taoki |
What do you mean ours though? |
| 21:02 |
RealBadAngel |
current lighting system |
| 21:03 |
Taoki |
Irrlicht light sources are the way to do dynamic lighting. Though it might be possible to do it in shaders entirely... still would tend toward Irrlicht's system |
| 21:03 |
RealBadAngel |
which could be brought down just to lightlevel |
| 21:03 |
Taoki |
Oh, yes. I think you mean the same thing as me |
| 21:03 |
RealBadAngel |
i mean no soft lighting or whatever its called |
| 21:04 |
RealBadAngel |
just the light level at pos |
| 21:04 |
Taoki |
Soft lighting should still work |
| 21:04 |
Taoki |
ah |
| 21:04 |
Taoki |
Hmmm... |
| 21:04 |
|
proller joined #minetest-dev |
| 21:04 |
Taoki |
param2 value at position would be cheaper and better than per-vertex brightness, yes |
| 21:04 |
RealBadAngel |
hi proller |
| 21:05 |
proller |
hi |
| 21:05 |
RealBadAngel |
i can use that value as light |
| 21:05 |
Taoki |
Still, I'm not sure what the shader code will do with it. |
| 21:05 |
Taoki |
We need to render a black & white version of the geometry based on the value of param2 at each position. Different render-pass... then post-process that as a modifier to light |
| 21:05 |
Taoki |
There would be at least 3 render passes overall |
| 21:06 |
RealBadAngel |
proller, have you rebased my sun/moon patch? |
| 21:06 |
Taoki |
Or maybe 2 |
| 21:06 |
RealBadAngel |
its pretty different from what you have merged before |
| 21:06 |
RealBadAngel |
Taoki, no |
| 21:07 |
RealBadAngel |
light calculations on the server side ~= render passes |
| 21:07 |
|
EvergreenTree joined #minetest-dev |
| 21:07 |
RealBadAngel |
!= |
| 21:08 |
proller |
RealBadAngel, merged current master in freeminer |
| 21:08 |
Taoki |
RealBadAngel: http://1.bp.blogspot.com/-G6xtoRnB2x8/Uf8u4V7HusI/AAAAAAAAAX0/x-QFBdEAYq0/s1600/Display+sheet.jpg Pass 1 would be untextured geometry, similar to "Ambient Color" in that image. Pass 2 would be untextured geometry with param2 map, similar to "Depth". Pass 3 would be lighting only, similar to "Ambient Occlusion" |
| 21:09 |
Taoki |
Then in the shaders code, Pass 1 is rendered, with Pass 3 using ADD blending on top of it, but with Pass 2 SUBTRACTED from it. Or something like that I think |
| 21:09 |
Taoki |
I think add and subtract are the right names for image blending too |
| 21:10 |
Taoki |
At least what I was thinking... my ideas might not always be the best |
| 21:10 |
Taoki |
erm... *Pass 1 would be TEXTURED geometry :P |
| 21:12 |
Taoki |
RealBadAngel: Actually, I don't really get how this would work out. Would the render passes have to be *created* server-side, or shader-side? I mean, the server knows the light value at each node posibion... but could the shader code use such information to generate the lighting map? |
| 21:15 |
RealBadAngel |
in fact i do not care |
| 21:15 |
RealBadAngel |
engine provides me color per vertex |
| 21:15 |
RealBadAngel |
which contains both celestial lights and artificial |
| 21:16 |
Taoki |
Hmm... that is good |
| 21:16 |
Taoki |
Still, how can you tell local lights from one another, and how much each contributes to the light value at a given location? |
| 21:16 |
RealBadAngel |
my idea is just to disable celestial there and let irrlicht handle them |
| 21:16 |
RealBadAngel |
^^ as above |
| 21:17 |
RealBadAngel |
make engine ones local |
| 21:17 |
RealBadAngel |
or treat them as local |
| 21:17 |
Taoki |
Still can't understand... sorry if I'm stupid >_< |
| 21:17 |
Taoki |
Both sun and moon as well as local lights should use hardware lighting, so both would have to work the same way |
| 21:17 |
Taoki |
Only that sun / moon light have infinite radius |
| 21:18 |
RealBadAngel |
sun/moon will use hardware lighting |
| 21:18 |
RealBadAngel |
to lit the scene |
| 21:19 |
Taoki |
What about light caused by torches? |
| 21:19 |
RealBadAngel |
mt engine will calculate just local lightsources as glowing stuff, torches etc and pass them as vertex colors to the shaders |
| 21:20 |
RealBadAngel |
so, the scene will sum real lights and artificial ones |
| 21:20 |
Taoki |
But not use hardware lights for local lights too? |
| 21:20 |
RealBadAngel |
no |
| 21:20 |
Taoki |
I see. Was hoping that could be done as well |
| 21:21 |
RealBadAngel |
we do need light as a node property |
| 21:21 |
RealBadAngel |
light level |
| 21:21 |
RealBadAngel |
for that current code is enough |
| 21:21 |
Taoki |
Torches can't cast directional light then. Unless they're used very smartly in the shader code. And even so I don't think they can then cast dynamic shadows |
| 21:22 |
Taoki |
Also, I was hoping this would finally allow for colored local lights |
| 21:22 |
RealBadAngel |
coloured lights? |
| 21:22 |
RealBadAngel |
no problemo |
| 21:23 |
Taoki |
Yeah. So torches can also have a color assigned to the lighting... for example torches that cast green light |
| 21:23 |
Taoki |
If that's possible it's a good thing :) |
| 21:23 |
RealBadAngel |
irrlicht allows that |
| 21:23 |
RealBadAngel |
just we are not using it |
| 21:23 |
Calinou |
hardware lighting: the notion of light level dies? |
| 21:23 |
Calinou |
don't forget about gameplay. |
| 21:23 |
Taoki |
Yes, but for dynamic lights. You said you don't plan to add HW light sources for these |
| 21:24 |
Taoki |
Calinou: That's what we're saying. We still need light to represent param2 (light value of node) |
| 21:24 |
Taoki |
Which is the tricky part |
| 21:24 |
RealBadAngel |
color can be also a parameter |
| 21:25 |
RealBadAngel |
atm its just white |
| 21:25 |
Taoki |
yeah |
| 21:25 |
RealBadAngel |
Calinou, we will leave light level for gameplay |
| 21:25 |
Taoki |
But then the engine / shaders must also tell light sources from one another. A torch casting red light might be near one casting green light |
| 21:25 |
RealBadAngel |
and use it to lit the scene |
| 21:26 |
Taoki |
The red and green light sould combine |
| 21:26 |
Taoki |
*lights would |
| 21:26 |
RealBadAngel |
we wil see |
| 21:26 |
Taoki |
yeah |
| 21:27 |
RealBadAngel |
one thing i have to say |
| 21:27 |
RealBadAngel |
engine allows that for sure |
| 21:27 |
Taoki |
RealBadAngel: Either way, local lights and light colors can come after sun and moon HW lights are in first. You could make celestial lights hardware only at first, then later make code for locals too |
| 21:27 |
RealBadAngel |
its just us to adapt |
| 21:27 |
Taoki |
Irrlicht yes :) Though shaders are needed to change intensity based on light level |
| 21:28 |
Taoki |
As Irrlicht isn't meant to work with our contept of lighting. It doesn't understand our light levels, smooth lighting, etc |
| 21:28 |
Taoki |
Se we need to take the whole lighting pass from irrlicht, and add the light level pass as a mask to it |
| 21:28 |
RealBadAngel |
thats what i said already |
| 21:28 |
Taoki |
Right... sorry |
| 21:28 |
Taoki |
yes |
| 21:28 |
RealBadAngel |
we just need light level at a position |
| 21:29 |
RealBadAngel |
smooth lighting code is obsolete |
| 21:29 |
proller |
and very slow and buggy |
| 21:29 |
RealBadAngel |
and that is needed for things like light sensors etc |
| 21:29 |
RealBadAngel |
nothing else |
| 21:30 |
RealBadAngel |
or maybe plants growing code |
| 21:30 |
RealBadAngel |
but definitely not litin up the scene |
| 21:31 |
RealBadAngel |
also server should not care about lights |
| 21:31 |
RealBadAngel |
it makes it slow |
| 21:32 |
RealBadAngel |
longer i develop GFX stuff, more stupid things i find |
| 21:32 |
Taoki |
HW lights should still match the light level, so the server returns realistic and correct values |
| 21:32 |
RealBadAngel |
thats the real problem |
| 21:33 |
RealBadAngel |
how to bound HW lights and lightlevel |
| 21:33 |
|
markveidemanis joined #minetest-dev |
| 21:34 |
RealBadAngel |
my idea is to use existing code |
| 21:34 |
RealBadAngel |
and cut from there everything that have impact on lighting |
| 21:35 |
RealBadAngel |
just leave there light level calculations |
| 21:35 |
RealBadAngel |
but im not sure how the extra light sources will behave then |
| 21:36 |
proller |
player with torch must be light source too |
| 21:36 |
RealBadAngel |
so atm i would rather mix current system with celestial and omnidirectional ones |
| 21:37 |
RealBadAngel |
proller, i am aware of that pull. but as c55 said, for those who cant use shaders, thats disadvantage |
| 21:37 |
|
kahrl joined #minetest-dev |
| 21:37 |
RealBadAngel |
and thus cannot be allowed |
| 21:37 |
proller |
wich pull? |
| 21:38 |
RealBadAngel |
wield light |
| 21:38 |
RealBadAngel |
until its aviable for players without shaders too, i wont agree to merge it |
| 21:38 |
|
markveidemanis left #minetest-dev |
| 21:39 |
RealBadAngel |
hi kahrl |
| 21:44 |
kahrl |
hi RBA, what's up? |
| 21:46 |
RealBadAngel |
kahrl, im makin a mess in shaders.cpp, is that your code or taken from somewhere else? |
| 21:47 |
kahrl |
I took tile.cpp and deleted most of it and changed the rest to work with shaders instead of textures |
| 21:47 |
kahrl |
not sure how much it changed since I wrote it |
| 21:48 |
RealBadAngel |
lemme explain what im doing right now |
| 21:48 |
RealBadAngel |
code allowed to compile shaders at runtime, on mesh updates |
| 21:49 |
RealBadAngel |
i restricted that only to startup |
| 21:49 |
RealBadAngel |
and main thread only |
| 21:50 |
RealBadAngel |
so ive trashed threads aware code |
| 21:51 |
kahrl |
I don't remember, are all required shaders always known on startup? |
| 21:51 |
RealBadAngel |
yes |
| 21:51 |
kahrl |
if so that sounds like a good idea |
| 21:51 |
RealBadAngel |
on texture refreshing |
| 21:51 |
RealBadAngel |
in nodedef.cpp |
| 21:51 |
kahrl |
unless it causes huge startup delays like preload_item_visuals does |
| 21:52 |
RealBadAngel |
no it doesnt |
| 21:52 |
kahrl |
if there's a huge number of items |
| 21:52 |
RealBadAngel |
we do have 5 materials and 16 drawtypes |
| 21:52 |
kahrl |
ok good |
| 21:52 |
RealBadAngel |
compiling 5*16 shaders takes circa 1s |
| 21:53 |
RealBadAngel |
and even drawtypes are made in excess |
| 21:53 |
kahrl |
doesn't the current shader code answer most shader request through the material cache? |
| 21:53 |
RealBadAngel |
no use yet, but shader can be aware of dratype used |
| 21:53 |
kahrl |
requests* |
| 21:54 |
kahrl |
so doesn't it only do cross-thread requests mostly on startup? |
| 21:54 |
RealBadAngel |
not really |
| 21:55 |
RealBadAngel |
i do compile all the possible matches |
| 21:55 |
RealBadAngel |
material/drawtype |
| 21:55 |
RealBadAngel |
and then call just for ID |
| 21:56 |
RealBadAngel |
by now, it was possible to time out |
| 21:57 |
RealBadAngel |
i saw situations that game started, shaders were timed out and applied on next mesh update like 10-15s later |
| 21:58 |
kahrl |
hmm |
| 21:58 |
RealBadAngel |
more complex mods, more media, larger lags |
| 21:59 |
RealBadAngel |
my approach eliminates that |
| 21:59 |
RealBadAngel |
no go when theyre not ready |
| 21:59 |
kahrl |
I thought sapier made it so it loops until the shader is received |
| 21:59 |
kahrl |
no timeout essentially |
| 22:00 |
RealBadAngel |
i saw that many times |
| 22:00 |
RealBadAngel |
he failed then |
| 22:01 |
RealBadAngel |
anyway, shader should be compiled just once |
| 22:01 |
RealBadAngel |
and then just fetched |
| 22:01 |
RealBadAngel |
and theres absolutely no point doing that in game |
| 22:02 |
Taoki |
RealBadAngel: What if we will someday be able to turn them on or off from the pause menu? Like it should be possible with most settings really |
| 22:02 |
RealBadAngel |
why not? |
| 22:02 |
Taoki |
Perhaps add an exception to be ready for that if it will ever happen |
| 22:02 |
RealBadAngel |
just set the flag |
| 22:02 |
Taoki |
So shaders aren't applied only at process startup |
| 22:02 |
Taoki |
Sure :) |
| 22:02 |
RealBadAngel |
code is aware of the flags |
| 22:02 |
Taoki |
Awesome then |
| 22:03 |
RealBadAngel |
i was talkin about applying/compiling shaders at runtime |
| 22:03 |
RealBadAngel |
which was just insane |
| 22:03 |
kahrl |
you'll have to recreate all the meshes though when you change the setting |
| 22:03 |
RealBadAngel |
no |
| 22:04 |
RealBadAngel |
i wont do anything |
| 22:04 |
kahrl |
what about the vertex colors and day-night transition? |
| 22:04 |
RealBadAngel |
just call mesh update with new state of the flag |
| 22:05 |
RealBadAngel |
which is done all the time |
| 22:05 |
RealBadAngel |
shaders doesnt modify them |
| 22:05 |
RealBadAngel |
so turning them on/off doesnt harm |
| 22:07 |
RealBadAngel |
kahrl, plz check the current code: https://github.com/RealBadAngel/minetest/tree/shaders |
| 22:07 |
kahrl |
any part in particular? |
| 22:08 |
RealBadAngel |
nodedef.cpp |
| 22:08 |
RealBadAngel |
thats something new here |
| 22:09 |
RealBadAngel |
ive moved shaders generation from mesh updates to textures refresh |
| 22:10 |
RealBadAngel |
here, because i am able to set shader there per tile, not the node |
| 22:10 |
kahrl |
I see |
| 22:10 |
RealBadAngel |
also the code refreshes all the possible ones |
| 22:11 |
RealBadAngel |
so leaving this part makes me sure i do have everything compiled |
| 22:13 |
Taoki |
proller: https://forum.minetest.net/viewtopic.php?f=5&t=6418&p=139374 Are you (still?) someone who could attempt to help with fixing this and getting that code in? Hoping for an year to see that in master |
| 22:13 |
Taoki |
RealBadAngel: ^ Might wanna look at that too sometime, since you are good at understanding the engine and graphics system |
| 22:14 |
kahrl |
RealBadAngel: I think that's good, don't see any obvious problems with your approach anyway |
| 22:14 |
Taoki |
And also don't avoid merging something excessively I guess :P |
| 22:14 |
kahrl |
as long as we don't merge meta_set_nodedef ;) |
| 22:14 |
proller |
Taoki, it works acceptable in freeminer |
| 22:14 |
Taoki |
proller: No more memory leaks? |
| 22:14 |
proller |
maybe small |
| 22:15 |
Taoki |
Is the branch still compatible with latest master also? |
| 22:15 |
Taoki |
ok |
| 22:15 |
Taoki |
Really need to get someone to merge it in master too (disabled by default) |
| 22:15 |
|
sapier joined #minetest-dev |
| 22:15 |
proller |
firs you must kill Pilz**** ;) |
| 22:16 |
RealBadAngel |
as a workaround for meta_set_nodef i think some new drawtypes will do |
| 22:16 |
Taoki |
Does PilzAdam still care about it (as in being against it)? |
| 22:16 |
PilzAdam |
proller, small? they were quite significant on my system |
| 22:16 |
RealBadAngel |
wirelike, tubelike |
| 22:16 |
sapier |
ShadowNinja: I don't know exactly but I guess it's because celeron didn't want to wait for regular shutdown on local host |
| 22:17 |
Taoki |
IIRC, latest version of the VBO branch had much smaller memory leaks |
| 22:17 |
sapier |
that's why shuting down sets peer timeout to 0.1 second causing immediate peer droping |
| 22:17 |
RealBadAngel |
but imho ability to change nodedef on the fly could be the best solution for modding |
| 22:18 |
Taoki |
Actually, not leaks. From what I remember it's just high memory usage due to how mapblocks are handled or something |
| 22:18 |
sapier |
smaller leaks ... :-) a leak is a leak no matter how big |
| 22:18 |
Taoki |
Which could be reduced if chunks of the world were stored for a smaller amount of time client-side. |
| 22:18 |
RealBadAngel |
hold on a sec |
| 22:18 |
Taoki |
sapier: Yeah, just remembered it's not a leak after all. At least not with a simple fix that was added in the latest version. Just high memory usage |
| 22:19 |
RealBadAngel |
tiles do already have special fields |
| 22:19 |
Taoki |
There was a memory leak at first, because the mesh wasn't removed with the object. That was solved |
| 22:19 |
sapier |
aren't we talking about those engine memory leaks? |
| 22:19 |
RealBadAngel |
why the fuck nodes cant? |
| 22:19 |
Taoki |
sapier: We're talking about the legendary VBO code again :) |
| 22:20 |
PilzAdam |
Taoki, ideally the memory (RAM) should go down, since we are storing the mesh in vRAM now |
| 22:20 |
sapier |
those not beeing leaks as in lost memory but as in use even more and more memory by engine |
| 22:20 |
kahrl |
RealBadAngel: special fields? |
| 22:20 |
PilzAdam |
+usage |
| 22:20 |
Taoki |
PilzAdam: I think it does once a chunk of world is unloaded from the client at least. |
| 22:20 |
RealBadAngel |
kahrl, used for animations |
| 22:20 |
Taoki |
But server has to re-send it then |
| 22:20 |
Taoki |
When the player re-explores an area |
| 22:21 |
kahrl |
RealBadAngel: and what do you mean by adding that to nodes? |
| 22:22 |
PilzAdam |
Taoki, I am talking about mesh data |
| 22:22 |
Taoki |
PilzAdam: But given that proller and users of the Freeminer branch (as well as myself when I last tested VBO I believe) are noticing a more acceptable memory usage, maybe it can still be added with a big warning on it or something? Myself and others would still love to be able to use it. As long as it won't crash my system, I'm fine with the extra memory usage :) |
| 22:22 |
Taoki |
Ah. Mesh data isn't being removed? |
| 22:22 |
RealBadAngel |
kahrl, nodeboxes? textures? |
| 22:22 |
Taoki |
IIRC that was fixed |
| 22:23 |
kahrl |
RealBadAngel: I don't get it |
| 22:23 |
RealBadAngel |
kahrl, anything that could ovveride definition |
| 22:24 |
kahrl |
RealBadAngel: that's essentially meta_set_nodedef, isn't it? |
| 22:24 |
Taoki |
But hell... Second Life uses 3GB of RAM for me sometimes, and it still works perfectly well. I can totally live with Minetest reacing 1GB, especially with a setting I choose to enable for greater FPS |
| 22:24 |
RealBadAngel |
yes |
| 22:25 |
RealBadAngel |
thats needed as hell, no matter how |
| 22:25 |
Taoki |
Though in my last test I remember I think VBO had Minetest use less than that... depends how much you explore is all |
| 22:25 |
kahrl |
unfortunately it turned out to be too slow, iirc |
| 22:25 |
kahrl |
not surprising if it has to check metadata of each node on mesh generation |
| 22:26 |
RealBadAngel |
its done in minecraft |
| 22:26 |
RealBadAngel |
and works |
| 22:26 |
RealBadAngel |
in JAVA |
| 22:27 |
Taoki |
Sssh... never say something we want to do in Minetest is done in Minecraft. We might get into trouble ;) |
| 22:27 |
RealBadAngel |
shall i paste link to minecraft sources> |
| 22:27 |
kahrl |
really? when was that added? |
| 22:27 |
RealBadAngel |
? |
| 22:27 |
RealBadAngel |
its on github |
| 22:27 |
kahrl |
(I didn't really follow minecraft development after the official release) |
| 22:28 |
RealBadAngel |
at least server's code is on github |
| 22:28 |
RealBadAngel |
https://github.com/RealBadAngel/mc-dev |
| 22:29 |
kahrl |
well the server doesn't render stuff ;), at least I hope it doesn't |
| 22:30 |
RealBadAngel |
reading how others have done something is not violating any license |
| 22:32 |
kahrl |
as long as you don't subconsciously write the code you've read before |
| 22:32 |
kahrl |
which has happened before... some of the mingw guys avoid reading any part of the official platform SDK for that reason |
| 22:34 |
kahrl |
anyway... any link that explains the meta_set_nodedef thing in minecraft? |
| 22:35 |
kahrl |
I could maybe try it out (without reading the code) in the game |
| 22:38 |
|
BlockMen left #minetest-dev |
| 22:39 |
VanessaE |
what about the thing that Nore already did? |
| 22:41 |
kahrl |
#1118? |
| 22:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/1118 -- [WIP] Meta set nodedef by Novatux |
| 22:41 |
VanessaE |
that's the one |
| 22:41 |
VanessaE |
I've played with it |
| 22:41 |
VanessaE |
it worked surprisingly well at the time |
| 22:42 |
kahrl |
I guess the [WIP] is why it wasn't merged :) |
| 22:43 |
VanessaE |
if I have the right package in mind, this mod http://digitalaudioconcepts.com/vanessa/hobbies/minetest/microblocks.zip would be the one I used to "demo" 1118. |
| 22:44 |
RealBadAngel |
it could solve many issues we have |
| 22:45 |
RealBadAngel |
and reduce nodes definitions greatly |
| 22:45 |
VanessaE |
the mod has a bug or two but it demonstrates the concept quite well |
| 22:46 |
RealBadAngel |
mesecons/pipeworks/technic could reduce node definitions by thousands |
| 22:48 |
kahrl |
but if each node of wire or pipe has its nodebox stored in metadata, how big will mapblocks be? (mostly thinking of bandwidth problems here, though map storage could be a problem too) |
| 22:48 |
VanessaE |
I'm not sure that's too much of a concern |
| 22:49 |
VanessaE |
the biggest pipelines I've ever seen on a server are still a pittance compared to the full size of even one mapblock anyway |
| 22:49 |
kahrl |
I'd rather allow different types of wire to be distinguished by param2 |
| 22:49 |
VanessaE |
a new drawtype is best |
| 22:49 |
* VanessaE |
looks at RealBadAngel |
| 22:49 |
RealBadAngel |
i can code that |
| 22:49 |
RealBadAngel |
but that wont be universal |
| 22:50 |
VanessaE |
different types as in, HV vs LV, vs TTL? |
| 22:50 |
RealBadAngel |
as nores/c55 work could be |
| 22:51 |
RealBadAngel |
see, if i code wires, still pipes wont be single defed |
| 22:51 |
RealBadAngel |
then i can code pipes |
| 22:51 |
RealBadAngel |
but what if we want another kind of wires/pipes/whatever? |
| 22:51 |
kahrl |
how about allowing multiple node definitions for each node |
| 22:52 |
kahrl |
which one is used is selected by param2 |
| 22:52 |
VanessaE |
I'd think the node name alone would be sufficient for that? |
| 22:53 |
VanessaE |
multiple node defs? |
| 22:53 |
VanessaE |
hm |
| 22:54 |
kahrl |
I thought you wanted to reduce node ID usage |
| 22:54 |
VanessaE |
hmmmm.... |
| 22:54 |
VanessaE |
well sure, of course |
| 22:54 |
VanessaE |
but you have to be able to texture them |
| 22:54 |
VanessaE |
and define them to do different things |
| 22:55 |
VanessaE |
an LV cable looks and behaves differently from a HV cable, for example |
| 22:56 |
kahrl |
well it depends on what the nodes do |
| 22:56 |
VanessaE |
but to have a single "LV cable" node that can change shape automatically instead of having to define dozens of shapes, that's the benefit I was thinking of |
| 22:56 |
kahrl |
I mean ABMs would still just match on node name and not on node name + param2 |
| 22:56 |
VanessaE |
just as you have one "fence" node that changes shape depending on its surrounding fence nodes. |
| 22:56 |
kahrl |
but if the different behaviour is implemented in lua, of course lua can check param2 |
| 22:57 |
sapier |
http://de.tinypic.com/r/n6ffuu/8 what do you think about adding download rate to media download progress bar? |
| 22:57 |
VanessaE |
right, but param2 is numeric. that could get confusing in the code. |
| 22:57 |
VanessaE |
sapier: +1000000000^(inf) |
| 22:58 |
kahrl |
true |
| 22:58 |
sapier |
but will only work for mintest download not for http mode |
| 22:58 |
proller |
instead of speeding up connection will print download animations... |
| 22:58 |
VanessaE |
sapier: you could calculate it for http too, as you already know when you requested a media object and when it arrives |
| 22:58 |
VanessaE |
the speed would just be more coarse |
| 22:59 |
sapier |
yes but that's gonna be quite tricky |
| 22:59 |
sapier |
and to be honest I don't have real interest in http mode |
| 22:59 |
VanessaE |
proller, if you think printing a speed to the screen is gonna slow down a network connection, you need to go back to Intro to Computing 101. |
| 23:00 |
sapier |
well proller those numbers are real numbers not some fake pictures |
| 23:01 |
VanessaE |
sapier: that said, it might be sufficient to just print the current speed and not the average speed. |
| 23:01 |
sapier |
and it's not mega bit but megabyte |
| 23:03 |
sapier |
yes seems to be a little bit big to me too |
| 23:03 |
|
PenguinDad left #minetest-dev |
| 23:04 |
sapier |
right now rate is only updated once per 10 seconds to cause quite less cpu usage ... means it's gonna be 0 KB at begining for 10s ... while progress bar already increases ... looks a little bit strange |
| 23:04 |
sapier |
for this picture I had 160mb texture data to have a chance to take it |
| 23:05 |
proller |
shut up and commit |
| 23:05 |
sapier |
it's localhost as my internet connection can't handle more then about 300-400 kb/s |
| 23:05 |
sapier |
average and current or current only? |
| 23:06 |
proller |
curr |
| 23:06 |
VanessaE |
current only I think. |
| 23:06 |
sapier |
ok current is 10s |
| 23:17 |
sapier |
https://github.com/sapier/minetest/tree/add_media_download_rate it's still WIP |
| 23:18 |
sapier |
you have to either compile non curl client or disable http fetching by adding "disable_remote_media_server = true" to config |
| 23:20 |
|
iqualfragile joined #minetest-dev |
