| Time |
Nick |
Message |
| 00:01 |
Fixer |
sofar: now do CSM version of skybox %) |
| 00:01 |
Fixer |
sofar: i like it |
| 00:02 |
Fixer |
https://i.imgur.com/Wk9599A.jpg |
| 00:02 |
Fixer |
damn it is good |
| 00:02 |
Fixer |
so good |
| 00:05 |
Fixer |
https://i.imgur.com/sVwmOOP.jpg :O |
| 00:05 |
Fixer |
add ambience to this and get a top f-ing win |
| 00:08 |
Fixer |
good night everyone |
| 00:09 |
* VanessaE |
throws up her hands in frustration. I give up! Technic is too complicated for me to fix any more :( |
| 00:09 |
* Jordach_ |
gives VanessaE a hug |
| 00:09 |
* Jordach_ |
understands |
| 00:11 |
VanessaE |
with all due respect as appropriate, technic's codebase sucks. it's impossible to understand, scattered across too many files, terribly organized, and 1000x more complicated than it needs to be |
| 00:11 |
VanessaE |
nore: enjoy. :P |
| 00:11 |
* Jordach_ |
isn't re-writing that |
| 00:11 |
* nore |
is ^^' |
| 00:24 |
* Jordach_ |
performs the solar plains art pass on RBA's water texture |
| 00:25 |
Jordach_ |
https://github.com/minetest/minetest_game/blob/master/mods/default/README.txt#L40 |
| 00:47 |
benrob0329 |
Hello |
| 00:55 |
Jordach_ |
wat ze fak |
| 00:55 |
Jordach_ |
_OnGenerated(): not enough memory |
| 00:55 |
Jordach_ |
2017-04-14 01:55:13: ERROR[Main]: Current Lua memory usage: 9 MB |
| 00:55 |
Jordach_ |
>9MB |
| 00:57 |
Jordach_ |
FFFFFFF |
| 00:57 |
Jordach_ |
2017-04-14 01:57:32: ERROR[Main]: Current Lua memory usage: 3 MB |
| 00:57 |
Jordach_ |
GC64 WEN |
| 01:00 |
benrob0329 |
What is this, 1994? |
| 01:00 |
Jordach_ |
sofar, https://jordach.net/Images/Screenshots/screenshot_20170414_015939.png |
| 01:00 |
Jordach_ |
shits fire yo |
| 01:00 |
Jordach_ |
there's a few texture revisions to the trees |
| 01:01 |
benrob0329 |
O_O |
| 01:01 |
Jordach_ |
overkill or underkill |
| 01:01 |
* benrob0329 |
wishes he was home to do a cinematic video now |
| 01:01 |
Jordach_ |
dirt, grass, grass side, cherry side, birch side, water |
| 01:01 |
* Jordach_ |
OOMs again |
| 01:02 |
Jordach_ |
benrob0329, https://jordach.net/Images/Screenshots/screenshot_20170414_020213.png |
| 01:02 |
Jordach_ |
RBA's water with a solar plains art pass |
| 01:03 |
benrob0329 |
Jordach_: its...beautiful |
| 01:06 |
nore |
wow |
| 01:06 |
Jordach_ |
if Solar Plains the one game with amiga art can look 800% BETTER |
| 01:28 |
benrob0329 |
http://imgur.com/a/IwXuX |
| 01:28 |
benrob0329 |
my, this isnt broken at all |
| 03:11 |
|
shivajiva joined #minetest-hub |
| 05:37 |
VanessaE |
sofar: so.. about the skybox mod. alpha support and multi-layers and hard-coded sky behind the images ... when? :D |
| 05:43 |
sofar |
!tell fixer csm skyboxes make little sense - there's nothing to opimize |
| 05:43 |
ShadowBot |
sofar: O.K. |
| 05:54 |
nore |
sofar: procedurally-generated skyboxes by client :) |
| 05:54 |
|
lumidify joined #minetest-hub |
| 06:17 |
sofar |
sure, but that needs a lot of engine work |
| 06:19 |
VanessaE |
"New in 0.4.17: [...] map terrain generation can now be applied to the skies to produce clouds (sofar) [...] " |
| 06:19 |
VanessaE |
:) |
| 06:19 |
|
nerzhul joined #minetest-hub |
| 06:24 |
sofar |
VanessaE: honestly that mod isn't doing anything new |
| 06:24 |
sofar |
VanessaE: it's just smart about how and what |
| 06:28 |
VanessaE |
perhaps, but only takes one good baser implementation to get people really interested in moar Moar MOAR :) |
| 06:28 |
VanessaE |
-r |
| 06:29 |
|
CWz joined #minetest-hub |
| 07:11 |
celeron55 |
what i do on computers that have the stutter in singleplayer is i just set max_simultaneous_block_sends_per_client = 1 |
| 07:16 |
celeron55 |
at this point i can't guess if it even is the same stutter as years ago, could be something different |
| 07:19 |
|
tenplus1 joined #minetest-hub |
| 07:19 |
tenplus1 |
hi folks |
| 07:19 |
VanessaE |
morning, tenplus1 |
| 07:19 |
tenplus1 |
hi Vanessa |
| 07:20 |
VanessaE |
celeron55: am I at least close in my guess then, that the mesh generator stalls the renderer because they're in the same thread (or at same priority)? |
| 07:21 |
celeron55 |
eh, they aren't in the same thread |
| 07:21 |
tenplus1 |
hi celeron |
| 07:21 |
VanessaE |
hm, ok |
| 07:21 |
celeron55 |
the stutter would be unimaginable in that case |
| 07:23 |
celeron55 |
when i was digging into it years ago, the mesh generator could process all it wanted; the stutter happened only when the generated meshes were made to be rendered which meant that something did something with them synchronously at the first time they were rendered, and irrlicht didn't seem to, so the suspect ended up being the gpu driver |
| 07:24 |
celeron55 |
i think that showed up as mainloop_draw time though |
| 07:25 |
celeron55 |
well it does spike in Fixer's graphs also |
| 07:25 |
VanessaE |
better to visit VE-S and see for yourself. especially walking from spawn eastward toward the tunnel |
| 07:26 |
VanessaE |
if you really wanna melt your machine down, install HDX too ;) |
| 07:26 |
VanessaE |
(but I think we've been through this before) |
| 07:27 |
celeron55 |
looks like on this system it looks like back then |
| 07:28 |
celeron55 |
all the stutter is seen in mainloop_draw |
| 07:29 |
VanessaE |
is that good, or bad? :) |
| 07:29 |
celeron55 |
http://i.imgur.com/SGImCRM.png |
| 07:29 |
celeron55 |
like this |
| 07:30 |
celeron55 |
it means it's the same thing as before, to which there seems to be no other solution than to just not update more meshes than 1 per frame |
| 07:30 |
celeron55 |
back then i found it to be outside of MT's control otherwise |
| 07:31 |
VanessaE |
http://i.imgur.com/pi3QFYq.png |
| 07:31 |
VanessaE |
that's my test world. |
| 07:32 |
VanessaE |
jitter/fps are actually fairly good on that shot, as you can see |
| 07:32 |
tenplus1 |
o.O the fist looks like it's trying to make a fart sound |
| 07:32 |
celeron55 |
that has some _other like Fixer's, but most of it seems to be in _draw |
| 07:32 |
celeron55 |
awit |
| 07:32 |
celeron55 |
wait* |
| 07:32 |
celeron55 |
no it doesn't |
| 07:33 |
celeron55 |
isn't* |
| 07:33 |
* celeron55 |
how does i english |
| 07:33 |
VanessaE |
you talk good Engrish ;) |
| 07:34 |
celeron55 |
i think those graphs look fine enough, no need to do anything |
| 07:34 |
VanessaE |
wait.. :P |
| 07:34 |
VanessaE |
http://i.imgur.com/WlhEOUf.png |
| 07:36 |
celeron55 |
that's still nothing compared to Fixer's |
| 07:36 |
VanessaE |
ok, let's try ... this. >:-) |
| 07:37 |
celeron55 |
what is important is the amount of stutter compared to the base level of processing |
| 07:37 |
VanessaE |
http://i.imgur.com/dyIkrVk.png |
| 07:38 |
celeron55 |
doesn't seem to correlate with mesh generation |
| 07:38 |
VanessaE |
it was. |
| 07:38 |
VanessaE |
or it was entities loading, maybe |
| 07:38 |
celeron55 |
actually, Fixer's might not either |
| 07:38 |
VanessaE |
I'm not sure which. |
| 07:38 |
celeron55 |
i just realized something, actually |
| 07:39 |
VanessaE |
however, with each stall, there's new meshes coming in |
| 07:39 |
VanessaE |
oh? |
| 07:40 |
celeron55 |
if a frame takes 2x the time due to literally anything at all, the server may have sent 2x the amount of meshes during that time and that can cause the meshes to spike for that exact amount |
| 07:40 |
VanessaE |
sounds reasonable. |
| 07:40 |
celeron55 |
i'm calling any _other-only spikes as not being caused by mesh generation |
| 07:41 |
celeron55 |
Fixer has similar ones, it's not the thing my screenshot is showing |
| 07:41 |
celeron55 |
and not the thing i looked into back then |
| 07:42 |
celeron55 |
it's probably just something the client directly does with some kind of data as it comes from the server (it does all that synchronously) |
| 07:43 |
celeron55 |
(except for things that have specially made workers like meshes) |
| 07:47 |
celeron55 |
that should be easily diagnosed by just adding a time measurement to all packet handlers and seeing which one is the most active when that kind of stutter happens |
| 07:51 |
VanessaE |
celeron55: try this: sign onto daconcepts.com 30001, I'll teleport you to where I am. |
| 07:52 |
VanessaE |
just turn on the graphs and observe the thing I'm looking at. |
| 07:52 |
celeron55 |
might not be very useful on this system that has the problem with meshes already |
| 07:52 |
VanessaE |
(a simple mesecons clock that runs a few dozen lengths of wire, toggles about once per 1.5 seconds, on average) |
| 07:54 |
celeron55 |
i guess i can cook and eat my breakfast while this media download is happening |
| 07:54 |
VanessaE |
heh |
| 07:54 |
VanessaE |
should only take a minute or two |
| 07:55 |
VanessaE |
well maybe a bit more since you're getting 1 Mbps or so :) |
| 07:58 |
VanessaE |
ah, I see you in-game. let me know when and I'll teleport you over here. |
| 07:58 |
VanessaE |
(or you can just wander around, it isn't far from the spawn) |
| 07:59 |
tenplus1 |
Fire Redo updated to add new /fire (on.off) command to stop and remove spreading fire in-game |
| 08:02 |
VanessaE |
celeron55: melted your computer into slag? |
| 08:04 |
|
Krock joined #minetest-hub |
| 08:04 |
tenplus1 |
hi Krock |
| 08:04 |
Krock |
hi tenplus1 |
| 08:04 |
VanessaE |
morning Krock |
| 08:04 |
Krock |
moin VanessaE |
| 08:06 |
tenplus1 |
what kinda priv should be required to turn fire spreading on/off ? |
| 08:06 |
Krock |
server, I guess? |
| 08:06 |
tenplus1 |
kewl, got that set as default |
| 08:07 |
cheapie |
celeron55: http://imgsrv.worldstart.com/1/8773Body.jpg yet? |
| 08:07 |
celeron55 |
well, all i can say is that what i see doesn't disprove what i said |
| 08:07 |
tenplus1 |
github.com/tenplus1/fire <-- new /fire (on|off) added to stop fire spreading in-game... also normal chest burns and drops items |
| 08:07 |
VanessaE |
celeron55: fair enough. Just wanted you to see what an in-practice server looks like |
| 08:07 |
VanessaE |
in the graphs |
| 08:07 |
* tenplus1 |
gets out marshmallows |
| 08:08 |
celeron55 |
the stutter is ridiculous though |
| 08:08 |
cheapie |
I turned my meshgen delay up a bit, seems fine to me now. |
| 08:10 |
celeron55 |
if someone has a system that doesn't stutter on VE-S, i'd like to know |
| 08:10 |
tenplus1 |
ve-s ? |
| 08:10 |
VanessaE |
tenplus1: daconcepts.com 30001 |
| 08:10 |
cheapie |
celeron55: Mine only stutters if I have a low or 0 meshgen delay set. |
| 08:10 |
VanessaE |
aka "VE-Survival" or "VE-S" for short. |
| 08:10 |
tenplus1 |
logging in |
| 08:10 |
cheapie |
Jordach's might be able to handle 0. |
| 08:11 |
VanessaE |
my machine can't avoid stutter even at 50. |
| 08:11 |
celeron55 |
cheapie: on that server? |
| 08:11 |
cheapie |
Yes. |
| 08:11 |
celeron55 |
it doesn't seem mesh-related, what else does the meshgen delay affect? |
| 08:12 |
cheapie |
I don't have much noticeable stutter at 10, but it's rather bad at 0. |
| 08:12 |
cheapie |
It seems to be worse with lots of entities moving around, maybe that's it? |
| 08:12 |
tenplus1 |
christ, am getting 5fps... what's up here ??? |
| 08:13 |
tenplus1 |
tha's better, am away from spawn... 29 fps... no stutter so far |
| 08:16 |
tenplus1 |
any chance of adding a /clear chat command ? |
| 08:17 |
tenplus1 |
would help a lot |
| 08:17 |
cheapie |
Make a client mod for it :P |
| 08:17 |
tenplus1 |
can lua actually clear log ??? |
| 08:17 |
Krock |
no but it can be flooded with empty messages |
| 08:17 |
cheapie |
By displaying a bunch of blank messages, yeah. |
| 08:18 |
tenplus1 |
noooooo, that's a nasty way of doing it... by clear I mean delete log entirely |
| 08:18 |
tenplus1 |
celeron55: am in the middle of nowhere with 54fps and no stutter, even when loading map |
| 08:20 |
tenplus1 |
what am I looking for in F5 stats ? |
| 08:20 |
|
lumidify_ joined #minetest-hub |
| 08:20 |
tenplus1 |
hi lumidify |
| 08:21 |
celeron55 |
no you need to be right in the center of everything |
| 08:21 |
celeron55 |
and what you're looking for in F5 is a screenshot |
| 08:21 |
tenplus1 |
so go back to spawn and take a screenshot of stats ? |
| 08:21 |
celeron55 |
that's a good start |
| 08:23 |
celeron55 |
preferably with a view range of not very far like <100 so that stutter is clearer |
| 08:25 |
tenplus1 |
http://tinypic.com/view.php?pic=35b6luu&s=9 |
| 08:26 |
tenplus1 |
does that help ? |
| 08:28 |
celeron55 |
yeah, looks pretty much the same as for me |
| 08:29 |
celeron55 |
and now i'm thinking maybe this is related to mesh generation, but in a different way than what i've seen before |
| 08:31 |
tenplus1 |
brb |
| 08:31 |
|
tenplus1 left #minetest-hub |
| 08:34 |
celeron55 |
the goal can't be anything else than getting rid of all that, of course, but i need to find out whether it's actually possible in practice |
| 08:35 |
celeron55 |
or someone has to; i'm taking a look now in case it happens to be worth anything |
| 09:29 |
|
nerzhul joined #minetest-hub |
| 09:31 |
VanessaE |
*sees celeron55 re-join on VE-S* |
| 09:31 |
VanessaE |
uh oh, I think I lit a fire ;) |
| 09:38 |
|
Darcidride joined #minetest-hub |
| 09:48 |
sfan5 |
why do people want me to remove xanadu from the srvlist? |
| 09:48 |
sfan5 |
(ping: sofar) |
| 10:02 |
* VanessaE |
wonders what celeron55 is up to... |
| 10:03 |
sfan5 |
hm well i get that it doesn't accept registrations atm |
| 10:03 |
sfan5 |
but having a server on the list still is useful for providing the client with flags |
| 10:03 |
sfan5 |
so it can populate the entry players have in their favorites |
| 10:04 |
VanessaE |
if it were up to me, any server that's gone private like that would be best excluded from the public list |
| 10:05 |
sfan5 |
we could just move it to the bottom |
| 10:05 |
VanessaE |
sounds fair |
| 10:05 |
VanessaE |
demote rather than delete |
| 10:18 |
nerzhul |
sfan5, can you tell me what do we do with https://github.com/minetest/minetest/pull/5559 ? Merge ? remove some files from the changeset and merge ? |
| 10:19 |
sfan5 |
i'll look at it later |
| 10:21 |
|
Fixer joined #minetest-hub |
| 10:26 |
|
lumidify joined #minetest-hub |
| 10:39 |
* VanessaE |
wanders off to sleep |
| 10:54 |
celeron55 |
http://i.imgur.com/t2xoh55.png |
| 10:57 |
celeron55 |
most of the mainloop_other time is handling of TOCLIENT_BLOCKDATA packets, most of which is spent deserializing mapblock node metadata inventories and the rest is copying mapblock data to the mesh generator |
| 10:59 |
celeron55 |
mainloop_dtime is mainloop_other + mainloop_draw though, and i have no idea why mainloop_draw bounces up like that |
| 11:00 |
Shara |
Hello all |
| 11:01 |
celeron55 |
but it does look like on VE-S at least a third of the lagginess is due to lots of node inventories being received all the time |
| 11:02 |
celeron55 |
at least in that specific spot |
| 11:05 |
celeron55 |
if one limits the mesh generator speed, then the server will wait for it before sending more mapblock updates and that way the TOCLIENT_BLOCKDATA handler doesn't get so much data and the server is capable of doing enough prioritization for the missing updates to not be very noticeable |
| 11:06 |
celeron55 |
(mainly it just leaves out updates for blocks that are not very close to the player) |
| 11:11 |
Krock |
thus, it may be helpful to not send the while mapblock if only the node meta changed |
| 11:11 |
celeron55 |
the server will send a full mapblock basically always when something changes and it doesn't have a more specific way of sending the change, and also if there are many small changes |
| 11:11 |
Krock |
*whole |
| 11:11 |
Fixer |
stutters i seen: 1) meshgen (most annoying) 2) due to mesecons/stuff 3) big freezes during loading kaeza signs (catched on ve-s) 4) other stutters that show up in mainloop_other (including in singleplayer) |
| 11:12 |
Fixer |
5) stutter when using https://github.com/minetest-mods/dynamic_liquid/ in ocean with open cave below (very big stutter in mainloop_other) |
| 11:13 |
celeron55 |
Fixer: meshgen doesn't show up in mainloop_other; stop calling it that and call it mapblock updates instead |
| 11:13 |
celeron55 |
it just happens to be that the meshgen is invoked for mapblock updates (obviously) |
| 11:13 |
Fixer |
i know, where did i said it? /me sips coffee |
| 11:14 |
Fixer |
yes, mainloop other is nondraw related |
| 11:15 |
celeron55 |
Krock: it would be very useful to know what even changes on the server to cause the updates |
| 11:16 |
Fixer |
i pinpointed kaeza signs that skyrocket mainloop_other part, but what causes it in vanilla singleplayer... |
| 11:16 |
celeron55 |
i'm not going to try guessing |
| 11:16 |
|
Jordach joined #minetest-hub |
| 11:17 |
celeron55 |
adding some logging on the server might be a good idea, just to make it say why it's sending mapblocks |
| 11:17 |
Fixer |
"mini" stutter https://i.imgur.com/JH9rDBm.png |
| 11:18 |
Fixer |
just 0.009 in other but some time before it was like 0.3 |
| 11:18 |
Fixer |
lone spike |
| 11:21 |
Fixer |
sofar's skybox mod: https://i.imgur.com/CbQDVC5.jpg |
| 11:26 |
Fixer |
kek https://i.imgur.com/FAB2Kx3.png |
| 11:26 |
Fixer |
2.2 sec stutter |
| 11:26 |
Fixer |
mainloop_other |
| 11:27 |
celeron55 |
http://i.imgur.com/XCR3wqc.png |
| 11:27 |
celeron55 |
deserializing about a thousand inventorylists per frame 8) |
| 11:27 |
celeron55 |
how about that |
| 11:27 |
Jordach |
*click* noice |
| 11:28 |
Fixer |
https://i.imgur.com/Roasy40.png standing on spawn with mesh gen delay set at 15ms |
| 11:28 |
Krock |
holy shit. where do these changes even come from?! |
| 11:28 |
Fixer |
traffic from vanessa server is about 100kbyte/sec |
| 11:29 |
celeron55 |
Krock: that's what i'd like to know |
| 11:29 |
Fixer |
still, mesh gen interval at 15 ms helps immensely on ve-s |
| 11:31 |
celeron55 |
let's write some instrumentation for VE's server and see what on earth it's even trying to do |
| 11:34 |
Jordach |
celeron55, i think that's like errr disecting a dead whale, it'll likely explode if you do :P |
| 11:36 |
Fixer |
van spawn without mesh gen delay https://i.imgur.com/tRhO5yi.png |
| 11:40 |
Fixer |
sigh, nore's shop has no text on kaeza signs because of usual reasons |
| 11:40 |
Fixer |
too many entities or smth |
| 12:09 |
celeron55 |
in the VE-S case, i think it's not feasible to make much improvement on the client side when the server is being that silly |
| 12:12 |
celeron55 |
i pushed those additional graphs to this branch https://github.com/celeron55/minetest/tree/toclient_blockdata_graphs |
| 12:13 |
celeron55 |
some random screenshots of those might be useful |
| 12:18 |
|
Megaf joined #minetest-hub |
| 12:23 |
CWz |
Upps forgot to remove that tag |
| 12:24 |
Krock |
ha ha ha. I don't get it. |
| 12:24 |
Fixer |
added to my compile patch set |
| 12:27 |
|
paramat joined #minetest-hub |
| 12:28 |
Krock |
*compiles* |
| 12:28 |
Fixer |
*compiling intensifies* |
| 12:29 |
paramat |
the worst problem i get is long, up to 1 sec, screen freezes. i often notice this when starting a new world and flying fast over a large snowy forest (complex meshes) with view range 130-190 |
| 12:31 |
|
tenplus1 joined #minetest-hub |
| 12:31 |
tenplus1 |
hi folks |
| 12:31 |
Krock |
hi tenplus1 |
| 12:32 |
celeron55 |
paramat: sounds like you probably run out of RAM and your system ends up swapping |
| 12:32 |
Megaf |
Hi onetyone |
| 12:32 |
tenplus1 |
hi Megaf |
| 12:32 |
* Megaf |
dont know how he is not the most hated person on Earth |
| 12:33 |
tenplus1 |
celeron55: strangely enough I had that issue yesterday, mt ram usage shot right up and used vm causing major lag and stall |
| 12:33 |
celeron55 |
meshes use up a lot of memory |
| 12:33 |
tenplus1 |
this was default game |
| 12:33 |
tenplus1 |
no mods |
| 12:34 |
Fixer |
ram size? |
| 12:34 |
tenplus1 |
my net-top has 2gb physical and 1gb vm |
| 12:35 |
Shara |
Hi ten :) |
| 12:35 |
tenplus1 |
hi Shara :) |
| 12:35 |
tenplus1 |
got something you may like btw... github.com/tenplus1/fire |
| 12:37 |
Krock |
some stats: http://i.imgur.com/ASZVijB.png |
| 12:38 |
Calinou |
hi tenplus1 |
| 12:39 |
tenplus1 |
hi cal |
| 12:39 |
Shara |
tenplus1: My skyboxes are almost working now :) |
| 12:39 |
Shara |
Just need to find or make a couple more |
| 12:39 |
tenplus1 |
ooh, link meh :P I like what I saw before |
| 12:39 |
Shara |
http://rc.minetest.tv/wp-content/uploads/2017/04/thebox_sky_hub.png |
| 12:40 |
Shara |
And thinking of using http://rc.minetest.tv/wp-content/uploads/2017/04/thebox_sky_night.png |
| 12:40 |
tenplus1 |
ooh |
| 12:40 |
tenplus1 |
I added a command to fire Redo for noob servers... can type: /fire off and it stops spreading in-game and removes nodes on update |
| 12:41 |
Shara |
Problem is, the people it would help are unlike to find a redo mod |
| 12:41 |
Shara |
Byt the time they do that, they know enough to find options too |
| 12:41 |
Shara |
though I like the idea of an ingame switch |
| 12:41 |
tenplus1 |
heh yeah... but would let owners enable fire with a quick option to disable it |
| 12:44 |
Shara |
I just need time to make the teleporters I need now :P |
| 12:44 |
tenplus1 |
custom mods 101 :PPP |
| 12:45 |
Shara |
It's the only way to do this one |
| 12:45 |
tenplus1 |
whaddya need from it ? |
| 12:45 |
Shara |
The teleporters? |
| 12:45 |
tenplus1 |
yeah |
| 12:45 |
Shara |
Hehe, PMN if you want to help. You'd be more than welcome to :) |
| 12:45 |
Shara |
PM* |
| 12:46 |
paramat |
nope it wasn't running out of RAM i have 7GB free |
| 12:46 |
Fixer |
paramat: https://github.com/celeron55/minetest/tree/toclient_blockdata_graphs |
| 12:47 |
Fixer |
paramat: this has more debug graphs, try with it |
| 12:48 |
paramat |
thanks |
| 12:51 |
celeron55 |
those graphs were chosen to pinpoint the problem on VE-S, they aren't general purpose, really, altough at least you can tell if the problem is the same or not |
| 12:52 |
paramat |
ok |
| 12:53 |
paramat |
i have (good, recent) intel integrated graphics though, maybe this has an effect |
| 12:59 |
celeron55 |
in Krock's screenshot one can see that 1) the particular location doesn't have a similarly massive metadata inventory issue as VE-S does, 2) copying mapblock data to mesh update tasks is too slow, 3) there are also other spikes in mainloop_other not caused by anything done by the toclient_blockdata handler |
| 13:00 |
Krock |
in other words meaningless |
| 13:00 |
celeron55 |
finding out what the other spikes are would be useful |
| 13:01 |
Krock |
since the spikes aren't that big |
| 13:02 |
celeron55 |
well, in my opinion any mainloop_dtime spike that is twice as high as the normal frametime is too high |
| 13:03 |
celeron55 |
in other words i'm happy if dtime_jitter is less than 100% |
| 13:04 |
celeron55 |
or, well, i'm happy anyway, but i don't expect players to be happy with that being higher than 100% 8) |
| 13:06 |
Fixer |
will try with dynamic liquid mod |
| 13:08 |
Fixer |
dynamic liquid mod : https://i.imgur.com/fGMoULo.png |
| 13:08 |
Fixer |
freezes |
| 13:08 |
paramat |
unsurprisingly |
| 13:10 |
Fixer |
dynamic liquid uses abms on water nodes iirc |
| 13:10 |
Fixer |
swaps nodes etc |
| 13:10 |
paramat |
nightmare |
| 13:10 |
paramat |
it's bad enough in C++ |
| 13:11 |
Fixer |
ve-s time |
| 13:12 |
Fixer |
celeron55: is it possible to export graph data into csv file and profile like everything.... and then in excel sort out worse offenders |
| 13:13 |
Fixer |
huge freeze on ve-s probably because of kaeza signs with those graphs: https://i.imgur.com/d3cLYLH.png |
| 13:14 |
Fixer |
mesh upd interv 15 ms |
| 13:15 |
Fixer |
2.11 sec freeze somewhere in other: https://i.imgur.com/YHGfZ37.png |
| 13:16 |
celeron55 |
<+Fixer> dynamic liquid mod : https://i.imgur.com/fGMoULo.png <- this is a good example of a spike that is mainly due to the copying of mapblock data to the meshgen |
| 13:17 |
celeron55 |
(it's visible as MeshMakeData::fill making up most of the spike) |
| 13:17 |
celeron55 |
(85.8ms out of 100ms) |
| 13:19 |
|
sniper338 joined #minetest-hub |
| 13:21 |
celeron55 |
https://i.imgur.com/d3cLYLH.png https://i.imgur.com/YHGfZ37.png <- in these the main source of the >1s spike is not visible; it's something else than anything in the toclient_blockdata handler |
| 13:22 |
celeron55 |
i would assume any >1s spike is the OS having to move stuff between ram and swap |
| 13:22 |
celeron55 |
but maybe it could be something else too |
| 13:23 |
celeron55 |
Fixer: it's possible but all the measurements have to be added to the code |
| 13:24 |
tenplus1 |
back laters |
| 13:27 |
Fixer |
8gbit ram, 64 bit os |
| 13:41 |
celeron55 |
Fixer: you made a windows build, right? can you upload it somewhere, i'll take some measurements myself |
| 13:41 |
celeron55 |
i don't have a build toolchain on this windows box |
| 13:46 |
paramat |
my long freezes are only rarely near 1s, mostly they are around 0.2s |
| 13:46 |
Fixer |
celeron55: yes |
| 13:46 |
Fixer |
celeron55: will upload |
| 13:46 |
Fixer |
celeron55: win build via mingw64 crosscompile from lin to win |
| 13:49 |
Fixer |
celeron55: https://transfer.sh/56Aao/minetest-0.4.15-98286a2-win64-PR4981-5533-profile.zip |
| 13:55 |
celeron55 |
looks like MeshMakeData::fill slowness is the general issue on this system |
| 13:58 |
celeron55 |
there's the PR about this, right? the one that takes away the copying of some of the neighbors |
| 13:59 |
paramat |
erm |
| 14:00 |
paramat |
https://github.com/minetest/minetest/pull/5239 ? |
| 14:05 |
celeron55 |
the thing is, there's no way to skip this code, and there's no way to make this code asynchronous |
| 14:05 |
celeron55 |
and it's already probably the fastest implementation in what it does |
| 14:07 |
celeron55 |
well actually there is a way to make it asynchronous |
| 14:07 |
celeron55 |
what that would involve is having two copies of the entire Map on the client, one for the main thread and one for the mesh generator thread |
| 14:09 |
|
Megaf joined #minetest-hub |
| 14:09 |
|
nerzhul joined #minetest-hub |
| 14:15 |
celeron55 |
possibly with some kind of dynamic batching |
| 14:17 |
celeron55 |
preparing the data for the mesh generation job of one mapblock already collects most of the data for generating the mesh of a neighboring mapblock; adding some neighbors to it is relatively cheap |
| 14:20 |
celeron55 |
actually, the calling code is so stupid upgrading this doesn't even mean it has to be dynamic, it just needs to be less stupid... |
| 14:21 |
Fixer |
pr 5239 did not eliminate the stutter for me |
| 14:23 |
celeron55 |
nothing will eliminate it but it should have removed some of the stutter |
| 14:23 |
celeron55 |
are you sure it didn't? |
| 14:24 |
celeron55 |
it literally removes 77% of processing in MeshMakeData::fill which is the main reason for the spike in https://i.imgur.com/fGMoULo.png |
| 14:25 |
Fixer |
https://github.com/minetest/minetest/pull/5239#issuecomment-280632461 |
| 14:25 |
celeron55 |
i would expect 5239 to at least halve the spike in that screenshot |
| 14:26 |
Fixer |
it probably fixes only some sorts of stutter |
| 14:26 |
celeron55 |
the only way to fix all sorts of stutter is to stop using minetest, lol |
| 14:26 |
Fixer |
mesh_generation_interval = 15 |
| 14:27 |
Fixer |
with this i do not need to quit minetest |
| 14:27 |
Fixer |
helps immensely in vanilla singleplayer |
| 14:28 |
Fixer |
ve-s is worst kind of lagserver |
| 14:28 |
Fixer |
just test was too |
| 14:28 |
Fixer |
but it died |
| 14:30 |
celeron55 |
5239 won't help with the problem in VE-S, it's a different stutter |
| 14:30 |
celeron55 |
or, well, VE-S has it too, but it has larger stutters that make it irrelevant |
| 14:34 |
celeron55 |
Fixer: can you test with and without 5239's first commit (not the extra two); the preferred situation is the initial first seconds of loading a world that has been generated beforehand |
| 14:35 |
celeron55 |
take a screenshot of the graphs just before the first graph lines are about to disappear |
| 14:35 |
Fixer |
i can try |
| 14:36 |
celeron55 |
even on this laptop that barely has any stutter i can see a 2x decrease in stutter (if you can even call it stutter on this...) |
| 14:36 |
celeron55 |
http://i.imgur.com/WziViVq.png <- without 5239's first commit |
| 14:36 |
celeron55 |
http://i.imgur.com/yJL08oJ.png <- with 5239's first commit |
| 14:37 |
celeron55 |
mainloop_other is cut in half |
| 14:37 |
celeron55 |
this is with mesh_generation_interval = 0, which should probably be used for these tests |
| 14:38 |
Fixer |
i will use default config |
| 14:38 |
nerzhul |
modders, i'm working on chat protocol rewrite (started in january), to have better client side handling. A chat message is now composed with: (message, sender, type). Type is: (raw, normal, announce, system) |
| 14:38 |
nerzhul |
it will permit CSM mods to ate message and handle it to do nice things (for examples with this mode you can easily create mods to change chat colors depending on type message or nicknames) |
| 14:38 |
nerzhul |
do you think i miss someting ? |
| 14:39 |
nerzhul |
maybe a timestamp |
| 14:39 |
nerzhul |
no ? |
| 14:42 |
Jordach |
http://oh-god-not-ht.ml/ |
| 14:44 |
Krock |
http://yeahboi.me/ |
| 14:45 |
octacian |
nerzhul: cool! |
| 14:51 |
Fixer |
celeron55: you mean lower peak mainloop_other? there needs to be some kind of moving avg |
| 14:51 |
celeron55 |
well, the problem is spikes, so peak works fine |
| 14:55 |
nerzhul |
ty octacian :) |
| 15:00 |
Fixer |
celeron55: somewhat crude, i can do it much better https://imgur.com/a/qmbjO |
| 15:01 |
Fixer |
celeron55: default config with vrange 240 |
| 15:02 |
celeron55 |
it seems similar to what i saw |
| 15:03 |
celeron55 |
are you able to test a dynamic liquid scenario? |
| 15:04 |
celeron55 |
i guess make two copies of a world and take a screenshot after the same amount of seconds or something |
| 15:06 |
Fixer |
another try here https://imgur.com/a/QBNW4 |
| 15:08 |
celeron55 |
that one seems to be first with PR, then no PR |
| 15:10 |
Fixer |
smaller mainloop other is with pr |
| 15:11 |
celeron55 |
the effect isn't as large as i hoped but it clearly is there |
| 15:14 |
celeron55 |
what this means is that any optimization that can be done to Client::addUpdateMeshTaskWithEdge will help |
| 15:15 |
Fixer |
celeron55: https://imgur.com/a/7ckbw |
| 15:15 |
Fixer |
dynamic liquid |
| 15:15 |
Fixer |
close enough |
| 15:16 |
Fixer |
made screenshot too fast and missed third spike... |
| 15:18 |
celeron55 |
this difference is very clear |
| 15:19 |
benrob0329 |
http://bash.org/?870063 |
| 15:19 |
benrob0329 |
This is one of the greatest things I've ever read. |
| 15:21 |
Fixer |
celeron55: when i tested it with 6 or 18 neighb-s i had graphical errors, like that mapblock light edges and broken flowing water |
| 15:22 |
Krock |
oh cool! bash is online again. Last time I checked it was down |
| 15:22 |
nerzhul |
i prefer zsh |
| 15:23 |
benrob0329 |
someone post that |
| 15:24 |
Jordach |
http://bash.org/?962787 me_irl |
| 15:25 |
celeron55 |
Fixer: yeah i'm not proposing merging of the PR, the PR just happens to have similar performance implications as what i'm thinking could be done without errors |
| 15:25 |
celeron55 |
not nearly as easily as changing a number though |
| 15:26 |
Fixer |
too bad it is just one sort of stutter |
| 15:29 |
celeron55 |
the only way to easily fix most stutters is to limit processing like mesh_generation_interval does, which limits map loading and update speed |
| 15:29 |
Fixer |
yes |
| 15:29 |
Fixer |
and it helps a lot |
| 15:30 |
Fixer |
hugely helps |
| 15:30 |
celeron55 |
well it's like telling a man with a broken leg to not walk |
| 15:31 |
celeron55 |
can you point out other stutters than this one, and the one that happens on places like VE-S's spawn with a lot of interactive nodes? |
| 15:33 |
celeron55 |
the 1-2 second spikes were mentioned but it wasn't clear in which situation they happen |
| 15:34 |
Fixer |
stutters i seen: 1) meshgen (most frequent and annoying) 2) due to metadata change in mesecons/technic/whatever? (periodical) 3) big freezes during loading kaeza signs (catched on ve-s) 4) other stutters that show up in mainloop_other (including in singleplayer) 5) stutter when using https://github.com/minetest-mods/dynamic_liquid/ |
| 15:34 |
celeron55 |
is 1 the same as 5? |
| 15:34 |
Fixer |
celeron55: 1-2 sec freezes caused by loading kaeza signs on ve-s thats like 99.9% sure, since i seen exact moment of stutter and text appearing on signs |
| 15:34 |
|
lumidify joined #minetest-hub |
| 15:35 |
Fixer |
celeron55: dynamic liquid causes two stutters: small draw one and big nondraw |
| 15:35 |
Fixer |
kaeza sign load causes huge nondraw freeze |
| 15:35 |
Fixer |
in mainloop_other |
| 15:36 |
Fixer |
5 is just a combination of various stutters %) |
| 15:36 |
Fixer |
tbh |
| 15:37 |
celeron55 |
so is 1 draw or non-draw? |
| 15:37 |
Fixer |
celeron55: dynamic liquids is both |
| 15:38 |
Fixer |
celeron55: kaeza signs is nondraw |
| 15:38 |
Fixer |
nondraw = in mainloop_other |
| 15:38 |
celeron55 |
but "1) meshgen (most frequent and annoying)" |
| 15:39 |
Fixer |
in general play in singleplayer/multiplayer like 95% of stutter is mesh updates |
| 15:39 |
Fixer |
smth like that |
| 15:40 |
celeron55 |
but do you see it in mainloop_other or mainloop_draw? |
| 15:40 |
Fixer |
for what case? |
| 15:40 |
Fixer |
dynamic liquid? |
| 15:40 |
Fixer |
or general play? |
| 15:41 |
Fixer |
for general play most stutters occur in mainloop_draw |
| 15:41 |
celeron55 |
well, a stutter can't change from one to another :P |
| 15:42 |
Fixer |
but you have many of them in one game, due to usual mesh updating and due to other causes |
| 15:43 |
celeron55 |
tough luck; we kind of need to be able to separate them anyway, lol |
| 15:43 |
Fixer |
in singleplayer with 15 ms i noticed this: |
| 15:44 |
Fixer |
1) mesh update stutter is reduced to very minimum, comfy to play |
| 15:44 |
Fixer |
2) no mesh updates - yet 0.03 sec spike in mainloop_other arrives... |
| 15:44 |
Fixer |
or even 0.04 |
| 15:44 |
Fixer |
during walking |
| 15:44 |
Fixer |
hmm |
| 15:45 |
sofar |
have you eliminated other sources of stutter? |
| 15:45 |
sofar |
e.g. download local map, run around in that? |
| 15:45 |
Fixer |
mesh_generation_interval = 15 is silver bullet for me, it fixes vanilla singleplayer and modded multiplayer more or less (except inhuman vanessa server spawns) |
| 15:46 |
Fixer |
celeron55: there is more stuttering in singleplayer than in multiplayer for some reason |
| 15:47 |
Fixer |
celeron55: if more or less vanilla server |
| 15:48 |
Fixer |
it seems |
| 15:50 |
|
nerzhul joined #minetest-hub |
| 15:53 |
celeron55 |
Fixer: that's because most of the stutters happen at the code that receives mapblocks from the server and a singleplayer server can send stuff faster than a dedicated server |
| 15:54 |
celeron55 |
Fixer: also because most of the stutters happen at the code that receives mapblocks from the server (same reason), mesh_generation_interval doesn't control the rate properly because it limits mesh generation, not directly the mapblock receive rate that you actually want to control for the purpose |
| 15:55 |
Fixer |
not a problem, i've used 15ms interval and it worked good on sp/mp/vanessa |
| 15:56 |
Fixer |
on my pc* |
| 15:56 |
celeron55 |
it seems dynamic liquid is mainly the exact same stutter but so much worse mesh_generation_interval is unable to limit it |
| 15:57 |
celeron55 |
(as it controls the wrong thing) |
| 16:00 |
Fixer |
no wait, dynamic liquid has small mesh update stutter and huge different stutter |
| 16:03 |
Fixer |
or whatever |
| 16:03 |
Fixer |
fuck it |
| 16:04 |
celeron55 |
most of the spike that you showed earlier today was caused by MeshMakeData::fill |
| 16:04 |
celeron55 |
well, in all of the three screenshots that were of dynamic liquid |
| 16:05 |
Fixer |
oh that, yeah |
| 16:05 |
Fixer |
but why it shows up in _other? |
| 16:09 |
celeron55 |
it's the main thread filling in VoxelManipulators to be handed to the mesh generator, as the mesh generator can't directly read the map |
| 16:09 |
|
mogeid joined #minetest-hub |
| 16:09 |
|
paramat joined #minetest-hub |
| 16:10 |
celeron55 |
that's how the system works |
| 16:12 |
celeron55 |
PR 5239 tries to make it fill in less stuff, and thus stutter less, but it turned out it needs all the stuff |
| 16:17 |
celeron55 |
i think this is the most important one to somehow optimize |
| 16:26 |
|
lumidify joined #minetest-hub |
| 16:28 |
Fixer |
celeron55: but what about kaeza sign/entity multisecond freezes on ve-s? |
| 16:38 |
celeron55 |
it's something completely different |
| 16:38 |
celeron55 |
where's the source code for those? |
| 16:38 |
celeron55 |
is it too complex for a quick read? |
| 16:46 |
nore |
celeron55: my perf tests show that the problem is the texture creation that takes a lot of CPU |
| 16:47 |
nore |
I don't remember where the code for that is, though |
| 16:47 |
celeron55 |
that's a rather obvious case then |
| 16:48 |
nore |
well, I guess texture creation could be optimized a bit |
| 16:48 |
nore |
but having something more efficient for these signs & others is definitely needed |
| 16:50 |
celeron55 |
looks like i'm able to take away 50% of processing from the main thread very crudely by copying mapblock contents into MeshMakeData and creating the VM later in the mesh generator thread |
| 16:51 |
nore |
there https://github.com/minetest/minetest/blob/master/src/client/tile.cpp#L594 |
| 16:52 |
nore |
rather that https://github.com/minetest/minetest/blob/master/src/client/tile.cpp#L1014 |
| 16:52 |
celeron55 |
i mean, just allocating and memcpying each mapblock's data member into a 26+1 long std::vector<MapNode*> m_mapblock_data; and then doing what MeshMakeData::fill does in the mesh generator thread; it's like 50% more processing overall, but 50% less processing in the main thread :P |
| 16:52 |
celeron55 |
i'm going to try something fancier but i guess this is one option if nothing else works |
| 16:57 |
Fixer |
celeron55: https://github.com/minetest-mods/signs_lib |
| 16:59 |
Fixer |
just 1163 lines |
| 16:59 |
Fixer |
:trollface: |
| 16:59 |
sofar |
celeron55: what are the 3 most used struct/classes in minetest when rendering? |
| 17:00 |
sofar |
just gonna throw pahole at them and see if they're bad or good |
| 17:01 |
|
lumidify joined #minetest-hub |
| 17:01 |
nore |
about signs: I think this block of code is the one that should be optimized https://github.com/minetest/minetest/blob/master/src/client/tile.cpp#L1342 (since signs use [combine with a massive amount of textures) |
| 17:01 |
celeron55 |
sofar: i don't know, maybe some irrlicht classes |
| 17:02 |
sfan5 |
nore: wrong approach |
| 17:02 |
sfan5 |
we should just implement a decent way to make signs |
| 17:02 |
nore |
sfan5: yes |
| 17:02 |
sfan5 |
also IIRC using [combine a lot is guaranteed to "leak" memory |
| 17:02 |
sfan5 |
as each single step to the final tex is cached |
| 17:03 |
nore |
hmmm, isn't that the advantage of [combine over ^ though? |
| 17:03 |
sfan5 |
no |
| 17:04 |
sofar |
#1367 |
| 17:04 |
sfan5 |
the advantage of [combine over ^ is that you can combine multiple images at once and set their positions |
| 17:04 |
nore |
yes |
| 17:04 |
nore |
so you don't get the intermediate combinations cached |
| 17:04 |
sfan5 |
also what i'm referring to is foo.png^[combine:<...>^[combine:<....>^[combine:<...> |
| 17:04 |
sfan5 |
foo.png^[combine.<... lots of stuff ...> is fine |
| 17:05 |
nore |
yeah, the first is bad, agreed |
| 17:07 |
celeron55 |
i think there's no reason not to optimize [combine, assuming there's a way to optimize it |
| 17:09 |
nerzhul |
i think i should refactor client event structure, if i get time, before release to reduce memory usage on events (using POO) |
| 17:09 |
celeron55 |
but it doesn't really do anything more than it has to |
| 17:09 |
nerzhul |
union = use the largest member memory size |
| 17:12 |
nerzhul |
also client events are handled using copy, i don't know if it's heavily used client side, but it can make a big memory penalty when many events are in queue |
| 17:17 |
celeron55 |
(maybe some of this belongs to #-dev? 8)) |
| 17:18 |
sofar |
damn all this offtopic chat...! |
| 17:19 |
celeron55 |
maybe modders will learn C++ if we talk enough about it |
| 17:22 |
Fixer |
+1 for signs |
| 17:28 |
sofar |
I had high hope that a guy like juhdanad or lhofhansl would have come up with code for #1367 already |
| 17:28 |
sofar |
I think my API and method would have worked well and be simple to add |
| 17:29 |
sofar |
now I end up writing my own sign mods using entities :( |
| 17:32 |
nerzhul |
+1 for C++ |
| 17:33 |
nore |
well actually dynamic node textures + a "text" texture modifier that generates text from a charmap image & a string would do that very well |
| 17:34 |
nore |
the second one shouldn't be too difficult to do and will probably save a lot when generating the texture |
| 17:35 |
nore |
while the former will avoid having so many entities but is more difficult, you need to convince juhdanad to do that :) |
| 17:39 |
paramat |
using POO? |
| 17:39 |
nore |
paramat: OOP |
| 17:39 |
nore |
POO is the French name :) |
| 17:41 |
Krock |
poo :3 |
| 17:45 |
CWz |
Whinne la merde |
| 18:15 |
paramat |
ahh object orient |
| 18:23 |
Fixer |
celeron55: there is also one very weird fps drop problem i will look into with this enhanced profiler, for some reason fps drops a lot to some value and after some time goes back to normal |
| 18:23 |
Fixer |
very strange and random bug i found while playing on hometown server |
| 18:23 |
Fixer |
maybe f5 shows up smth useful |
| 18:29 |
celeron55 |
checking the GPU and CPU MHz during that would be useful in case it's a throttling event of some kind |
| 18:30 |
* benrob0329 |
returns |
| 18:42 |
|
rubenwardy joined #minetest-hub |
| 18:42 |
Fixer |
celeron55: if you wondering, my amd/ati hd6870 sometimes drops frequences for very short instant (maybe second or less) during minetest play, observed this in 0.4.13 or somewhere |
| 19:11 |
|
rubenwardy joined #minetest-hub |
| 19:18 |
|
rubenwardy joined #minetest-hub |
| 19:28 |
Hijiri |
minetest must be so efficient that the card is tricked into thinking it needs less power |
| 19:29 |
Fixer |
gpu-z said videocard utilisation was at 20-50%, no idea how it measures it |
| 19:36 |
Krock |
busy vs idle in a specified timespan, and then the average of it, perhaps? |
| 19:55 |
|
tenplus1 joined #minetest-hub |
| 19:56 |
tenplus1 |
hi folks |
| 19:56 |
Shara |
Hi ten :P |
| 19:56 |
tenplus1 |
hi shara |
| 19:57 |
tenplus1 |
spent the last few hours setting up a bluetooth pedal on ipad... *shudder* |
| 19:57 |
Shara |
Ekk |
| 19:58 |
Shara |
I've been fussing with mods a lot |
| 19:58 |
tenplus1 |
what ya working on ? |
| 19:58 |
Shara |
SOmeone opened an issue on my fire mod, but figured it out already |
| 19:58 |
tenplus1 |
I tested the slab opening door bug that's in latest dev... thankfully it doesnt happen with doors/stairs redo :P |
| 19:58 |
sofar |
that bug is in builtin I believe |
| 19:59 |
Shara |
Hi sofar |
| 19:59 |
Jordach |
meow |
| 19:59 |
tenplus1 |
hi sofar |
| 19:59 |
tenplus1 |
hi Jordach |
| 19:59 |
sofar |
but, if you're not using the fine_pointed API you're safe |
| 19:59 |
Shara |
meow Jordach |
| 19:59 |
Krock |
tenplus1, because your redo doesn't use the new builtin function yes |
| 19:59 |
Krock |
*yet |
| 19:59 |
tenplus1 |
hi Krock, exactly :DDD |
| 19:59 |
Krock |
damn it sofar. Always these ninjas |
| 19:59 |
tenplus1 |
keepin it simple |
| 19:59 |
* sofar |
swooshes away behind a puff of smoke, coughing |
| 20:00 |
tenplus1 |
I bet that smoke is cms particles :PPP |
| 20:00 |
sofar |
right, so nobody else sees them, lmao |
| 20:00 |
tenplus1 |
ehehe |
| 20:00 |
Shara |
sofar: thanks for the skybox links yesterday. Found at least one there I'm going to use :) |
| 20:01 |
tenplus1 |
been checking those out, they look so beautiful... does it lag changing skybox on servers tho ? |
| 20:01 |
Shara |
This one: http://rc.minetest.tv/wp-content/uploads/2017/04/thebox_sky_night.png |
| 20:01 |
sofar |
no |
| 20:01 |
sofar |
it's just a tiny packet to the client |
| 20:01 |
tenplus1 |
w00t!... it adds a lot to the game having beautiful skies :P |
| 20:02 |
sofar |
of course, textures do need to be loaded on startup |
| 20:02 |
tenplus1 |
how big did you get the images down to ? |
| 20:02 |
Shara |
Still considering this one: http://rc.minetest.tv/wp-content/uploads/2017/04/thebox_sky_desert_mountains.png |
| 20:02 |
sofar |
17mb for all 6 combined |
| 20:02 |
tenplus1 |
oof |
| 20:02 |
sofar |
the largest set is 5mb |
| 20:02 |
Shara |
That's pretty big still |
| 20:02 |
sofar |
the smallest one is ... *checks* |
| 20:03 |
tenplus1 |
will it replace mt's own sunset/sunrise gradients by using them ? |
| 20:03 |
sofar |
1.1M total |
| 20:03 |
sofar |
yes, you lose *all* sky elements entirely |
| 20:03 |
tenplus1 |
aw |
| 20:03 |
Jordach |
whatcha doin, sofar |
| 20:03 |
sofar |
no moon, no sun, no clouds |
| 20:03 |
Shara |
I got the night sky one there too... about 450kb |
| 20:04 |
Shara |
to* |
| 20:04 |
* Jordach |
coughs |
| 20:04 |
Jordach |
something something stellar api |
| 20:04 |
Jordach |
something something transparent skyboxes |
| 20:04 |
tenplus1 |
api's are fun |
| 20:04 |
* nore |
wants |
| 20:04 |
tenplus1 |
hi nore |
| 20:04 |
nore |
hey all btw :) |
| 20:04 |
Jordach |
or even just allow skyboxes to be paletted by the dynamic colours |
| 20:04 |
Shara |
Hi nore :) |
| 20:04 |
sofar |
I've been doing OSS too long, I know that small steps are needed to make big changes |
| 20:04 |
Jordach |
sofar, Y O L O |
| 20:04 |
tenplus1 |
heh |
| 20:05 |
sofar |
yes, but, in my lifetime I aim to achieve major differences by making small contributions in the right way over time |
| 20:05 |
sofar |
not "go for bust" and achieve nothing |
| 20:05 |
tenplus1 |
+1 for small changes... it all adds up |
| 20:06 |
Hijiri |
if you're dictator you can freeze development for your totally great overhaul change |
| 20:06 |
tenplus1 |
hi Hijiri |
| 20:06 |
Hijiri |
hi |
| 20:06 |
* tenplus1 |
wonders if Kim Jong Un has his own minetest clone ?!?! o.O |
| 20:07 |
Hijiri |
I joined this channel so I would have more irc logs to burn time on reading |
| 20:07 |
Krock |
Hijiri, you should consider burning time by submitting features and bugfixes for Minetest :P |
| 20:08 |
sofar |
any *serious* server operators online willing to discuss a proposal? |
| 20:08 |
Hijiri |
ah yeah I've been pretty inactive, even in modding |
| 20:09 |
Shara |
sofar: define 'serious' |
| 20:09 |
sofar |
willing to pay 1$ to make their servers load faster for players. |
| 20:09 |
Krock |
#define serious "SELECT * FROM users WHERE server_skills > -1" |
| 20:10 |
* tenplus1 |
ran ALL textures through 'optipng -o9 -strip all *.png' and it definitely loads faster :D |
| 20:10 |
Shara |
did same and moved to remote media and... yea. Been fine since |
| 20:11 |
sofar |
how about a shared CDN for *all* media from many servers |
| 20:11 |
sofar |
automatically updated regularly |
| 20:11 |
sofar |
hosted all across the world on various professional CDNs |
| 20:11 |
Shara |
I just use what TPS has for it |
| 20:11 |
sofar |
so they don't even hit *your* media server |
| 20:11 |
tenplus1 |
if sound sets could be loaded locally like textures it would save a lot of server load |
| 20:11 |
Krock |
tenplus1, storage-wise there's no change due to sector size but there will be indeed less data to send over the pipe |
| 20:11 |
Shara |
So I don't use my own media server. |
| 20:12 |
sofar |
yes but how does TPS get *your* textures? |
| 20:12 |
Shara |
I have access. |
| 20:12 |
sofar |
who else does? |
| 20:12 |
Shara |
RobbieF |
| 20:12 |
Shara |
Since he owns TPS. |
| 20:12 |
tenplus1 |
tps skyblock looks real nice with john smith texture pack :D |
| 20:12 |
sofar |
so what if I want to use it? |
| 20:13 |
sofar |
or *randomjoe* |
| 20:13 |
sofar |
it's costing robbief now (I'm sure he pays for it some way) |
| 20:13 |
sofar |
and when he leaves, it's gone? |
| 20:13 |
sofar |
besides he doesn't have a CDN |
| 20:14 |
sofar |
just just has *a* media server |
| 20:14 |
Shara |
Since I'm on the TPS team and have been working closely with them for a very long time now, I'm not too worried about it. |
| 20:14 |
sofar |
a CDN would be a lot faster for everyone |
| 20:14 |
sofar |
and probably cheaper in the end |
| 20:14 |
Shara |
Pretty sure it is actually, but can't check things right now |
| 20:15 |
sofar |
plus we can open it for everyone |
| 20:15 |
sofar |
accelerating everyone's servers |
| 20:16 |
tenplus1 |
question... do clients load all textures from a server or does it already use default textures (not texture pack) ? |
| 20:17 |
sofar |
good question |
| 20:17 |
tenplus1 |
I'd rather not load default textures from a server if they already exist on hdd |
| 20:17 |
tenplus1 |
*cough* ssd |
| 20:17 |
Jordach |
isn;t that the point of cache |
| 20:17 |
Jordach |
tenplus? |
| 20:17 |
sofar |
I'm assuming it doesn't load unneeded textures |
| 20:18 |
tenplus1 |
my cache folder is always empty... nothing is saved there |
| 20:18 |
sofar |
that's what the media cache is for |
| 20:18 |
sofar |
~/.cache/minetest/media |
| 20:18 |
sofar |
350M+ in there for me |
| 20:18 |
tenplus1 |
.minetest/cache <-- empty |
| 20:18 |
Shara |
Mine's always got stuff |
| 20:18 |
sofar |
that's old, no longer used |
| 20:19 |
sofar |
the .minetest/cache folder is not the right location |
| 20:19 |
tenplus1 |
ooh |
| 20:19 |
tenplus1 |
got 355mb... ouch! |
| 20:19 |
tenplus1 |
didnt realise it changed location |
| 20:21 |
sofar |
oh |
| 20:21 |
sofar |
I know |
| 20:21 |
sofar |
robbief uses cdnjs |
| 20:23 |
Shara |
My creative used to suffer if I had many connections at once, up until I moved stuff |
| 20:23 |
Shara |
so it definitely helps |
| 20:24 |
Shara |
but reducing media size helped a lot too |
| 20:25 |
sofar |
so anyway, I'm thinking we should get a collective CDN for everyone who runs a server |
| 20:25 |
Shara |
most slow loading servers I encounter have a ridiculous number of mods |
| 20:25 |
sofar |
and allow server admins to upload media for inclusion |
| 20:25 |
tenplus1 |
true, they add all sorts in the hope of making a better server, not realising it slows things down |
| 20:26 |
Jordach |
use github as a media server :^) </insanity> |
| 20:26 |
sofar |
github isn't a CDN |
| 20:28 |
|
rubenwardy joined #minetest-hub |
| 20:28 |
tenplus1 |
hi rubenwardy |
| 20:29 |
benrob0329 |
Hi rubenwardy, tenplus1, Jordach, sofar, Shara, Krock |
| 20:29 |
Shara |
Hi benrob0329 |
| 20:29 |
Krock |
hi benrob0329 |
| 20:30 |
Calinou |
hi benrob0329 |
| 20:30 |
benrob0329 |
Hi Calinou |
| 20:31 |
tenplus1 |
hi ben |
| 20:36 |
|
rubenwardy joined #minetest-hub |
| 20:41 |
sofar |
I'm fairly sure I could build a service that allows minetest server operators to have a professional CDN for all their media |
| 20:41 |
sofar |
and even auto-update it regularly |
| 20:41 |
* tenplus1 |
has an old Amiga 500 he uses as a media server :PPPP |
| 20:41 |
sofar |
giving everyone the fastest possible login times |
| 20:41 |
sofar |
tenplus1: but the guy in australia gets it from your server |
| 20:41 |
sofar |
the idea of a CDN is that it's in australia already |
| 20:42 |
tenplus1 |
:P |
| 20:42 |
sofar |
wherever the player is |
| 20:42 |
sofar |
not where you are |
| 20:42 |
sofar |
all server owners would have to do is |
| 20:42 |
sofar |
set a media url to the CDN |
| 20:42 |
sofar |
and register their server with the bit that syncs their game server with it |
| 20:44 |
Fixer |
current mood: http://scontent-sea1-1.cdninstagram.com/t51.2885-15/s480x480/e35/12357700_464469330405959_1963486238_n.jpg?ig_cache_key=MTEzNzMwMzY5MjA2NDM3NjIzNA%3D%3D.2 |
| 20:47 |
tenplus1 |
when mt caches media, does it unpack images or leave them as compressed png ? |
| 20:47 |
|
rubenwardy joined #minetest-hub |
| 20:48 |
paramat |
https://github.com/paramat/snowdrift is now a snowfall / rainfall weather mod with sound and overcast cloud. matched to biomes of all non-mgv6 mapgens |
| 20:49 |
Shara |
paramat: blue or grey rain now? :P |
| 20:49 |
tenplus1 |
nite all :P |
| 20:49 |
|
tenplus1 left #minetest-hub |
| 20:51 |
|
nerzhul joined #minetest-hub |
| 20:53 |
Fixer |
nice |
| 20:53 |
Fixer |
will try |
| 20:57 |
paramat |
very pale blue, textures may be improved |
| 21:00 |
Shara |
paramat: hmm, might try to use it for something |
| 21:01 |
sofar |
paramat: could look nice with one of the dark skyboxes |
| 21:01 |
Shara |
sofar: you're reading my mind |
| 21:11 |
Fixer |
paramat: very few particles |
| 21:16 |
paramat |
only a plain colour skybox can smoothly change brightness across day-nght transitions |
| 21:17 |
nore |
paramat: semi-transparent skyboxes + background |
| 21:17 |
paramat |
that's the special feature |
| 21:17 |
|
rubenwardy joined #minetest-hub |
| 21:17 |
nore |
well that would make smooth changes |
| 21:18 |
paramat |
skybox has an alpha parameter but in testing it doesn't make the plain colour translucent unfortunately |
| 21:19 |
Shara |
I wasn't even able to vary colour on default skybox while keeping sun/moon when I checked before. |
| 21:20 |
paramat |
i wouldn't use those real-life photo skyboxes anyway, they are beautiful sky photos yes, but look wrong in MT |
| 21:20 |
Shara |
depends what you're aiming for |
| 21:21 |
paramat |
maybe with HD photo-realistic textures |
| 21:21 |
benrob0329 |
Just got done visiting thr Creation |
| 21:21 |
benrob0329 |
*Creation Museum |
| 21:22 |
benrob0329 |
Highly recommended, including the planetarium |
| 21:24 |
Fixer |
paramat: if under tree there is no precip rendered at all |
| 21:28 |
paramat |
hehe |
| 21:28 |
Fixer |
paramat: 16/32 particles is a joke |
| 21:28 |
paramat |
the big problem with weather mods is, how to detect when outside? |
| 21:29 |
|
mogeid joined #minetest-hub |
| 21:29 |
paramat |
this samples light level, 15 = outside |
| 21:29 |
paramat |
with the funny result that it stops raining when you go inside |
| 21:30 |
sofar |
nore: we just need to write a 'transition' api |
| 21:30 |
benrob0329 |
But it should rain out the window |
| 21:30 |
benrob0329 |
Perhaps if rain was per mapblock |
| 21:30 |
nore |
sofar: hmmm |
| 21:30 |
paramat |
MT particles are not very lightweight, so number of particles is set to a minimum by default, you can adjust that |
| 21:31 |
nore |
I was thinking maybe about allowing to set the sky color texture as well |
| 21:31 |
nore |
(the texture that maps time to color) |
| 21:31 |
Fixer |
paramat: tried 64 particles, somewhat better but with snow fps goes down to 55... |
| 21:32 |
benrob0329 |
Wait, what if the airblock was just modified? |
| 21:32 |
paramat |
yeah ideally collision detection should be on, then maybe sample light high above the player (above the roof) |
| 21:33 |
paramat |
now you know why i minimised number of particles :] |
| 21:33 |
nerzhul |
for weather part, don't do it server side, it should be fully implemeted client side, and best: use shaders and detect if a player is outside or not |
| 21:33 |
benrob0329 |
If light level == 15, and raining == true, texture = raining_animated |
| 21:35 |
paramat |
yeah i know CSM will be good for weather, but i'm working with current stable MT abilities, and my mods are always written for last stable |
| 21:35 |
Fixer |
https://i.imgur.com/FgCRjuI.jpg game from 2001 can into particles hitting fps cap (30 fps), minetest in 2017 on core i3 can't render damn 64 particles without huge penalty |
| 21:35 |
paramat |
i will never rely on shaders, too much performance drain, many turn them off completely |
| 21:36 |
benrob0329 |
MT needs help from experienced OGL programmers |
| 21:36 |
paramat |
yes our particles need work, and irrlicht particles are needed |
| 21:36 |
benrob0329 |
Shaders could be just as fast as fixed, if they were optimized |
| 21:37 |
Fixer |
https://i.imgur.com/SXv3kcj.jpg year 2001 |
| 21:38 |
* benrob0329 |
mumbles about asking the Antarctica devs for help |
| 21:38 |
Fixer |
and i played this 16 years ago on that hardware |
| 21:38 |
Fixer |
900mhz cpu and gf2mx |
| 21:39 |
benrob0329 |
Heh, Source Engine particles arw better |
| 21:39 |
Fixer |
this screenshot alone has _hundreds_ of particles |
| 21:41 |
Fixer |
close to 300 |
| 21:42 |
Fixer |
around 280 for rain |
| 21:47 |
Fixer |
"How to run Microsoft Edge on Windows 7" |
| 21:47 |
benrob0329 |
*facedesk* |
| 21:52 |
Fixer |
"RebootBlocker is a free program for Windows 10 that prevents automatic reboots after the installation of updates on Windows 10 systems." |
| 21:53 |
Fixer |
you gotta be kidding me /o |
| 21:53 |
benrob0329 |
Heh |
| 22:04 |
Fixer |
reminder https://pbs.twimg.com/media/C9WP6YkU0AEGXsl.jpg:large |
| 22:10 |
|
Fixer joined #minetest-hub |
| 22:24 |
paramat |
forum spammer https://forum.minetest.net/memberlist.php?mode=viewprofile&u=21013 VanessaE Calinou |
| 22:29 |
benrob0329 |
So many people complaining about the name.. |
| 22:29 |
benrob0329 |
I don't think they realise how difficult and painful a name change is |
| 22:42 |
Jordach |
>Jabber:asdasdasda.fasfasfdasdasd yandex.ru |
| 22:42 |
Jordach |
top keks |
| 23:08 |
|
octacian_ joined #minetest-hub |
| 23:14 |
Fixer |
lol |
| 23:19 |
Calinou |
paramat: done |
| 23:20 |
Calinou |
benrob0329: trying this out btw, https://doomwiki.org/wiki/Knee-Deep_in_ZDoom |
| 23:20 |
Calinou |
they actually put… a trailer in the game |
| 23:20 |
Calinou |
quite impressive, I didn't know this was possible |
| 23:21 |
Calinou |
dynamic skybox, slopes, etc |
| 23:21 |
benrob0329 |
Calinou: interesting |
| 23:21 |
Calinou |
seems to work ok in Zandronum |
| 23:21 |
Calinou |
(it's a multiplayer-oriented ZDoom fork) |
| 23:21 |
Calinou |
too lazy to install GZDoom :P |
| 23:22 |
Calinou |
there's also security cameras à la Duke Nukem 3D, nice |
| 23:27 |
Fixer |
paramat: why rain drops are so slow? |
| 23:27 |
Fixer |
paramat: increase their falling speed a bit |
| 23:27 |
|
wayward1 joined #minetest-hub |
| 23:27 |
Fixer |
paramat: no sound fading :( |
| 23:28 |
Fixer |
paramat: particles do not respect your move, when i move towards them, there is no drift to me |
| 23:29 |
|
wayward1 joined #minetest-hub |
| 23:29 |
|
wayward1 joined #minetest-hub |
| 23:29 |
Fixer |
paramat: are there weather variability or it depends on biomes only? |
| 23:29 |
Fixer |
paramat: snow/rain particles look a bit large |
| 23:29 |
Fixer |
paramat: especially snow |
| 23:29 |
paramat |
thanks |
| 23:30 |
paramat |
particles are relative to the world not to the player |
| 23:31 |
Fixer |
right, but then if i move they should go closer to me, yet they are relative to player it feels |
| 23:31 |
Fixer |
maybe i'm wrong |
| 23:31 |
paramat |
they do move towards you if you move forwards |
| 23:31 |
|
wayward1 joined #minetest-hub |
| 23:31 |
paramat |
raindrop speed is realistic but looks slow for some reason, but 10 might be better |
| 23:31 |
|
wayward1 joined #minetest-hub |
| 23:31 |
|
wayward1 joined #minetest-hub |
| 23:32 |
paramat |
sound fading may be possible, i might try |
| 23:32 |
Fixer |
not related https://i.imgur.com/ZtniAtX.jpg |
| 23:33 |
paramat |
precipitation does start and stop with time, as well as being affected by temp and humidity |
| 23:34 |
paramat |
particle pixels are matched to world pixels, so to have an interesting structure snowflakes have to be large |
| 23:37 |
Fixer |
if i increase velocity to -32 i can see they come in batches |
| 23:37 |
Fixer |
for rain* |
| 23:38 |
Fixer |
paramat: precipitation for the poor |
| 23:40 |
paramat |
yes due to the 0.5s globalstep cycle |
| 23:40 |
paramat |
you could reduce the cycle time instead |
| 23:40 |
paramat |
GSCYCLE |
| 23:40 |
paramat |
-10 is a rough max for real rain |
| 23:41 |
Fixer |
eh... waiting for CSM weather with lots of particles :) |
| 23:41 |
paramat |
particles need work first |
| 23:42 |
Jordach |
paramat, is there an engine call for sky_visible(pos) |
| 23:42 |
benrob0329 |
Particles_redo >:-) |
| 23:43 |
Fixer |
paramat: seeing 32 slow rain particles makes me very depressing since no good rains IRL |
| 23:46 |
|
wayward1 joined #minetest-hub |
| 23:47 |
|
wayward1 joined #minetest-hub |
| 23:47 |
|
wayward1 joined #minetest-hub |
| 23:50 |
Jordach |
paramat, >local outside = minetest.get_node_light(ppos, 0.5) == 15 |
| 23:50 |
Jordach |
*nice* |
| 23:50 |
* Jordach |
figured out a possible way of safe spawning |
| 23:51 |
Jordach |
>random x,y position |
| 23:51 |
Jordach |
>send that with +-32 on all pos.x/y/z |
| 23:51 |
Jordach |
>use minetest.emerge_area() |
| 23:51 |
Jordach |
>wait a few seconds |
| 23:51 |
Jordach |
>then do checks at the center area |
| 23:53 |
paramat |
there's no sky_visible API, but light = 15 means under open sky |
