| Time |
Nick |
Message |
| 01:06 |
|
VanessaE joined #minetest-dev |
| 01:36 |
|
cib0 joined #minetest-dev |
| 01:56 |
|
paramat joined #minetest-dev |
| 02:09 |
|
cib0 joined #minetest-dev |
| 02:21 |
|
paramat left #minetest-dev |
| 02:27 |
ShadowNinja |
celeron55: I discussed it with several other devs, and you only review PRs very rarely. |
| 02:27 |
ShadowNinja |
hmmmm: What exactly is the bug? |
| 02:27 |
ShadowNinja |
infostream isn't working somehow? |
| 02:28 |
|
thatgraemeguy joined #minetest-dev |
| 02:28 |
|
thatgraemeguy joined #minetest-dev |
| 02:29 |
ShadowNinja |
hmmmm: Oh, BTW, I thought of a nice solution to your categories idea that doesn't require massive changes. |
| 02:30 |
ShadowNinja |
You could use a scoped object. |
| 02:31 |
ShadowNinja |
Eg: server::step() { LogScope("ServerStep"); /* Any stream writes will use the provided category name unless you enter another log scope */ } |
| 02:32 |
ShadowNinja |
This should be very helpfull for the debugging case that you had in mind, since you just have to add that line to the top of each function/ |
| 02:33 |
ShadowNinja |
(but actually assigning it to a variable :-P) |
| 02:36 |
ShadowNinja |
Oh, BTW, also note that kwolekr made some modifications to that PR, and est did some after for his console patch, so it's not necessarily my bug. |
| 02:44 |
|
dandelion joined #minetest-dev |
| 03:21 |
|
VanessaE joined #minetest-dev |
| 03:33 |
|
crazyR_ joined #minetest-dev |
| 04:06 |
|
dandelion left #minetest-dev |
| 04:26 |
|
paramat joined #minetest-dev |
| 04:29 |
|
Supertanker2 joined #minetest-dev |
| 04:49 |
paramat |
kwolekr == hmmmmm |
| 04:51 |
* VanessaE |
wishes hmmmm would just go by kwoelkr here too :) |
| 05:09 |
paramat |
hi hmmmm i'd like to merge mgflat soonish if you're able to check it https://github.com/minetest/minetest/pull/3313 i'm currently working on adding a choice of 4 formulas to mgfractal |
| 05:34 |
|
Hunterz joined #minetest-dev |
| 05:41 |
|
paramat left #minetest-dev |
| 06:20 |
|
paramat joined #minetest-dev |
| 06:33 |
paramat |
i'll merge mgflat in 3 hrs, it was reviewed earlier and i trust myself with the recent changes |
| 06:38 |
|
Hunterz joined #minetest-dev |
| 06:59 |
|
jin_xi joined #minetest-dev |
| 07:04 |
|
Player2 joined #minetest-dev |
| 07:23 |
|
Supertanker2 joined #minetest-dev |
| 07:30 |
celeron55 |
ShadowNinja: it turned out that it probably is not the fault of your code; however, it still is not working |
| 07:30 |
celeron55 |
ShadowNinja: i have no idea why; i am even suspecting that libstdc++ 4.9...5.1 is broken |
| 07:55 |
|
paramat left #minetest-dev |
| 08:04 |
hmmmm |
celeron, maybe it would help if you disassembled the function at that point |
| 08:05 |
hmmmm |
ShadowNinja: the scoped name thing sounds good but you're making the same god damn mistake that sapier, nerzhul, and est all make with temporary objects and their lifetimes |
| 08:05 |
hmmmm |
please PLEASE don't do this for something important and subtle like MutexAutoLock |
| 08:05 |
hmmmm |
I know you like to generate enormous commits where it's easy for reviewers to miss things like that |
| 08:07 |
hmmmm |
paramat: I guess it looks good at first glance |
| 08:37 |
celeron55 |
hmmmm: it might help but i have to use my day for developing this actual feature if i am to ever get it done |
| 08:37 |
hmmmm |
you shouldn't rush as much |
| 08:38 |
celeron55 |
this is not about rushing; this is about focusing |
| 08:38 |
|
Gael-de-Sailly joined #minetest-dev |
| 08:40 |
celeron55 |
even now i'm ending up fixing way more stuff than i would have wanted in the first place |
| 08:41 |
celeron55 |
and in any case you don't even want a huge changeset from me that touches every part of minetest just because there were some small nitpicks here and there |
| 08:42 |
hmmmm |
i hope it's not too much to ask for |
| 08:43 |
hmmmm |
as much as you focus on your actual task at hand, commits should be as focused as possible as well |
| 08:43 |
hmmmm |
otherwise what's the point? might as well just attach a script to your IDE's "save" button that runs git commit -m "WIP" |
| 08:43 |
celeron55 |
oh, you want me to explain that? well i'll explain that then |
| 08:44 |
celeron55 |
(i didn't think i would have to) |
| 08:44 |
celeron55 |
i make three kinds of commits when i am working on a big feature like this |
| 08:44 |
hmmmm |
explain what |
| 08:44 |
celeron55 |
type 1: a commit that implements or fixes something in an unrelated part of the code |
| 08:46 |
celeron55 |
type 2: a commit that i made because i am either switching direction in my design so considerably that i might just forget how many times exactly to undo things to get where i was, or i am just leaveing my computer and want to know where i was then (often called just WIP) |
| 08:46 |
celeron55 |
type 3: a commit where i see that the subfeature that i was making now works; often called something more reasonable and intended to be at least squashed with all the previous WIP commits |
| 08:47 |
celeron55 |
but i squash absolutely nothing before i have to, because i would be losing information |
| 08:47 |
hmmmm |
so in other words, with your workflow it isn't so difficult to keep the unrelated things separated |
| 08:47 |
celeron55 |
i recommend this to everyone, in fact |
| 08:51 |
celeron55 |
i know how much attention span i have for this and that is how i budget the unrelated things |
| 08:52 |
celeron55 |
it's not something you can choose |
| 08:52 |
hmmmm |
shouldn't you be coding instead of talking right now? |
| 08:53 |
celeron55 |
well, you were the one asking but i guess i'll go make some breakfast now |
| 09:00 |
celeron55 |
you might be under the impression that i'm just making huge meshes on the client, but now i have actually spent days reworking the map sending algorithm so that it can reliably and efficiently support loading and sending this stuff |
| 09:01 |
celeron55 |
this is much harder than i thought it would be |
| 09:01 |
hmmmm |
what is the map sending algorithm now? |
| 09:01 |
celeron55 |
i have ended up with the server choosing what to sent based on a few parameters periodically updated by the client |
| 09:02 |
celeron55 |
it's essentially the same as before but, like, not a prototype made in a few hours like the previous one was |
| 09:02 |
celeron55 |
and with these things required for FarBlocks |
| 09:02 |
|
nrzkt joined #minetest-dev |
| 09:03 |
hmmmm |
that is a rather vague description |
| 09:03 |
celeron55 |
...or i don't know if "essentially the same" is a correct way to put it |
| 09:03 |
celeron55 |
ask a detail and i will tell a detail |
| 09:03 |
celeron55 |
there are many details |
| 09:04 |
hmmmm |
well you say it's essentially the same but then you say that it was a lot harder than you thought |
| 09:04 |
hmmmm |
soooo.. |
| 09:05 |
celeron55 |
the old algorithm was kind of inefficient due to multiple reasons, and this one is less inefficient; and it contained multiple bugs that i had to sort out |
| 09:05 |
celeron55 |
FarBlocks require this to be able to first determine what MapBlock and what FarBlock would be sent, and then prioritize between them |
| 09:06 |
celeron55 |
then there's the logic that determines when to send a farblock because they are loaded from disk in such small pieces (that are MapBlocks) |
| 09:06 |
celeron55 |
stuff like that |
| 09:06 |
hmmmm |
just to be clear; FarBlocks are not saved to disk, correct? |
| 09:07 |
celeron55 |
yes; i don't intend to save them; they are an in-memory cache (i guess) |
| 09:07 |
hmmmm |
cool |
| 09:13 |
celeron55 |
overally this is such a dynamic system that it is hard to test; but i have managed to break it apart into more meaningful smaller pieces so that's good |
| 09:14 |
hmmmm |
yeah that's another thing I'm concerned about |
| 09:14 |
celeron55 |
but the logic has to pull all kinds of information from everywhere in order to do what it needs to do |
| 09:14 |
hmmmm |
many things in minetest are not testable due to the lack of separation of concerns |
| 09:14 |
celeron55 |
not more than before really, but that was already many things |
| 09:14 |
hmmmm |
would people be able to write unit tests for this new code? |
| 09:15 |
celeron55 |
if you'd replace some direct references to things with interfaces, then possibly |
| 09:15 |
celeron55 |
because the autosend algorithm is now a separate class |
| 09:16 |
celeron55 |
instead of being mangled inside RemoteClient |
| 09:18 |
|
Gael-de-Sailly joined #minetest-dev |
| 09:34 |
|
paramat joined #minetest-dev |
| 09:36 |
paramat |
now merging flat mapgen https://github.com/minetest/minetest/pull/3313 |
| 09:43 |
paramat |
merged |
| 09:59 |
paramat |
i appreciate the work on farmap, excellent feature, love the screenshots |
| 09:59 |
|
paramat left #minetest-dev |
| 10:01 |
|
Calinou joined #minetest-dev |
| 10:17 |
|
crazyR joined #minetest-dev |
| 10:49 |
celeron55 |
i am happy to announce that the emerge system is happily coping with the utterly ridiculous amounts of emerge requests when the new algorithm (which finally works properly) is racing to load hundreds of FarBlocks |
| 10:50 |
celeron55 |
well, properly in the speed aspect (in other aspects it's still WIP) |
| 10:51 |
celeron55 |
or, well |
| 10:52 |
celeron55 |
the only thing now is that the idle sleep is broken so it consumes a lot of CPU but that's easily fixed i suspect and i think i'll do it now |
| 10:53 |
celeron55 |
or, not the sleep but the triggering of it... whatever! |
| 10:59 |
|
proller joined #minetest-dev |
| 11:05 |
|
proller joined #minetest-dev |
| 11:14 |
|
proller joined #minetest-dev |
| 11:37 |
|
Amaz joined #minetest-dev |
| 11:37 |
|
Megaf joined #minetest-dev |
| 11:38 |
Megaf |
https://github.com/minetest/minetest/issues/3357 |
| 11:38 |
Megaf |
#3357 |
| 11:39 |
thatgraemeguy |
that was done in _game, not in engine |
| 11:39 |
thatgraemeguy |
it makes sense too, trees need light to grow |
| 11:40 |
Megaf |
oh |
| 11:40 |
Megaf |
ok |
| 11:40 |
Megaf |
I will close the issue there and open in game |
| 11:41 |
Megaf |
thatgraemeguy: minetest is not aobut realism, is about freedom, and that breaks a lot of stuff in my server |
| 11:41 |
thatgraemeguy |
don't shoot the messenger |
| 11:42 |
celeron55 |
thank god that is not an engine issue; at least something in this design is working 8D |
| 11:44 |
Megaf |
celeron55: lol |
| 11:45 |
Megaf |
https://github.com/minetest/minetest_game/issues/724 |
| 11:45 |
Megaf |
just moved the issue to the right place |
| 11:47 |
thatgraemeguy |
heh, good luck |
| 11:51 |
Megaf |
thatgraemeguy: https://github.com/minetest/minetest_game/issues/724#issuecomment-155751466 |
| 11:56 |
crazyR |
Megaf. You could write a mod to overide it. it wouldnt be that hard |
| 11:57 |
|
jin_xi joined #minetest-dev |
| 11:57 |
Megaf |
crazyR: I can not, I have no idea how to do that |
| 11:57 |
|
cib0 joined #minetest-dev |
| 12:07 |
crazyR |
Il see what i can do if i get some spare time today. as i doubt they will change it back unless a lot of people demand it |
| 12:10 |
crazyR |
celeron55 whats the deal with overiding abm's. can it be done, or would not register ? |
| 12:16 |
crazyR |
actually scrap that, its not needed :) |
| 12:17 |
Megaf |
Calinou: mosh is fantastic, I no longer have to reconnect to my server, it does on its own |
| 12:17 |
Megaf |
wrong channel |
| 12:45 |
|
Darcidride joined #minetest-dev |
| 13:22 |
|
zat joined #minetest-dev |
| 13:26 |
|
PilzAdam joined #minetest-dev |
| 14:01 |
|
VargaD joined #minetest-dev |
| 14:15 |
|
zupoman joined #minetest-dev |
| 14:15 |
|
Calinou joined #minetest-dev |
| 14:15 |
|
Fritigern joined #minetest-dev |
| 15:24 |
|
Hunterz joined #minetest-dev |
| 15:35 |
|
rubenwardy joined #minetest-dev |
| 15:53 |
celeron55 |
the fact that in minetest node id 0 is just a random regular node is actually pretty annoying |
| 15:53 |
celeron55 |
you can't just rely on arrays initializing at 0 |
| 15:54 |
celeron55 |
it's surprisingly hard to spot every place that needs to be explicitly set to CONTENT_IGNORE |
| 15:58 |
rubenwardy |
Would it be impossible/difficult to change w/o incompatibility? To set CONTENT_IGNORE=0? |
| 15:59 |
celeron55 |
here's some modern art: http://i.cubeupload.com/9gqPHU.jpg http://i.cubeupload.com/qtJqfN.jpg http://i.cubeupload.com/MtiQPF.jpg |
| 16:00 |
|
CraigyDavi joined #minetest-dev |
| 16:00 |
celeron55 |
rubenwardy: that would require looking up a huge amount of version compatibility details |
| 16:01 |
celeron55 |
it would work straight away if you dropped old worlds and network compatibility but those are the hard part |
| 16:01 |
rubenwardy |
So the CONTENT_IGNORE isn't declared by the server, it's a constant that's always the same |
| 16:02 |
celeron55 |
the modern art i just linked is actually quite effective |
| 16:03 |
celeron55 |
looking at it makes me almost feel like i'm suffocating |
| 16:03 |
rubenwardy |
When a player emerges, does it create a dummy MapBlock whilst it waits for mapgen to work? |
| 16:04 |
|
hmmmm joined #minetest-dev |
| 16:06 |
* VanessaE |
hopes celeron55 pushes soon... wanna test ;) |
| 16:09 |
celeron55 |
the problems in dreambuilder are reproducible, by the way |
| 16:09 |
celeron55 |
and i can't figure out what causes them |
| 16:10 |
celeron55 |
use less nodes and it works |
| 16:10 |
VanessaE |
at least that rules out a hardware or driver fault |
| 16:10 |
celeron55 |
i tried looking up some simple-ish errors i might have made but didn't find any (like using u8 in place of u16) |
| 16:14 |
|
Lunatrius` joined #minetest-dev |
| 16:15 |
|
Warr1024_ joined #minetest-dev |
| 16:16 |
|
Icedream- joined #minetest-dev |
| 16:16 |
|
who_wants_some joined #minetest-dev |
| 16:36 |
celeron55 |
http://i.imgur.com/BQWudzF.jpg |
| 16:36 |
celeron55 |
nodetopia and mgv7 |
| 16:36 |
celeron55 |
it's cute |
| 16:36 |
VanessaE |
that actually looks pretty good. |
| 16:36 |
celeron55 |
ok i think i'll push now |
| 16:37 |
VanessaE |
btw about dreambuilder, does it help you if I mention there are come 16,500 nodes in that game? |
| 16:37 |
celeron55 |
i know how many there are |
| 16:37 |
VanessaE |
(nodes/items) |
| 16:37 |
celeron55 |
too god damn many |
| 16:37 |
VanessaE |
lol |
| 16:38 |
celeron55 |
pushed https://github.com/celeron55/minetest/commits/far_map_wip |
| 16:38 |
celeron55 |
now there is a setting called "far_map_allow_generate" that defaults to false |
| 16:41 |
rubenwardy |
and 90% of those nodes are probably from homedecor ;) |
| 16:41 |
VanessaE |
rubenwardy: actually, about half of them come from mods like colored woods, stained glass, etc. |
| 16:42 |
VanessaE |
if the engine had in-the-map colorization of nodes, I could probably cut the item count in half. meta_set_nodedef could improve that further. |
| 16:45 |
VanessaE |
celeron55: did you decide if you're going to allow the farmap texture atlas to be used for general non-facedir terrain? |
| 16:45 |
celeron55 |
why would it use the same atlas |
| 16:46 |
VanessaE |
well you mentioned something along those lines yesterday |
| 16:46 |
celeron55 |
well i'm not doing it in a loooong time |
| 16:46 |
VanessaE |
no worries. |
| 16:46 |
celeron55 |
if that's what you are asking |
| 16:47 |
|
Hunterz joined #minetest-dev |
| 16:49 |
|
est31 joined #minetest-dev |
| 16:49 |
|
Icedream joined #minetest-dev |
| 16:50 |
VanessaE |
seems to work mostly. one thing though is if the server lags, it loves to load in the farmap data before it loads in the corresponding "detailed" terrain |
| 16:50 |
VanessaE |
maybe it shouldn't load either one in that case. |
| 16:51 |
VanessaE |
(well, whatever you call the "server half" of singleplayer) |
| 16:51 |
est31 |
that "color nodes" or "hardcode slabs into the engine" disscussion doesn't bring much. You still will have to address all those nodes some way, and every system you could think of would be less flexible than the current one. |
| 16:52 |
est31 |
ofc, its bad that it pregenerates all the textures for the whole nodedef, but that can be optimized without introducing categories |
| 16:53 |
est31 |
just generate them when you want to render a mapblock with that node, and un-generate them when you delete that mapblock from the client's env. |
| 16:53 |
VanessaE |
celeron55: here's an example of what I mean by that: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-11_11-52-52.png |
| 16:53 |
celeron55 |
yes; people shouldn't falsely think adding more identifiers alongside the node id and facedirs would make performance better |
| 16:53 |
VanessaE |
(as you can see, the edge of the road is only 2 or 3 meters in front of me) |
| 16:53 |
celeron55 |
if anything, each of those additions makes it worse |
| 16:54 |
celeron55 |
VanessaE: i don't know what you are talking about |
| 16:54 |
celeron55 |
or what that screenshot is about |
| 16:55 |
celeron55 |
oh, you mean that |
| 16:55 |
VanessaE |
celeron55: that screenshot is me running down the road and stopping when the game lagged. you can see farmap terrain that shouldn't even BE there yet imho. here's the same scene after letting the lag subside and the terrain load: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-11_11-54-12.png |
| 16:55 |
celeron55 |
well, it's just a priorization system |
| 16:56 |
celeron55 |
it can't magically help server lag |
| 16:56 |
est31 |
hmmmm's map locking plans would help there I guess |
| 16:56 |
VanessaE |
oh I'm not worried about the lag, that's just some inefficient entity-related mod or something |
| 16:56 |
est31 |
but thats another discussion |
| 16:56 |
celeron55 |
well let me add a thing to the client's configuration that you can use to control the priorities |
| 16:58 |
|
Krock joined #minetest-dev |
| 17:08 |
celeron55 |
okay, added |
| 17:09 |
celeron55 |
https://github.com/celeron55/minetest/commit/05850ce25ec2e0a2ae4bb8382d14d67ba778e817 |
| 17:09 |
VanessaE |
your timing is impeccable. |
| 17:09 |
VanessaE |
not 2 seconds before you said that, I pulled :) |
| 17:09 |
celeron55 |
set that lower if you want to prioritize regular map transfers |
| 17:10 |
celeron55 |
i think i'll lower the default to 4 |
| 17:10 |
|
damiel joined #minetest-dev |
| 17:10 |
celeron55 |
or... maybe 5 |
| 17:11 |
* VanessaE |
tries it with 4. |
| 17:14 |
VanessaE |
4, with a farmap range of 300 seems good |
| 17:17 |
VanessaE |
hm. note to self: tell cheapie about the junkyard having been raided. |
| 17:19 |
VanessaE |
make that range 200. I think if you can sort out that "too god damn many" nodes ;-) glitch, you've got something very usable. |
| 17:22 |
celeron55 |
use the built-in watershed and be impressed |
| 17:22 |
celeron55 |
you want to up the range to like 700 |
| 17:23 |
VanessaE |
oh I was just keeping the range at 200 because this world just has horrible fps in built-up areas anyway |
| 17:23 |
* VanessaE |
tries watershed |
| 17:23 |
VanessaE |
hm. watershed is not offers as a mapgen in the "new" dialog. |
| 17:24 |
celeron55 |
(it's not in the menu but there are some ways you can get a world to use it) |
| 17:24 |
celeron55 |
i just put it in minetest.conf and start a server at a new world, stop the server and then start singleplayer on it |
| 17:25 |
celeron55 |
paramat had some other way |
| 17:26 |
VanessaE |
editing map_meta.txt and deleting map.sqlite seems to work |
| 17:27 |
VanessaE |
kinda. :P |
| 17:27 |
VanessaE |
there we are. it couldn't find a spot to spawn me, had to fly up to +230 :P |
| 17:28 |
VanessaE |
hah, segfaulted :D |
| 17:29 |
celeron55 |
it isn't segfaulting for me exactly all the time so you need to get a backtrace |
| 17:29 |
celeron55 |
and i've been running it all day |
| 17:29 |
VanessaE |
oh I'll grab a bt later |
| 17:29 |
VanessaE |
just amused is all :) |
| 17:33 |
|
cib0 joined #minetest-dev |
| 17:35 |
VanessaE |
your "topmost node" calculation looks to have an off-by-1 error |
| 17:35 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-11_12-34-41.png versus http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-11_12-34-48.png |
| 17:35 |
VanessaE |
(minetest_game, unmodified, mgv7) |
| 17:46 |
Krock |
http://i50.photobucket.com/albums/f324/ann1024/DevelopersAreBornBrave_Small.jpg |
| 17:46 |
VanessaE |
heh |
| 18:06 |
celeron55 |
umm? |
| 18:06 |
celeron55 |
off-by-1 based on what? |
| 18:07 |
celeron55 |
it doesn't use the leaves unless it has no other choice because leaves propagate light and thus aren't as solid as something else is that it prefers |
| 18:08 |
celeron55 |
it desperatetly wants something solid; it's all it's got in life |
| 18:08 |
celeron55 |
don't go mocking it like that |
| 18:09 |
celeron55 |
also, you are still looking it up too close; it's never going to look good that close |
| 18:10 |
VanessaE |
based on height? what I mean is, why are tree trunks showing when there's nothing but leaves on the top layer (and certainly more of them than trunks) |
| 18:10 |
celeron55 |
i just explained that |
| 18:10 |
VanessaE |
well I guess |
| 18:11 |
VanessaE |
but in practice, you really should be just showing whatever the cube has the most of |
| 18:11 |
celeron55 |
that's a much more expensive calculation than to just go throgh one Y column |
| 18:11 |
celeron55 |
how many leaves are there on top of that trunk? |
| 18:12 |
celeron55 |
inside the farnode |
| 18:12 |
VanessaE |
1 or 2 nodes. |
| 18:12 |
VanessaE |
if you flip between the two screenshots, you can see what I was trying to point out. also look to the left, where you can see a chunk of leaves appear/disappear entirely. |
| 18:15 |
VanessaE |
as for being too close, I only got up close to this spot to show the issue; I see this happening 50, 100 nodes away too. |
| 18:15 |
celeron55 |
i think it's fine, but let me add a profiling timer in there so people can figure out if they can make it better without making it much slower |
| 18:22 |
|
Calinou joined #minetest-dev |
| 18:26 |
celeron55 |
https://github.com/celeron55/minetest/blob/5f0402b36e2208446250aca25df0aadc9fbefe57/src/far_map_server.cpp#L98 |
| 18:27 |
celeron55 |
this is what decides how each FarNode looks like |
| 18:28 |
|
Robert_Zenz joined #minetest-dev |
| 18:29 |
VanessaE |
yeah, that's the issue then, you only search the center column, so every so often you hit the tree trunk (as in my example), so you get what looks like a block of trunks, even if there are far more leaves. |
| 18:29 |
celeron55 |
well, obviously |
| 18:29 |
VanessaE |
yeah, in practice I don't think that's gonna satisfy users |
| 18:30 |
VanessaE |
you've only got 256 nodes to search (and sort by count) in a block, I'd think the engine could do that in a couple of milliseconds? |
| 18:31 |
VanessaE |
..in a farnode block thingy I mean |
| 18:32 |
celeron55 |
in a 1024x384x1024 area of map (which is roughly what you get when you use a range of 500), there are 98304 MapBlocks that the thing has to go through |
| 18:32 |
celeron55 |
you don't want it taking a millisecond for sure |
| 18:33 |
celeron55 |
that would be two minutes of purely churning that code |
| 18:33 |
celeron55 |
currently it takes something like 13-16µs for me which is quite fine |
| 18:34 |
VanessaE |
ok well maybe a millisecond or two is an exaggeration |
| 18:34 |
VanessaE |
but that said, how long does it take to load that much map data in practice? (assuming it's already been generated) |
| 18:35 |
celeron55 |
not as long as you think |
| 18:35 |
VanessaE |
by my experience, that's at least 5-10 mins of flying around to get that much map loaded |
| 18:35 |
|
Niebieski joined #minetest-dev |
| 18:35 |
celeron55 |
i'm testing now |
| 18:35 |
VanessaE |
that aside, if it takes 16 uS for one column, then it should take between 250 and 300 uS to search all 16 columns, including time to count and sort it |
| 18:37 |
celeron55 |
looks like about 2 minutes |
| 18:38 |
celeron55 |
and the average for that function went as high as over 30µs |
| 18:39 |
|
VanessaE left #minetest-dev |
| 18:39 |
|
VanessaE joined #minetest-dev |
| 18:39 |
VanessaE |
oops. |
| 18:39 |
celeron55 |
i'm of course using this laptop with a 512GB SSD and a quad core processor running at over 3GHz |
| 18:40 |
celeron55 |
and 16GB of RAM |
| 18:40 |
celeron55 |
so your values will be worse i guess |
| 18:40 |
VanessaE |
yeah, I'm speaking in terms of playing on a server such as VE-Basic |
| 18:47 |
celeron55 |
i guess i'll test something |
| 18:49 |
celeron55 |
i made a simple implementation for finding what the most common node is and it takes over 400µs on average |
| 18:49 |
celeron55 |
that's unacceptable |
| 18:49 |
celeron55 |
it's 40 seconds from the total load time of 2 minutes; no way |
| 18:49 |
celeron55 |
that would be ridiculous |
| 18:51 |
celeron55 |
and this makes all ground be stone |
| 18:51 |
VanessaE |
400 uS is about in line with what I'd expect. |
| 18:52 |
VanessaE |
ok so just find only the top nodes |
| 18:52 |
VanessaE |
and sort those |
| 18:52 |
VanessaE |
at worst, 16 entries to be counted (once found) |
| 18:59 |
VanessaE |
and at least with that, you can be sure grass will remain as grass :) |
| 19:03 |
VanessaE |
one thing that would be nice, but probably way too expensive, would be to sort each of the 6 sides of the farmap cubes |
| 19:03 |
VanessaE |
so e.g grass on top, dirt or stone or something on the sid etc. |
| 19:03 |
VanessaE |
side* |
| 19:03 |
VanessaE |
not sure if it would actually look good though |
| 19:10 |
VanessaE |
this is the part where someone is supposed to pipe up and mention that octrees would be the magic bullet :) |
| 19:10 |
celeron55 |
this is way too slow |
| 19:11 |
celeron55 |
if i try to do anything fancy in there, it goes to the range of hundreds |
| 19:11 |
VanessaE |
(to that end, I remember a couple years ago some minecraft-related blog discussing how to do something like your farmap, but with variable-sized cubes) |
| 19:11 |
celeron55 |
i am not interested in technical fancytalk like that; it's never actually useful and is just basically some kind of wankery |
| 19:11 |
celeron55 |
if you didn't know |
| 19:12 |
VanessaE |
I assumed as much |
| 19:12 |
VanessaE |
:) |
| 19:13 |
celeron55 |
i can tell you that this looks incredibly boring when the trunks are missing |
| 19:14 |
VanessaE |
I'd say boring is fine as long as it looks more accurate |
| 19:17 |
celeron55 |
well that's the problem |
| 19:18 |
VanessaE |
damn it where is that blog post |
| 19:25 |
VanessaE |
I guess the only sane thing to do, once you have an accurate way to "scale down" the terrain data, is to cache it in the map :-/ |
| 19:26 |
Warr1024 |
if you cache that metadata server-side, you could have the option of sending only that metadata to clients for distant mapblocks, too. |
| 19:26 |
celeron55 |
meh; i'll just make it configurable and then everyone can decide by themselves how much time they want to waste in that function |
| 19:26 |
celeron55 |
caching this is out of question |
| 19:26 |
celeron55 |
on disk that is |
| 19:27 |
Warr1024 |
is it going to be a lot of data or something? or do you just not want to mess with the file formats? |
| 19:27 |
celeron55 |
i won't do it, and it won't be accepted because it's not needed and complicates things too much |
| 19:29 |
celeron55 |
why are you even suggesting that; it's ridiculous |
| 19:29 |
VanessaE |
celeron55: because you're trying to create these meshes in realtime. why? |
| 19:29 |
celeron55 |
i think i got the result you want by checking four Y columns |
| 19:30 |
VanessaE |
four? |
| 19:30 |
VanessaE |
ok I'm listening :) |
| 19:30 |
VanessaE |
(you can be sure you'll never end up with a tree turning into only trunks, for sure) |
| 19:30 |
celeron55 |
well it looks almost the same as the other result |
| 19:32 |
VanessaE |
if this were normal terrain (rather than voxels), this might have been helpful: http://www.gamasutra.com/view/feature/131596/realtime_dynamic_level_of_detail_.php?print=1 |
| 19:32 |
VanessaE |
(it's not the page I was looking for, though) |
| 19:41 |
VanessaE |
another related, http://www.sea-of-memes.com/LetsCode64/LetsCode64.html |
| 19:42 |
celeron55 |
i won't open any of those but if someone is bored, i guess those are fun |
| 19:42 |
VanessaE |
just "thinking out loud". |
| 19:43 |
celeron55 |
i think i'm going to end up with something that you might be okay with |
| 19:52 |
VanessaE |
ok. |
| 19:54 |
|
who_wants_some_ joined #minetest-dev |
| 19:57 |
|
who_wants_some joined #minetest-dev |
| 20:01 |
|
who_wants_some_ joined #minetest-dev |
| 20:03 |
|
who_wants_some_ joined #minetest-dev |
| 20:05 |
|
who_wants_some joined #minetest-dev |
| 20:11 |
|
est31 joined #minetest-dev |
| 20:17 |
VanessaE |
est31: you mentioned before about wanting to rework /clearobjects to get down into the 20 min range. still going to do that? |
| 20:17 |
est31 |
well I have it coded actually |
| 20:17 |
est31 |
I just need to tidy it up |
| 20:18 |
est31 |
but the question is rather whether its wanted or not |
| 20:18 |
VanessaE |
well |
| 20:18 |
VanessaE |
given that I tried to do a /clearobjects on VE-survival (local copy) and 8 hours later it was still chewing on it.... |
| 20:18 |
VanessaE |
'nuff said? :) |
| 20:19 |
est31 |
okay, then I'll tidy it up |
| 20:19 |
est31 |
I just wonder how much of minetest's code to re-use |
| 20:20 |
VanessaE |
at the time, I was trying to rig up a sort of "optimum test map" - an empty game dir (literally zero mods), so that there'd be nothing in the world but unknown nodes and zero entities. |
| 20:20 |
VanessaE |
(basically a sort of "let's find where it is REALLY crapping out map) |
| 20:24 |
|
who_wants_some joined #minetest-dev |
| 20:54 |
celeron55 |
this is fiddly as fuck |
| 20:54 |
celeron55 |
nobody is allowed to touch this anymore after i make my next commit; it can only get worse |
| 20:54 |
VanessaE |
what's fiddly about it? |
| 20:54 |
celeron55 |
there are so many little details the output must conform to in order to be useful |
| 20:55 |
celeron55 |
for example, if the area is mostly air, the result still cannot usually be air because it would reveal the underground |
| 20:55 |
celeron55 |
but if the area is almost completely air by an arbitrary limit that i had to come up with, it will be considered to be air because otherwise, again, it looks stupid |
| 20:58 |
celeron55 |
and i had to make it check 8 Y columns; otherwise it's too fiddly |
| 20:59 |
celeron55 |
i mean, otherwise it has a slightly too random output |
| 20:59 |
celeron55 |
but with 16 it goes above the time i am going to allow it to take |
| 20:59 |
celeron55 |
even now it's taking 20% of emergethread's time |
| 20:59 |
|
RethaiN joined #minetest-dev |
| 21:00 |
celeron55 |
which is around 100us per MapBlock |
| 21:02 |
VanessaE |
too bad your farblock size isn't 5x5, then you could use a 5-column sample (center and corners), which would probably be optimal |
| 21:03 |
celeron55 |
that doesn't matter |
| 21:20 |
celeron55 |
pushed |
| 21:20 |
celeron55 |
i am not happy with this but i cannot make it better |
| 21:20 |
celeron55 |
so that's what it will be |
| 21:22 |
VanessaE |
actually, that looks pretty good |
| 21:25 |
VanessaE |
you got some un-init data happening though: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-11_16-24-25.png |
| 21:26 |
celeron55 |
no, that's just the same old glitch |
| 21:26 |
VanessaE |
(mgv7, mt_game, flying into some newly-generated terrain, I think) |
| 21:26 |
VanessaE |
oh ok. |
| 21:26 |
celeron55 |
it happens in mt_game too during some conditions that i don't understand |
| 21:28 |
VanessaE |
well that at least rules out "too G*d damn many nodes" as the cause. :P |
| 21:32 |
celeron55 |
it seems that for some reason the mesh ends up with wrong texture coordinates |
| 21:33 |
celeron55 |
when you go close to it, different meshes are rendered instead of the large one and then the effect disappears with the large mesh |
| 21:33 |
celeron55 |
and stays in it |
| 21:34 |
celeron55 |
or, well, a wrong texture atlas texture |
| 21:34 |
celeron55 |
all of the textures that end up in them are valid as far as i know; they are just some completely random weird ones |
| 21:35 |
celeron55 |
or... well if the atlas texture is switched, then maybe it can also contain some uninitialized areas that the others don't |
| 21:35 |
celeron55 |
but i haven't seen such yet |
| 21:39 |
VanessaE |
am I seeing this right that you're doing 4^3 at one distance, and then 8^3 further out? |
| 21:40 |
celeron55 |
yeah, there's a further LOD level hardcoded to begin at 500 |
| 21:40 |
celeron55 |
and no, it's not 8^3; it's full MapBlocks at that point |
| 21:40 |
VanessaE |
ah |
| 21:41 |
VanessaE |
couldn't tell at that distance :) |
| 21:42 |
VanessaE |
would it take a lot of resources to do 2^3 and 8^3 also? |
| 21:44 |
celeron55 |
dunno, maybe |
| 21:46 |
|
cib0 joined #minetest-dev |
| 21:46 |
celeron55 |
that's completely out of scope for me; it's not useful in my opinion compared to any work reequired to make it or any resources it would use |
| 21:47 |
VanessaE |
this is actually pretty impressive. I've got pieces of terrain visible almost 1000 meters away now, with farmap range set to that, and still managing 30 fps with a "detail" view range of 130 |
| 21:47 |
VanessaE |
(the whole strip between there and where I am is loaded) |
| 21:48 |
celeron55 |
it's the power of huge static VBOs and as low level of detail as humanly possible :P |
| 21:48 |
VanessaE |
heh |
| 21:48 |
VanessaE |
one thing though, the detailed terrain is taking an ice age to load, yet the farmap stuff is loading instantly |
| 21:48 |
VanessaE |
(well as instantly as terrain ever has anyway) |
| 21:49 |
celeron55 |
that depends on so many factors that the complaint is useless to me |
| 21:49 |
celeron55 |
it has always worked for me 100% fine |
| 21:50 |
celeron55 |
maybe lower far_map_far_factor even more |
| 21:50 |
celeron55 |
i mean |
| 21:50 |
celeron55 |
what was it called |
| 21:50 |
celeron55 |
far_map_far_weight |
| 21:51 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-11_16-50-27.png this farmap area here took 15 seconds to fill in with detailed terrain |
| 21:51 |
VanessaE |
normally terrain like this would load in a fair fraction of a second at most |
| 21:52 |
celeron55 |
well if there's a farblock nearby that is closer when the distance is divided by far_map_far_weight than those mapblocks, it will be loaded first |
| 21:52 |
celeron55 |
is that server running anything laggy? |
| 21:52 |
VanessaE |
this is vanilla mt_game on singleplayer. |
| 21:52 |
VanessaE |
fresh map, mgv7 |
| 21:53 |
celeron55 |
did it have to generate it? |
| 21:53 |
VanessaE |
yes, but the area you see in the screenshot was generated at least a minute or so before I snapped the shot |
| 21:56 |
celeron55 |
i guess the farblock loading could make such an emerge queue that it will trigger the generation of multiple mapgen chunks |
| 21:56 |
celeron55 |
and as it is a queue, nothing will get past it |
| 21:57 |
celeron55 |
i assume you have far_map_allow_generate set to true |
| 21:57 |
VanessaE |
ye |
| 21:57 |
VanessaE |
s |
| 21:58 |
celeron55 |
it kind of needs to heavily fill up the queue though because otherwise the queue will just run out and things will just idle if the stuff is coming from disk |
| 21:58 |
celeron55 |
and then you'd get long loading times for no reason |
| 22:03 |
celeron55 |
i guess that can be solved somehow if it ends up being a problem |
| 22:04 |
VanessaE |
something of note:" |
| 22:05 |
VanessaE |
the minimap indicates that distant terrain that has at least farmap blocks is not actually loaded. |
| 22:06 |
VanessaE |
(if the "detailed" terrain isn't showing, that is) |
| 22:06 |
VanessaE |
example: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-11_17-05-36.png |
| 22:08 |
* VanessaE |
tries something.. |
| 22:08 |
celeron55 |
yeah the minimap doesn't know anything about the farmap |
| 22:09 |
celeron55 |
the data is probably reasonably easy to pass there assuming the minimap is fast enough to process all that |
| 22:10 |
celeron55 |
but maybe it needs a new interface for pushing low-resolution data into it so that it doesn't need to be upscaled first 8) |
| 22:10 |
VanessaE |
something = turning block send distance up to 25 and adding the two "simultaneous block sends" params I use with my servers. no effect though. |
| 22:12 |
celeron55 |
the server only sends the distance that the client requests, and the client only requests the distance that it renders |
| 22:13 |
VanessaE |
meanwhile, it's sitting here hammering two cores, but very little is happening on screen |
| 22:13 |
celeron55 |
it doesn't push unnecessary mapblocks to clients anymore |
| 22:13 |
VanessaE |
that's good |
| 22:13 |
celeron55 |
it's probably generating some faraway stuff to be slowly created into farblocks |
| 22:13 |
celeron55 |
don't expect to see anything in a good while... |
| 22:14 |
celeron55 |
and expect the map size to go up like crazy |
| 22:14 |
celeron55 |
that's why there is the setting 8) |
| 22:16 |
VanessaE |
that would explain it to some degree then. |
| 22:17 |
VanessaE |
in my current view (after a restart), render distance of 81 at 30 fps; minimap needs 128+ to fill it out. |
| 22:18 |
celeron55 |
somebody can just implement the farmap-to-minimap thing |
| 22:18 |
celeron55 |
i have never found the minimap useful or used it nor did i even want it |
| 22:19 |
celeron55 |
so this is easy to prioritize to me |
| 22:19 |
VanessaE |
minimap isn't important for this |
| 22:19 |
VanessaE |
that's just something I noticed. |
| 22:21 |
VanessaE |
interesting thing about that texture coordinate glitch is that it's consistent across restarts. |
| 22:23 |
celeron55 |
it seems to me |
| 22:28 |
VanessaE |
ok 9 minutes after a restart, without moving or changing yaw, it's still hitting 2 cores solid |
| 22:29 |
VanessaE |
overlooking terrain that's long since been generated |
| 22:29 |
VanessaE |
though every so often I see something appear in the distance |
| 22:29 |
VanessaE |
something new* |
| 22:29 |
VanessaE |
(like once a minute or so) |
| 22:31 |
VanessaE |
bbl |
| 22:33 |
celeron55 |
i pushed some profiler additions to EmergeThread and whatever |
| 22:33 |
celeron55 |
now some kind of an average queue size is visible there along with some other useful stats |
| 22:34 |
celeron55 |
i found a quite magical place in nodetopia+mgv7 |
| 22:34 |
celeron55 |
it's a tower of floating islands on top of a thick large forest which grows on the surface of a lake |
| 22:34 |
celeron55 |
this is some intense stuff |
| 22:35 |
celeron55 |
http://i.imgur.com/oxSRUlm.jpg |
| 22:51 |
|
proller joined #minetest-dev |
| 22:54 |
celeron55 |
hi proller; here is a new screenshot: https://forum.minetest.net/viewtopic.php?p=197801#p197801 |
| 22:54 |
celeron55 |
8) |
| 22:54 |
|
who_wants_some joined #minetest-dev |
| 22:57 |
hmmmm |
lol you're so proud of your farmap thing |
| 22:57 |
celeron55 |
it's glorious |
| 22:59 |
celeron55 |
actually what is even more glorious than it itself is how it gives new value to all of these generator things |
| 23:46 |
|
cib0 joined #minetest-dev |
| 23:48 |
|
Soni joined #minetest-dev |
| 23:53 |
|
est31 joined #minetest-dev |
