| Time |
Nick |
Message |
| 00:00 |
kahrl |
I think updateViewingRange() would be a better place to put a // BLACK MAGIC comment in than updateSelectedItem() |
| 00:01 |
Exio |
// DARK MAGIC HERE! READ WITH CAUTION |
| 00:01 |
Exio |
;P |
| 00:02 |
VanessaE |
PilzAdam: what it should be doing is gradually adjusting the value of wanted_rate_change based on how far the actual fps is from the target, with a minimum value, and use some simple hysteresis to prevent oscillations. |
| 00:02 |
VanessaE |
wait, actually it already does that |
| 00:02 |
kahrl |
VanessaE, you mean a PID controller? |
| 00:02 |
VanessaE |
well, it adjusts the wanted change |
| 00:03 |
VanessaE |
kahrl: no, talking about the view_range tuner. |
| 00:03 |
kahrl |
I know |
| 00:03 |
VanessaE |
but the lack of hysteresis is why it oscillates with larger values. |
| 00:04 |
kahrl |
the "D" in "PID" is what is supposed to dampen oscillations |
| 00:04 |
VanessaE |
kahrl: I dunno about temperature controllers, but think schmitt-trigger in transistor logic |
| 00:05 |
VanessaE |
line 561 almost does that actually |
| 00:10 |
VanessaE |
my mind just isn't comprehending code right now (and this isn't particularly complex) or I'd try to come up with some better numbers |
| 00:10 |
Exio |
just random optimizations |
| 00:11 |
Exio |
wouldn't be better to move the settings, mymax and so, to the class as private? |
| 00:44 |
|
dexter0 joined #minetest-dev |
| 00:58 |
|
jojoa1997 joined #minetest-dev |
| 00:59 |
|
kaeza joined #minetest-dev |
| 01:14 |
|
ch98 joined #minetest-dev |
| 01:18 |
|
ch98 joined #minetest-dev |
| 01:28 |
|
ImQ009 joined #minetest-dev |
| 01:32 |
|
mrtux joined #minetest-dev |
| 02:05 |
|
Anchakor_ joined #minetest-dev |
| 02:27 |
|
ssieb joined #minetest-dev |
| 02:39 |
hmmmmm |
am i going crazy, or did liquids stop transforming? |
| 02:39 |
kaeza |
both |
| 02:39 |
VanessaE |
define "transforming" |
| 02:40 |
VanessaE |
as in flowing? |
| 02:40 |
hmmmmm |
yeah, flowing |
| 02:40 |
VanessaE |
pilzadam's hacky liquid fix probably did that |
| 02:40 |
VanessaE |
it defaults to 500 (from 10000 in the original code) |
| 02:40 |
hmmmmm |
hrm?? |
| 02:40 |
kaeza |
they flow for a bit and then stand still |
| 02:40 |
hmmmmm |
this is in the core ? |
| 02:40 |
VanessaE |
https://github.com/minetest/minetest/commit/b1ebd9f79c63cf78b0e0fb2ea6f52d82cdfb95b6 |
| 02:41 |
VanessaE |
set liquid = 10000 to get the old behavior. |
| 02:41 |
hmmmmm |
don't really see why he'd set it so low |
| 02:41 |
hmmmmm |
this is breaking shit |
| 02:41 |
VanessaE |
the problem is the queue gets full, but doesn't just throw away events in favor of new events |
| 02:41 |
VanessaE |
they just keep queueing up |
| 02:41 |
hmmmmm |
right |
| 02:42 |
VanessaE |
I hit 500k events in the queue at one point, with the value set to 500, but my server didn't break as it would have with the default code. |
| 02:42 |
hmmmmm |
i am surprised pilzadam would commit something like this... |
| 02:42 |
VanessaE |
I asked him to so it wouldn't get lost/stale. it keeps servers from barfing when users abuse liquids to create gigantic fountains |
| 02:43 |
hmmmmm |
either way, both 'safety mechanisms' are broken as shit |
| 02:43 |
VanessaE |
so it would seem |
| 02:44 |
VanessaE |
I advocated that liquid flowing events be added to the queue in a completely random order, and have the queue get thrown away when the event list is too long, he said that would be pointless |
| 02:47 |
Exio |
and kahrl said it will fuck up stuff that needs the order of the queue |
| 02:47 |
Exio |
:D |
| 02:47 |
VanessaE |
true, forgot about that. |
| 02:47 |
VanessaE |
the way I figure it, you're only able to process X events per second on the output side of the queue (depending on your CPU I guess). If you're adding Y events per second to the input side and Y > X, the queue either has to stack up indefinitely, or part of it has to be thrown away to make room for less-stale events. |
| 02:49 |
hmmmmm |
so what's the order of the queue? |
| 02:49 |
VanessaE |
beats me |
| 02:50 |
VanessaE |
but I presume some block-serial order based on what's active in the mass of loaded blocks |
| 02:50 |
VanessaE |
it has something to do with how recently the liquid was placed also |
| 02:50 |
VanessaE |
older placed liquids flow more readily than newer ones. |
| 02:50 |
hmmmmm |
of course, but what would depend on that order? |
| 02:51 |
VanessaE |
other than downward flow of a given liquid, I can't think of anything |
| 02:51 |
VanessaE |
(and I'm sure that could be easily worked around) |
| 02:52 |
hmmmmm |
why should a flowing liquid add things to the transforming liquid queue if it has already spread to its maximum extent? |
| 02:53 |
VanessaE |
well in a horizontal spread of course you're right |
| 02:53 |
VanessaE |
but vertical spread is where the trouble starts I guess |
| 02:53 |
hmmmmm |
and why is that? |
| 02:53 |
VanessaE |
damned if I know :) |
| 02:55 |
hmmmmm |
mm i'll check it out later |
| 02:56 |
VanessaE |
hmmmmm: the test case we used was pretty simple. Set liquid=10000. teleport to say 0,400,0. Set a single cobble node up there. Now build some random scaffold say 10x10 nodes in dimensions, sparsely populated. pour water and lava. go on pricewatch and buy a new CPU cooler. |
| 02:56 |
VanessaE |
:) |
| 02:57 |
hmmmmm |
and minecraft cuts off after 40 or so nodes iirc |
| 02:57 |
|
arsdragonfly|pho joined #minetest-dev |
| 02:57 |
VanessaE |
kinda hard not to since MC only has a 128-node-tall map, yes? |
| 02:57 |
VanessaE |
the problem is twofold though: |
| 02:57 |
hmmmmm |
i still don't see why we shouldn't cut off vertically |
| 02:58 |
VanessaE |
1 of course is the infinite distance a water node can spread |
| 02:58 |
|
arsdragonfly joined #minetest-dev |
| 02:58 |
VanessaE |
2 is the existence of any kind of lavacooling mod including that which is in default. |
| 02:58 |
VanessaE |
as lava hardens, it creates new surfaces for the liquids to spread onto |
| 02:58 |
VanessaE |
s/a water node/a liquid source node/ |
| 02:59 |
Exio |
VanessaE: i'm pretty sure the problem was the liquid + the get_node(s) in the "abm" |
| 02:59 |
kahrl |
hmmmmm: I don't know much about the order of the queue, but in removeNodeAndUpdate there is a comment that suggests it is important. |
| 02:59 |
VanessaE |
Exio: I'm sure the abm adds its own load, but I don't think it's as bad as pilz was making it seem |
| 03:00 |
kahrl |
map.cpp:1280 |
| 03:00 |
Exio |
(plus it can lead to "sometimes it doesn't apply so continue running it after that") |
| 03:02 |
VanessaE |
Exio: as soon as someone adds a "only_neighboring_faces" field to the ABM definition, I'll remove my extra get_node() checks. |
| 03:02 |
VanessaE |
(and someone adds a way to turn that damn lavacooling ABM off altogether so I can supply my OWN code....) |
| 03:04 |
Exio |
who used a goto in the abm handler? i need to highfive him |
| 03:04 |
VanessaE |
(and if those get_node() checks are as slow as you're implying, the functions they call need to be rewritten. Such things should be virtually instantaneous on anything less than ~15 years old) |
| 03:05 |
hmmmmm |
wtf |
| 03:05 |
hmmmmm |
here i think there's a bug with my code |
| 03:05 |
VanessaE |
? |
| 03:05 |
Exio |
what code? |
| 03:05 |
VanessaE |
what bug? |
| 03:05 |
hmmmmm |
how do i subtract v3s16(20,20,20) from a v3s16 table in lua? |
| 03:05 |
hmmmmm |
am i going crazy? |
| 03:05 |
hmmmmm |
this is totally simple |
| 03:06 |
VanessaE |
I don't think there are any such table operations |
| 03:06 |
Exio |
what is a v3s16 in lua |
| 03:06 |
Exio |
a table with .X .Y and .Z? |
| 03:06 |
hmmmmm |
i am doing this |
| 03:06 |
VanessaE |
you'd have to do it manually I guess |
| 03:06 |
hmmmmm |
local p1 = pointer.above |
| 03:06 |
hmmmmm |
p1.x = p1.x - 20 |
| 03:06 |
hmmmmm |
so on for the other coordinates |
| 03:06 |
VanessaE |
pointer.above? did you mean pointed_thing.above ? |
| 03:06 |
hmmmmm |
no, it's pointer in this code |
| 03:06 |
VanessaE |
ok |
| 03:07 |
hmmmmm |
pointer.above is a v3s16 |
| 03:07 |
VanessaE |
what you're doing SHOULD work though, |
| 03:07 |
hmmmmm |
er, holds x y and z rather |
| 03:07 |
VanessaE |
at least from Lua's standpoint |
| 03:07 |
kaeza |
hmmmmm, have in mind that p1 = pointed_thing.above does not copy the table |
| 03:07 |
VanessaE |
that's true, it's all pass-by-reference |
| 03:07 |
VanessaE |
(which has bitten me more times than I can count) |
| 03:07 |
hmmmmm |
aaaaaaaaaaaaaa |
| 03:07 |
Exio |
hahaha |
| 03:07 |
hmmmmm |
oh boy |
| 03:08 |
VanessaE |
hmmmmm <head explode> |
| 03:08 |
hmmmmm |
i really hate lua |
| 03:08 |
hmmmmm |
here i'm trying to treat it like an opaque type |
| 03:08 |
kaeza |
you'd prolly want local p = { x=above.x, ... } |
| 03:09 |
VanessaE |
hmmmmm, what are you trying to do, ultimately? |
| 03:09 |
Exio |
he is writing the lua mapgen, i guess |
| 03:09 |
hmmmmm |
just test out this dumb thing |
| 03:10 |
hmmmmm |
thanks kaez |
| 03:10 |
hmmmmm |
a |
| 03:10 |
VanessaE |
ahhh |
| 03:10 |
hmmmmm |
wow, i can't believe how retarded this is |
| 03:10 |
kaeza |
hmmmmm, np |
| 03:10 |
kaeza |
as VanessaE said, it can lead to weird bugs in code |
| 03:10 |
VanessaE |
hmmmmm: still think "every little thing" doesn't belong in the engine now? :) |
| 03:11 |
VanessaE |
(that was a joke. it's funny. laugh.) |
| 03:14 |
hmmmmm |
well at least my code worked |
| 03:16 |
hmmmmm |
so erm, just wondering anyway, does lua have += and -= operators? |
| 03:16 |
kaeza |
nope :< |
| 03:16 |
hmmmmm |
it's really annoying having to repeat myself in the code |
| 03:16 |
kaeza |
and don't even try to suggest the idea in #lua |
| 03:17 |
kaeza |
-> permaban |
| 03:17 |
VanessaE |
wait, I though it did have those? |
| 03:17 |
kaeza |
not in stock Lua at least |
| 03:17 |
VanessaE |
huh. I guess not. |
| 03:18 |
kahrl |
http://forum.minetest.net/viewtopic.php?id=4952 |
| 03:19 |
kahrl |
oh wait, you mean for scalars? |
| 03:19 |
|
arsdragonfly joined #minetest-dev |
| 03:19 |
hmmmmm |
that's a cute class, i guess, but it's not very helpful as there's no language integration and it adds a dependency |
| 03:20 |
VanessaE |
kaeza: one I wish it did have was != (because ~= is harder to spot and makes less sense) |
| 03:20 |
kaeza |
+1 to that |
| 03:20 |
hmmmmm |
someone ought to make a scripting language with C++ syntax and static typing, and not perl |
| 03:21 |
kaeza |
AngelScript |
| 03:21 |
VanessaE |
bash :P |
| 03:21 |
hmmmmm |
bash script for gamedev |
| 03:21 |
VanessaE |
(well maybe not, but the syntax is at least close to C) |
| 03:21 |
hmmmmm |
top lel m80 |
| 03:21 |
kaeza |
http://www.angelcode.com/angelscript/ |
| 03:22 |
hmmmmm |
wonder how fast it is in comparison to lua |
| 03:23 |
kaeza |
could be useful to overcomplicate stuff and make a neutral API to which you could plug other scripting languages |
| 03:23 |
hmmmmm |
and what's the difference between foo:bar and foo.bar in lua exactly? foo:bar is for methods, foo.bar is for members, but if you can call methods with . over :, what's the point ..? |
| 03:23 |
kaeza |
ehh no |
| 03:24 |
VanessaE |
hmmmmm: I use : versus . was more of a reminder |
| 03:24 |
VanessaE |
s/was/as/ |
| 03:24 |
kaeza |
foo:bar() is syntactic sugar for foo.bar(foo) |
| 03:24 |
hmmmmm |
ahhh. |
| 03:24 |
VanessaE |
I prefer to call functions et.al using foo:bar() because it reads cleaner to my mind |
| 03:24 |
hmmmmm |
so foo:bar is really a method call and foo.bar is just bar using the namespace foo |
| 03:24 |
hmmmmm |
thank you, that makes a lot of sense. |
| 03:24 |
VanessaE |
and foo.bar for reading/writing individual table elements |
| 03:25 |
kaeza |
(in addition, 'foo' is somewhat optimized by the interpreter) |
| 03:25 |
kaeza |
(in the case of foo:bar() ) |
| 03:38 |
hmmmmm |
kaeza, according to the section starting "Now, when we call the method..." http://www.lua.org/pil/16.html it does a1 = Account; Account = nil, then uses a1 right after. this doesn't happen if you use self. instead of the global object name, however - why? when does Lua decide to do a deep copy of tables? |
| 03:38 |
hmmmmm |
this seems ridiculously arbitrary to me |
| 03:39 |
kaeza |
ehm |
| 03:39 |
VanessaE |
hmmmmm: afaik it never does |
| 03:40 |
kaeza |
they are just references |
| 03:40 |
hmmmmm |
then why is a1 = Account; Account = nil, a1:foobar() allowed? |
| 03:40 |
kaeza |
local a = { foo="bar" }; b = a; a = nil; print(dump(b)) -> { foo="bar" } |
| 03:40 |
kaeza |
yes |
| 03:41 |
kaeza |
there is a table referenced by variable 'Account' |
| 03:41 |
kaeza |
the reference count is incremented when asigned to a1 |
| 03:41 |
kaeza |
and decremented when Accont is set to nil |
| 03:41 |
hmmmmm |
i see |
| 03:42 |
kaeza |
you still have a reference in a1 |
| 03:42 |
hmmmmm |
how do i make a completely new object? |
| 03:42 |
kaeza |
you have to copy it manually |
| 03:42 |
hmmmmm |
figured |
| 03:42 |
kaeza |
give me a second |
| 03:42 |
hmmmmm |
i know |
| 03:42 |
hmmmmm |
foreach pairs(k,v) in Account do blahblah |
| 03:43 |
kaeza |
yep |
| 03:43 |
kaeza |
ehh no |
| 03:43 |
hmmmmm |
would've figured there's a convenience function for that in lua |
| 03:43 |
VanessaE |
somewhere in the PiL there is a proper deep copy routine |
| 03:43 |
kaeza |
for k,v in pairs(t) do newt[k] = v end |
| 03:43 |
hmmmmm |
kaeza, yeah. |
| 03:43 |
hmmmmm |
hmm |
| 03:44 |
kaeza |
actually, hmm |
| 03:44 |
hmmmmm |
I hate lua so much |
| 03:44 |
hmmmmm |
why am i doing this |
| 03:44 |
hmmmmm |
why don't i just give it to somebody else to do this part |
| 03:44 |
kaeza |
to create a new table from scratch, you use foo = {} |
| 03:44 |
hmmmmm |
yes |
| 03:44 |
hmmmmm |
hahahahahaha |
| 03:44 |
hmmmmm |
wouldn't it be funny if foo = {} added a reference to the table {}? |
| 03:44 |
VanessaE |
hmmmmm: because if it's Lua, the only other person who's gonna touch it is pilz and he....has his own ways of doing stuff |
| 03:44 |
hmmmmm |
true. |
| 03:45 |
|
ch98 joined #minetest-dev |
| 03:46 |
hmmmmm |
setmetatable(a, {__index = b}) |
| 03:47 |
hmmmmm |
alright, now things are getting less crap |
| 03:47 |
kaeza |
heh |
| 03:48 |
kaeza |
thought you didn't like operator stuff from C++ cause it tended to hide side-effects |
| 03:49 |
hmmmmm |
vector +, - and = are probably the only exceptions, merely because you know exactly what to expect from them |
| 03:49 |
hmmmmm |
it's the wackier things that people do, and overloading = is especially bad. some people like overloading = though |
| 03:50 |
hmmmmm |
i mean == for the former |
| 03:50 |
kaeza |
well, I'm used to Lua, so I'd expect a = b to pass a reference (or a pointer in plain C) rather than copying |
| 03:51 |
kaeza |
but I agree to the vector stuff |
| 03:52 |
|
Miner_48er joined #minetest-dev |
| 03:55 |
Rath |
why does the for loop on line 409 in nodedef.cpp use 0xffff intead of MAX_CONTENT ? |
| 03:57 |
hmmmmm |
because celeron added an extra f |
| 03:58 |
hmmmmm |
not that it matters, since there's the assert (c <= MAX_CONTENT) in INodeDefManager::set() |
| 03:59 |
hmmmmm |
oh, nevermind, that's a bug. |
| 04:00 |
kaeza |
suddenly: no more bugs in MT |
| 04:01 |
Exio |
someone told me a bit ago "every time i find a bug, i look around because there are 10 more" |
| 04:06 |
VanessaE |
oh not this subject again. |
| 04:40 |
|
salamanderrake joined #minetest-dev |
| 04:44 |
|
neko259 joined #minetest-dev |
| 04:53 |
hmmmmm |
i guess at this point i could commit what i have |
| 04:53 |
hmmmmm |
nah |
| 04:53 |
VanessaE |
I'm almost afraid to look :P |
| 04:54 |
hmmmmm |
i think i'm going to make a series of commits but push them at the same time. that way it can stay neat and in order, but people won't jump on it all at once |
| 04:55 |
VanessaE |
translation: "I think I'll make some attempt to hide my nasty code under a bunch of other changes" ;) |
| 04:55 |
hmmmmm |
so right now i just need to pass one of these objects to on_generate() and make my perlin noise maps flag |
| 04:55 |
hmmmmm |
s/flag/flat/ |
| 04:56 |
hmmmmm |
not sure what i was thinking when i made them actually 2d and 3d tables... |
| 04:56 |
hmmmmm |
in fact i don't think anybody ever used them in mods |
| 04:56 |
hmmmmm |
and then i'll make the demonstration mapgen |
| 05:21 |
|
ch98 joined #minetest-dev |
| 06:19 |
|
darkrose joined #minetest-dev |
| 06:28 |
hmmmmm |
aaaaaaha! |
| 06:28 |
hmmmmm |
i got your bug kahrl |
| 06:29 |
hmmmmm |
it has absolutely nothing to do with the block being loaded or unloaded or whatever |
| 06:29 |
hmmmmm |
now if only i can figure out how to reproduce this |
| 06:32 |
hmmmmm |
it happens after a period of high latency |
| 06:33 |
hmmmmm |
i have the lock, no idea why that would happen... |
| 06:40 |
|
diemartin joined #minetest-dev |
| 06:42 |
hmmmmm |
also very occasionally, pitch black shadows form over the block where it failed to spawn |
| 06:42 |
hmmmmm |
sounds familiar? *cough* tree lighting bug |
| 06:48 |
|
diemartin joined #minetest-dev |
| 07:01 |
hmmmmm |
alright; for some reason the data doesn't exist when this happens. i would say that it's a air that wasn't loaded and we can't see it, but that's just not possible because i'd see a lower layer of nodes at least |
| 07:02 |
hmmmmm |
both Map::getBlockNoCreateNoEx() returns NULL and VMANIP_BLOCK_DATA_INEXIST on the blocks in question when this happens; yet the blocks are clearly there |
| 07:05 |
hmmmmm |
so it's either a dummy block or not present in the sector |
| 07:10 |
hmmmmm |
the only explanation is that the server removed that block from memory while the client still has it |
| 07:56 |
|
Calinou joined #minetest-dev |
| 07:56 |
celeron55 |
hmmmmm: that totally can happen, there's nothing to guard against such |
| 07:58 |
celeron55 |
this once again means that minetest would need something to allow synchronous loading of blocks for special cases |
| 08:03 |
|
iqualfragile joined #minetest-dev |
| 08:55 |
|
darkrose joined #minetest-dev |
| 09:34 |
|
proller joined #minetest-dev |
| 09:48 |
|
iqualfragile joined #minetest-dev |
| 10:42 |
|
Calinou joined #minetest-dev |
| 10:54 |
|
Zeg9 joined #minetest-dev |
| 11:06 |
|
ImQ009 joined #minetest-dev |
| 11:53 |
|
PilzAdam joined #minetest-dev |
| 12:00 |
|
ironzorg joined #minetest-dev |
| 12:16 |
|
proller joined #minetest-dev |
| 12:48 |
|
NakedFury joined #minetest-dev |
| 13:09 |
|
PilzAdam joined #minetest-dev |
| 13:47 |
|
PilzAdam joined #minetest-dev |
| 14:16 |
|
dzho joined #minetest-dev |
| 14:33 |
|
hmmmm joined #minetest-dev |
| 14:35 |
|
dzho joined #minetest-dev |
| 14:41 |
hmmmm |
right |
| 14:41 |
hmmmm |
minetest has synchronous loading of blocks, just not generation |
| 14:42 |
hmmmm |
i changed this a long time ago, if it can't find the block on disk, it'll create one full of content ignore |
| 14:43 |
|
ironzorg` joined #minetest-dev |
| 14:43 |
hmmmm |
this way you have a block to work with where you can place your nodes and they'll still be there after map generation |
| 14:44 |
hmmmm |
so the solution i figure, is to extent vmanip's initialEmerge and emerge to load blocks or create a blank instead of marking it as inexistent |
| 14:45 |
hmmmm |
this would fix every instance of this problem.... saplings growing into trees, the place_schematic problem, and my current problem |
| 14:45 |
PilzAdam |
hmmmm, I had a new idea about the snow: the nodebox could be extended to add so that there is a layer that covers the node under it (like this: https://gist.github.com/PilzAdam/5859007; https://www.dropbox.com/s/xag8v7q0st4yz2b/Snow.png) |
| 14:45 |
PilzAdam |
-to add |
| 14:46 |
PilzAdam |
the problem with this is that there are rendering glitches if the d < 0.55; but everything > 0.51 doesnt look good |
| 14:46 |
hmmmm |
it looks nice enough i suppose, but that's still a hack |
| 14:47 |
PilzAdam |
a not hacky way would be to change the texture of the node under it at runtime |
| 14:47 |
hmmmm |
also doesn't overuse of nodeboxes decrease performance |
| 14:48 |
PilzAdam |
but since we cant do this currently thats the best way so far |
| 14:48 |
PilzAdam |
this only has 5 nodeboxes per node; pipeworks for example has 90 or so per node |
| 14:49 |
|
sfan5 joined #minetest-dev |
| 14:49 |
PilzAdam |
and the snow could be changed to only use 1 nodebox |
| 14:53 |
PilzAdam |
the rendering glitches appear at a distance of > 10 nodes |
| 14:54 |
|
Anchakor joined #minetest-dev |
| 14:57 |
|
Jordach joined #minetest-dev |
| 14:59 |
celeron55 |
that rendering glitch could probably be largely solved by implementing a properly dynamic near depth value |
| 15:00 |
celeron55 |
try if increasing the value given to cam->setNearValue() in camera.cpp helps it |
| 15:01 |
celeron55 |
(i'd maybe prefer modifying the textures of the nodes under snow at mesh generation time, if it's reasonably doable) |
| 15:14 |
|
Calinou joined #minetest-dev |
| 15:32 |
hmmmm |
oooh heh |
| 15:32 |
hmmmm |
seems like the completely black shadow bug isn't caused by this |
| 15:33 |
hmmmm |
too bad i can't readily reproduce such a thing, i assume it'll work if i set it to load on inexistent block in updateLighting as well |
| 15:33 |
hmmmm |
on the other hand, blitting the data itself is reliable |
| 15:39 |
|
toabi_ joined #minetest-dev |
| 15:42 |
|
dexter0 joined #minetest-dev |
| 15:42 |
hmmmm |
http://oi44.tinypic.com/2mmvmub.jpg |
| 15:44 |
Jordach |
is THAT MGV7 |
| 15:44 |
hmmmm |
yeah, but that's not the point of the picture... :p |
| 15:45 |
Jordach |
looks awesome |
| 15:45 |
Jordach |
so these bubbles are to prove what? |
| 15:46 |
hmmmm |
i fixed the missing block/pitch black lighting issue for trees growing into saplings and decoration placement |
| 15:47 |
Jordach |
\o/ OMFG |
| 15:47 |
Jordach |
finally |
| 15:48 |
|
sapier1 joined #minetest-dev |
| 15:50 |
sfan5 |
Jordach: ? |
| 15:50 |
Jordach |
<hmmmm> i fixed the missing block/pitch black lighting issue for trees growing |
| 15:51 |
sfan5 |
oh ok |
| 15:58 |
sapier1 |
is anyone investigating the punch fps problem vanessae found? |
| 16:04 |
hmmmm |
nope |
| 16:04 |
hmmmm |
i told her it'd be helpful if she found the exact commit where the regression started.... that'd be helpful |
| 16:04 |
hmmmm |
https://github.com/kwolekr/minetest/commit/98c7c7aedf0df0bf34a2dffe7636266ee1f81648 |
| 16:05 |
hmmmm |
https://github.com/kwolekr/minetest/commit/fcc453ccd8be469a1f09e6e17c763f9a179a71ad |
| 16:07 |
sapier1 |
are you sure "manip" is correct term for this interface? |
| 16:07 |
hmmmm |
yup, why not? |
| 16:07 |
hmmmm |
is it a german curse word or something? |
| 16:07 |
Jordach |
hmmmm, i'll take a look for her |
| 16:07 |
sapier1 |
I'd expect a manip to modify something but this looks more like chunk save restore |
| 16:08 |
hmmmm |
well, i didn't come up with "manipulator", i just came up with the shortened version that sounds better |
| 16:08 |
Jordach |
hmmmm, 0.4.1 i remember had them |
| 16:09 |
hmmmm |
Jordach, to find the specific commit, figure the points at which you're absolutely sure the bug wasn't there, and you're absolutely sure the bug was there |
| 16:09 |
sapier1 |
I guess there's exactly one mod benefiting from this |
| 16:10 |
hmmmm |
then take the middle of those two commits, see if it's present there |
| 16:10 |
hmmmm |
if not, check the middle between that commit and the last one |
| 16:10 |
hmmmm |
so on and so forth |
| 16:10 |
hmmmm |
sapier, any mod that writes to the map a lot |
| 16:11 |
sapier1 |
how to create data that can be written? |
| 16:11 |
hmmmm |
you read the chunk, make the modifications, then write it back |
| 16:11 |
hmmmm |
the data that's being written is just a huge, flat table of content ids |
| 16:11 |
sapier1 |
yes but how to modify it? maybe I just missed that? |
| 16:12 |
|
proller joined #minetest-dev |
| 16:12 |
hmmmm |
local c_cobble minetest.get_content_id("default:cobble"); data[a.index(x, y, z)] = c_cobble; |
| 16:13 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 16:13 |
|
dexter0 joined #minetest-dev |
| 16:13 |
hmmmm |
also i ported VoxelArea to Lua |
| 16:13 |
sapier1 |
ok missed that I'll take back what I said it's really a manip |
| 16:14 |
sapier1 |
would be good to hava a small example in doc |
| 16:14 |
hmmmm |
we don't have examples in the documentation |
| 16:14 |
sapier1 |
any chance to avoid bothering user with the ids? |
| 16:14 |
hmmmm |
i plan on having a demonstration mod for this reason |
| 16:15 |
hmmmm |
and yeah, i was thinking of maybe putting in an "easy mode" that's a bit slower but you only need to specify the node name |
| 16:16 |
Jordach |
hmmmm, https://github.com/minetest/minetest_game/commit/dd9b33db6743812f33bcfe97910d9a110fb0b4f9 and https://github.com/minetest/minetest/commit/506203345ba2795aa0af68a434f4b77cf50e664a |
| 16:16 |
|
Zeg9_ joined #minetest-dev |
| 16:16 |
Jordach |
THOSE are the two commits VanessaE was talking about |
| 16:16 |
hmmmm |
wow |
| 16:16 |
Jordach |
one for when the chests got moveed |
| 16:16 |
sapier1 |
yes I guess if youz cache id/name mapping within lua it's not that much slower |
| 16:16 |
Jordach |
and when the formspec got added |
| 16:17 |
|
ironzo joined #minetest-dev |
| 16:17 |
Jordach |
have a poke about for it |
| 16:17 |
hmmmm |
sapier, i'm thinking more or less the extraneous cpu time being spent on meaningless string copy and manipulation |
| 16:18 |
hmmmm |
hmm, jordach, maybe that's what vanessa was talking about, but i honestly don't see anything there that would cause such a bug |
| 16:18 |
Jordach |
hmmmm, I think parsing of the chest / furnaces take their time |
| 16:18 |
sapier1 |
we are talking about the la bug? |
| 16:18 |
hmmmm |
did you actually try out minetest at this specific commit and verify that the problem is present, and the commit before that and saw that it wasn't there? |
| 16:18 |
Jordach |
sapier1, yes |
| 16:18 |
Jordach |
hmmmm, i don't have 0.4.1 and 0.4.2 |
| 16:19 |
hmmmm |
...compile |
| 16:19 |
sapier1 |
can_dig? |
| 16:19 |
Jordach |
hmmmm, its just easier as i dont have debugging tools |
| 16:19 |
hmmmm |
easier for you maybe |
| 16:19 |
Jordach |
hmmmm, we also have git tags |
| 16:20 |
hmmmm |
none of this is really helpful as i need to see actual code that would have caused this effect |
| 16:20 |
hmmmm |
i can't pull a solution out of thin air |
| 16:20 |
Jordach |
VanessaE stated that it happened when the nodemeta came about |
| 16:21 |
Exio |
if you don't try that commit and the one *before* it, you are just guessing |
| 16:21 |
Jordach |
i might think that nodemeta might be screwing with node prediction a tad |
| 16:21 |
Exio |
what can mean, that is not true == wasted time |
| 16:21 |
Jordach |
Exio, process of elimination |
| 16:27 |
sapier1 |
hmm did anyone already check if mouse beeing hold down causes cyclic events? |
| 16:28 |
sapier1 |
if it does we're most likely running line 1135 everytime |
| 16:28 |
celeron55 |
stop asking and start testing, goddamnit |
| 16:28 |
celeron55 |
and no it doesn't, as far as i tested it |
| 16:28 |
celeron55 |
i don't have latest git on this laptop though and won't bother building it because it's so slow |
| 16:28 |
sapier1 |
celeron55 it's not worth testing something that already has been ruled out |
| 16:29 |
celeron55 |
is there a github issue for this? |
| 16:29 |
celeron55 |
1) if there isn't, there should be, 2) if there is, everything should be also written in there |
| 16:29 |
celeron55 |
also those who the problem affects are responsible for filling it out |
| 16:30 |
sapier1 |
at least no one referenced one the last days but yes you're right |
| 16:30 |
celeron55 |
(if they aren't going to fix it, then they should at least help as much as they can) |
| 16:32 |
sapier1 |
no there isn't a issue on github |
| 16:33 |
Jordach |
actually, I've just spotted something |
| 16:33 |
Jordach |
you know the node animations, they take up quite a few resources |
| 16:34 |
sapier1 |
the crack updates? |
| 16:34 |
Jordach |
yes |
| 16:34 |
Jordach |
because at the end of it, it removes the node + anim |
| 16:34 |
sapier1 |
where's the code? |
| 16:36 |
Jordach |
sapier1, its also strange that any server with rtt = < 0.1xx |
| 16:36 |
Jordach |
any dug nodes re-appear then disappear |
| 16:37 |
Jordach |
but some stay as if you never touched it |
| 16:37 |
sapier1 |
that's a behaviour that happened quite often when mobf did use abms to spawn mobs |
| 16:38 |
sapier1 |
i guess it's related to "long" steplengths on server |
| 16:44 |
hmmmm |
am i going mad, or is there a huge memory leak since finishBlockMake doesn't delete the voxel manipulator |
| 16:45 |
Exio |
try a free() |
| 16:45 |
Exio |
if minetest crashes, no! |
| 16:45 |
Exio |
i think doing that will be faster than trying with valgrind |
| 16:47 |
hmmmm |
the reason why i ask is because minetest was run under valgrind just recently by like three different people, and it would've been caught |
| 16:48 |
sapier1 |
if none of them created a voxel manip valgrind can't show an error ;-) |
| 16:48 |
hmmmm |
they ran minetest, yes? |
| 16:48 |
hmmmm |
they emerged map |
| 16:48 |
sapier1 |
oh you're not talking about the thing in api |
| 16:50 |
hmmmm |
ah |
| 16:50 |
|
neko259 joined #minetest-dev |
| 16:50 |
hmmmm |
the only way it gets cleaned up is by falling out of scope |
| 16:50 |
hmmmm |
that's really.. hidden... if you ask me |
| 16:51 |
PilzAdam |
celeron55, cam->setNearValue() doesnt really help |
| 16:51 |
sapier1 |
falling out of scope is perfectly ok if an object has a valid destructore |
| 16:52 |
hmmmm |
sapier, you're all about super-defensive coding, how do you possibly like using C++ for mission critical embedded things? |
| 16:52 |
celeron55 |
PilzAdam: eg. 1.0 makes no practical difference? |
| 16:52 |
PilzAdam |
nope |
| 16:52 |
celeron55 |
well no luck then :P |
| 16:53 |
sapier1 |
if you stick to avoid some language elements c++ isn't that bad ;-) and con/destructors are very very safe things if done right |
| 16:53 |
celeron55 |
hmmmm: any object in C++ should be coded so that falling out of scope cleans it up properly |
| 16:54 |
celeron55 |
anything else is bullshit |
| 16:54 |
hmmmm |
explicitly deleting things is bullshit? |
| 16:55 |
celeron55 |
if you dynamically allocate something, then you delete it (usually in the same function or destructor of some owner object) |
| 16:55 |
sapier1 |
hmmm you can't delete a stack object "explicitly" |
| 16:56 |
hmmmm |
BlockMakeData looks like really simple struct and has the potential to fool someone who isn't thinking in C++ mode |
| 16:57 |
hmmmm |
+a |
| 17:00 |
celeron55 |
i don't think it's worth it to take in use any conventions to mark whether structs manage their memory themselves or not |
| 17:01 |
PilzAdam |
celeron55, oh, wait, I was modifying the value of the camera for the wielditem |
| 17:01 |
PilzAdam |
setting it to 4.0 for the other camera removes the glitches completly |
| 17:02 |
PilzAdam |
(it was the default value (1.0) previosly) |
| 17:02 |
celeron55 |
that'll make you able to easily look through walls by walking near them though 8) |
| 17:02 |
hmmmm |
hmmmm |
| 17:02 |
hmmmm |
celeron, is there a reason why you added minetest.get_perlin()? |
| 17:02 |
celeron55 |
it's need some code to scale it based on how close is the nearest thing to the camera (that's what all 3D things should do, but many are lazy) |
| 17:03 |
celeron55 |
it'd* |
| 17:03 |
PilzAdam |
3.0 works too, and you cant look through walls with that |
| 17:03 |
celeron55 |
hmmmm: is there a reason why you think it shouldn't exist? |
| 17:04 |
celeron55 |
PilzAdam: jumping towards ceiling will still work |
| 17:04 |
hmmmm |
i think it should've been implemented in lua |
| 17:04 |
PilzAdam |
celeron55, it also works with 1.0 (wich we have currently) |
| 17:04 |
celeron55 |
hmmmm: can't remember |
| 17:05 |
PilzAdam |
0 is a nice wallhack ;-) |
| 17:05 |
hmmmm |
meh |
| 17:05 |
hmmmm |
i'll make a wrapper for VoxelManip:read_chunk() |
| 17:05 |
celeron55 |
hmmmm: could have been something like wanting to make it behave exactly like what C++ gets with the same seed difference |
| 17:05 |
hmmmm |
it'll create a VoxelArea and add it in there and all sorts of other convenient things |
| 17:05 |
celeron55 |
if done in lua, variables can wrap differently |
| 17:05 |
hmmmm |
that makes sense i guess |
| 17:08 |
|
sokomine joined #minetest-dev |
| 17:10 |
|
ssieb joined #minetest-dev |
| 17:11 |
Taoki |
hmmmm: Thanks for the script last night. Managed to yry v7 and it's looking pretty good. Although I can see where it needs more work, but I'm glad I got to test it :) |
| 17:11 |
hmmmm |
yep, and i'm not working on it at the moment |
| 17:11 |
hmmmm |
i have other things |
| 17:11 |
Taoki |
Only curiosity is if I can enable spawning of trees yet. Or if that's not implemented currently |
| 17:12 |
Taoki |
ok |
| 17:12 |
hmmmm |
oh, i didn't give you the tree schematic |
| 17:12 |
Taoki |
Ah, there's a separate one for that? Sure, I'd like that too then |
| 17:13 |
Taoki |
If I can get trees working I think I can leave it enabled on my server, since it's good enough apart from some noise / design issues |
| 17:13 |
Taoki |
eg: Floating cave tops and lots of air holes in water. Other than that it feels complete to me otherwise |
| 17:14 |
hmmmm |
http://www.filedropper.com/treewprob |
| 17:15 |
Taoki |
.mts? What folder do these go in? |
| 17:15 |
hmmmm |
ever since omploader vanished, i've been in the market for a new file upload site... |
| 17:15 |
hmmmm |
the way i have it set up, the current working directory |
| 17:16 |
Taoki |
So the root GIT folder? |
| 17:16 |
hmmmm |
the minetest folder that is one level up from the location of the executable |
| 17:18 |
Taoki |
Placed it there but nothing happens. I assume a Lua function is needed to point at the file |
| 17:19 |
hmmmm |
i had it included with the biomes |
| 17:20 |
Taoki |
Ah, I see it there now. It has no path, so it means it's trying to run it from the same folder as the binary most likely. Will fix |
| 17:20 |
Taoki |
Thanks |
| 17:22 |
Taoki |
Works now. But why is it a binary file? How are mts schematics generated? |
| 17:22 |
Taoki |
Might be useful to know |
| 17:22 |
hmmmm |
you can create them using minetest.create_schematic() |
| 17:23 |
Taoki |
oh,,, good to know |
| 17:23 |
hmmmm |
there's a worldedit command for this, //mtschemcreate |
| 17:23 |
sokomine |
those schematics can also be used by the speedy-gonzales branch of worldedit. that works fine already (at least when the area is loaded). uberi introduced it yesterday |
| 17:24 |
sokomine |
ah, hmmm was faster |
| 17:25 |
sokomine |
there is, however, a problem with them: if a furnace is included (perhaps only an active one?), the game will crash after //mtschemeplace because the metadata is empty |
| 17:26 |
|
Miner_48er joined #minetest-dev |
| 17:26 |
sokomine |
changing line 982 in minetest_game/mods/default to "if not( fuel) or fuel.time <= 0 then" solves the problem |
| 17:27 |
Exio |
i think a pull request for that could be pretty nice? |
| 17:27 |
Taoki |
Hopefully that will be fixed in GIT |
| 17:27 |
sokomine |
hm. a pull request for such a small change? wouldn't that be considered spam? |
| 17:29 |
|
khonkhortisan joined #minetest-dev |
| 17:29 |
|
Naked joined #minetest-dev |
| 17:31 |
PilzAdam |
sokomine, that fixes the crash but makes the furnace not usable |
| 17:32 |
PilzAdam |
hmmmm, any chance to call on_construct of nodes that are placed by place_schematic()? |
| 17:32 |
hmmmm |
PilzAdam, no. |
| 17:33 |
PilzAdam |
then you break every node that uses metadata |
| 17:33 |
hmmmm |
:/ |
| 17:33 |
hmmmm |
i was hoping that a mod knows about nodes that have metadata |
| 17:36 |
PilzAdam |
all nodes that have an inventory set the size of the lists in on_construct() |
| 17:41 |
hmmmm |
it seems to me that everybody believes that new lua api are new features of minetest |
| 17:41 |
hmmmm |
all an api does is exposes something from the engine |
| 17:42 |
hmmmm |
or speeds up something that would've otherwise been restrictively slow |
| 17:42 |
hmmmm |
so, no, new api won't be complete and handle every corner case like node metadata, it's just a thin wrapper |
| 17:43 |
hmmmm |
and i explicitly refuse to deal with metadata in schematics for a couple reasons |
| 17:44 |
hmmmm |
the biggest being the intent. you're using schematics for transferring data between worlds, but it's intended to be a way to create a schematic file, for use in the schematic decoration type |
| 17:44 |
hmmmm |
it was never intended to be used in the manner you're using it |
| 17:46 |
PilzAdam |
I dont want you to save metadata in the file |
| 17:46 |
sokomine |
the copying between worlds was just a testcase. and, in a way, the schematics we'll use for decoration will have to be built somewhere - in the world of the mod developer - and will be used by those who use the schematic in their worlds, so transfer to other worlds is the expected usage |
| 17:46 |
hmmmm |
if you can use it in the manner you'd like to, that's a convenient plus, but i am under absolutely no obligation to handle your problem that occurs when it doesn't work the way you want it to work |
| 17:46 |
sokomine |
not handling metadata is understandable |
| 17:47 |
sokomine |
no, you are under no obligation at all. you're all doing this for free, for the benefit of others. but that's the problem with users: they may like something you did :-) and request more |
| 17:48 |
hmmmm |
glad you like it :-)! i'm not making more |
| 17:48 |
PilzAdam |
hmmmm, the problem is that lua-api.txt gives a guarantee that on_construct() is called when the node is placed in the worl (except mapgen) |
| 17:48 |
PilzAdam |
+d |
| 17:48 |
sokomine |
no chance for that rotation-feature? *looking hopefully* or that node-replacement-feature? |
| 17:49 |
hmmmm |
should change "except mapgen" to "bulk writes" |
| 17:49 |
ShadowNinja |
sokomine: Very puesdo-codey for (x, y, z) get_node(pos) node.on_construct(pos) end |
| 17:49 |
hmmmm |
that was an easy promise to keep when you only had heavyweight api like set_node() that does everything |
| 17:49 |
hmmmm |
sokomine, rotation is planned |
| 17:49 |
PilzAdam |
ShadowNinja, WE could do that |
| 17:49 |
hmmmm |
it's only going to be along the vertical axis however |
| 17:50 |
sapier1 |
hmmmm which of the at least 2 entity rotation variants? I hope both |
| 17:50 |
celeron55 |
on_construct should always be called; there are no excuses for that |
| 17:50 |
sokomine |
that sounds good! rotation will be very helpful for all kind of rotation |
| 17:50 |
hmmmm |
...seriously? |
| 17:50 |
hmmmm |
celeron, i can come up with three undeniable excuses right now off the top of my head |
| 17:51 |
celeron55 |
it is explicitly in there exactly to allow nodes to have code that is always run, compared to on_place or such |
| 17:51 |
sokomine |
no entity rotation. node rotation for the new schematic-functions |
| 17:51 |
celeron55 |
because some nodes just can't work otherwise |
| 17:51 |
celeron55 |
by design |
| 17:51 |
hmmmm |
and those nodes that have code should be specially handled |
| 17:52 |
hmmmm |
any modder worth his weight should be able to find their special nodes, add the position to a list, and then call on_construct manually |
| 17:52 |
celeron55 |
IF a way is provided to handle them, then there is an excuse; but for example there is no way furnace code could currently make itself work after being created without on_construct and without horrible hacks, AFAIK |
| 17:52 |
hmmmm |
i'd be interested in somebody making a Lua hook or something to preserve metadata |
| 17:53 |
hmmmm |
all i did was expose part of the core to the Lua scripts via an API |
| 17:53 |
celeron55 |
there's no reason to not make it complete |
| 17:53 |
sapier1 |
rotation meaning e.g.45 degree rotated nodes or only 90 degree steps? |
| 17:53 |
hmmmm |
i am frankly not very interested in making it "easy to use" |
| 17:53 |
sokomine |
ask uberi. iirc worldedit had an extra function for it. until it switched to a mixed format where node- and metadata was in one table-like file |
| 17:53 |
hmmmm |
sapier, 90 degree steps only |
| 17:54 |
sapier1 |
ok good idea :-) |
| 17:54 |
celeron55 |
IS there a way a furnace can start operating when missing metadata? |
| 17:54 |
hmmmm |
i'd have to say that's a furnace bug |
| 17:54 |
celeron55 |
like, where does it get the first "tick" |
| 17:54 |
hmmmm |
why isn't it more robust? |
| 17:54 |
celeron55 |
is it *ABLE* to get it anywhere |
| 17:54 |
PilzAdam |
celeron55, it needs to detect the missing meta in the ABM and then init it there |
| 17:54 |
sapier1 |
what about extending on_place signature to parameter node/tableofnodes? |
| 17:55 |
celeron55 |
PilzAdam: okay, so that is handled for nodes that have ABM; now the question is, how about those that *don't* have ABM? |
| 17:55 |
celeron55 |
i.e. chests |
| 17:55 |
PilzAdam |
no non hack way |
| 17:55 |
celeron55 |
that should be fixed in some way |
| 17:56 |
PilzAdam |
a hack would be: catch on_rightclick() and set it there (on_rightclick() is only called if the formspec field is not set) |
| 17:56 |
sapier1 |
I suggest doing a single on_construct (per nodetype) passing a list of nodes of that type |
| 17:56 |
PilzAdam |
but it would mean the player has to rightclick it two times and wait for the server |
| 17:56 |
sapier1 |
ähh on_place of course |
| 17:57 |
sokomine |
the furnace is really only of intrest when it's supposed to do anything. most likely it will have a player nearby who's eagerly awaiting the result and will change the input of the furnace if needed |
| 17:57 |
hmmmm |
sapier, seems like a great idea for *lua* to do that and not the api |
| 17:57 |
celeron55 |
PilzAdam: is that acceptable? |
| 17:58 |
hmmmm |
these minor 'bookkeeping' type tasks are for lua, not the api |
| 17:58 |
sapier1 |
hmmmm my intention was to avoid doing maybe hundreds of single node lua calls from c++ |
| 17:58 |
sokomine |
chests also loose their functionality. that's not a big problem because that really is something the mod that uses the api function has to plug in - i.e. to fill the chests randomly, to assign them to someone etc (mostly this will be handled by a seperate chest node in my mod - i'm using a dummy for that anyway) |
| 17:58 |
PilzAdam |
celeron55, the problem is that every single mod will have to add these hacks too |
| 17:58 |
hmmmm |
sapier, right, we'd like to avoid doing that in C++ and that's one of the reasons |
| 17:58 |
hmmmm |
no overhead if you call it straight from lua |
| 17:59 |
celeron55 |
okay so, i assume we'll go hmmmm's way then |
| 17:59 |
celeron55 |
it means that the main public api must be a lua wrapper that provides reasonable means to automate on_constructs |
| 17:59 |
hmmmm |
nevermind that, the furnace should be fixed as well |
| 17:59 |
sapier1 |
hmmmm if we do already have all information in lua yes that'd be best |
| 18:00 |
hmmmm |
i would recommend going through the whole space with get_node() and doing something special if it's one of those nodes you're interested in |
| 18:00 |
hmmmm |
it's going to be dog slow anyway, so what's the difference? |
| 18:00 |
sapier1 |
alll get_node calls? are you crazy? |
| 18:00 |
hmmmm |
fppppt |
| 18:01 |
sapier1 |
I don't even know how often I do get_node in mobf |
| 18:01 |
sapier1 |
:-) |
| 18:01 |
hmmmm |
or luavoxelmanip |
| 18:01 |
celeron55 |
my main point is that if on_construct isn't called by default, the API is broken from the mod's standpoint because everytime previously the mod has been able to rely on that having been taken care of |
| 18:01 |
hmmmm |
like i said before |
| 18:01 |
hmmmm |
that was an easy promise to make back then when you only had heavyweight set_node calls |
| 18:02 |
sokomine |
is the new api function useful for mobf? the schematic only seems to be saved to a file. of course it would be very useful for spawning the trader homes |
| 18:02 |
celeron55 |
if the thing exposed by C++ can be wrapped in lua and presented as the preferred non-broken API and the "raw" C++ API given as something to get huge speeds with if the problems are understood, then it's ok to me |
| 18:02 |
sapier1 |
year forget about my comment I missread something :-) |
| 18:02 |
hmmmm |
append _raw? |
| 18:02 |
celeron55 |
something like that |
| 18:03 |
Taoki |
hmmmm: Oh... before I forget, regarding v7: I noticed that each biome has an option called terrain_type, which currently has values like "liquid" or "normal". When you'll be working on the mapgen again, can you please please make nether and floatlands part of that setting? Would help with that realms idea I mentioned some days ago |
| 18:03 |
sokomine |
perhaps you just ought to write it into the documentation of the api |
| 18:03 |
Taoki |
If you're going to do those either way (aether and nether), it would sound perfect to make them part of terrain_type |
| 18:03 |
hmmmm |
i'd rather we add a note in the documentation that says "this is a RAW api, here are the problems with it, use this wrapper instead if you can't handle it" |
| 18:03 |
Taoki |
Then by default one can define any min_height and max_height they want, and everyine is happy and has the realms they wish |
| 18:04 |
hmmmm |
taoki, if you saw that piece of code then you know what the answer is |
| 18:04 |
hmmmm |
no point in asking |
| 18:04 |
Taoki |
I only saw the function's use in the script. I'll go ahead and check it in the code actually |
| 18:04 |
* Taoki |
hopes that is good news :) |
| 18:05 |
sapier1 |
main question how big is the risk we gain huge speed in a rare case but add significat slowdown in common case? |
| 18:05 |
hmmmm |
oh.. |
| 18:05 |
hmmmm |
hold on a minute |
| 18:05 |
sokomine |
hmmm: yes, that's what i wanted to say. if a working wrapper is supplied - fine. but what we need is the speed gain through the new functions |
| 18:05 |
hmmmm |
i forgot to take that field out |
| 18:06 |
hmmmm |
yes, and the option is there to use the raw version if the modder wants to, so you have a choice between slow but very complete, and fast but doesn't get 100% of the work done |
| 18:06 |
hmmmm |
better than "here, slow as shit but it's REALLY easy to use!" and that's your only option |
| 18:06 |
celeron55 |
it is an important question that how wast the complete one is though |
| 18:06 |
celeron55 |
fast* |
| 18:06 |
hmmmm |
go profile it |
| 18:07 |
celeron55 |
but that can be improved later anyways |
| 18:07 |
Taoki |
Haha... checked it and the other options are indeed there like I imagined |
| 18:07 |
Taoki |
Awesome work hmmmm, that will prolly be helpful :) |
| 18:07 |
celeron55 |
there could be a C++ API to do a quick check whether a schematic contains nodes that have on_construct |
| 18:07 |
celeron55 |
so that the complete lua wrapper can do that first and skip slowness if it indeed is safe |
| 18:08 |
sokomine |
the main problem with spawning larger...areas/houses/whatever in mt is that it scales very badly. even more than the speed issue, the problem with add_node is that it only works in loaded areas. which makes life hard for people who want to place these things. the new function helps there |
| 18:08 |
celeron55 |
or whatever, don't mind the details for now (i'm quite ignorant on this thing as a whole) |
| 18:08 |
Taoki |
celeron55: Kept wanting to ask; Is the feature to adapt draw distance to FPS broken? I have min fps set to 60, but if I look toward some directions I still get 30. Isn't it supposed to adapt dymanically each frame? |
| 18:09 |
hmmmm |
yeah, celeron, that sounds good but you won't need a C++ api for that. again, VoxelManip |
| 18:09 |
celeron55 |
Taoki: how do you think it tries to adapt? |
| 18:10 |
Taoki |
celeron55: Thought it reads the FPS and decreases draw distance till it pops up past the minimum limit |
| 18:10 |
celeron55 |
it should work, but it's slow |
| 18:10 |
hmmmm |
how is it slow?? pure computational stuff like looping and checking numbers is fast enough in lua |
| 18:11 |
celeron55 |
(being *that* slow is a bug; but it can't be very fast because otherwise looking down from towers and such would cause terrible, horrible oscillation) |
| 18:11 |
celeron55 |
hmmmm: completely different thing |
| 18:11 |
hmmmm |
well that's the idea |
| 18:11 |
Taoki |
hmmmm: FPS / distance adaptation is a C++ client thing |
| 18:11 |
Taoki |
celeron55: I see. Hope the bug that makes it overly slow can be fixed |
| 18:11 |
hmmmm |
oh, you're talking about something separate. |
| 18:11 |
|
proller joined #minetest-dev |
| 18:12 |
PilzAdam |
Taoki, its not a bug |
| 18:12 |
Taoki |
ah |
| 18:12 |
VanessaE |
it's not so much a bug as a bad formula |
| 18:13 |
PilzAdam |
its not meant to instantly change the viewing range; it watches the FPS for some time |
| 18:13 |
Taoki |
I'd love the magic trick that would yeld me 60fps wherever I look, even if draw distance would switch quickly |
| 18:13 |
VanessaE |
it moves too slowly when the target fps is close to the real fps, which is a problem if the real fps is less than the target. |
| 18:13 |
PilzAdam |
so if you constantly look into the low-FPS direction then it will decrease the viewing range |
| 18:13 |
Taoki |
Would be a nice option to have in minetest.conf |
| 18:13 |
celeron55 |
VanessaE: it's not a bad formula; it's the best i could come up in like a month of tuning it in early MT development |
| 18:13 |
Taoki |
PilzAdam: I remember I left it looking into a 30 FPS area for a while and it did nothing. I'll try again |
| 18:14 |
celeron55 |
VanessaE: it's actually way better than anyone would come up with from scratch |
| 18:14 |
celeron55 |
it's just gotten out of tune somehow |
| 18:14 |
VanessaE |
it's a problem because it makes the engine stick with a low fps and long view distance for far too long when it shouldn't. |
| 18:14 |
Taoki |
Gonna leave it for a minute or two in an area where I hav eexactly 30 fps and see |
| 18:14 |
celeron55 |
again, if it bothers you, tune it |
| 18:15 |
VanessaE |
celeron55: "early MT development". and you've had HOW long to fix it? |
| 18:15 |
celeron55 |
it doesn't bother me so it's hard to fix it |
| 18:15 |
VanessaE |
that's my only gripe right there guys - I can't do shit to fix this, but you can, and you've had virtually forever to do it. |
| 18:15 |
celeron55 |
it behaves so differently depending on how fast a computer is and what is the ratio of GPU speed to CPU speed |
| 18:15 |
celeron55 |
i don't have a fast computer like you |
| 18:15 |
celeron55 |
so it's basically blind tuning |
| 18:16 |
VanessaE |
you said you did some time back, fast enough anyway to see these kinds of things happening. |
| 18:16 |
VanessaE |
but one which you don't use for MT, as I recall |
| 18:16 |
hmmmm |
i don't see any problem with that.... i have a very fast cpu compared to my gpu however |
| 18:16 |
celeron55 |
it's not nearly as fast as yours |
| 18:16 |
Taoki |
Been over 3 minutes, FPS still at 30. So it's certainly out of tune somewhere |
| 18:16 |
sokomine |
regarding fps...that "fps drops around spawn" due to too-many-objects (if i got that right? what pilzadam tested on menches server?) is something that ought to be fixed if possible. it makes mt slow |
| 18:17 |
PilzAdam |
sokomine, kahrl said he probably will look into the object duplication bug |
| 18:17 |
PilzAdam |
celeron55, VanessaE, the auto tuner works perfectly fine for me, with high-end GPU and CPU |
| 18:17 |
VanessaE |
PilzAdam: define "high end". |
| 18:18 |
PilzAdam |
GeForce GTX 460 and intel core i7 8 cores @ ~2.9 GHz |
| 18:18 |
sokomine |
that's fine! if he can use any help (i.e. shown servers where it happens) please just tell |
| 18:18 |
VanessaE |
2.8 Ghz 6-core Phenom II w/16GB + HD 6870 video w/1GB here. |
| 18:18 |
celeron55 |
VanessaE: camera.cpp: try adjusting min_time_per_range |
| 18:18 |
Taoki |
PilzAdam: Mine are pretty high-end too, but it doesn't work |
| 18:19 |
Taoki |
Well, it DOES make sure I don't go under 30 FPS at any moment. But I want it to make sure I don't go under 60 and set it to that. THAT doesn't work |
| 18:19 |
VanessaE |
celeron55: I looked at that code yesterday but wasn't able to really understand it at the time |
| 18:19 |
PilzAdam |
though, I dont use fancy leaves to cap the FPS drops in jungles |
| 18:19 |
celeron55 |
VanessaE: yes, the code would need some higher-level documentation to be understood, don't worry about that |
| 18:19 |
PilzAdam |
Taoki, set fps_min (or so) in minetest.conf to 60 |
| 18:19 |
celeron55 |
but try making that value lower |
| 18:19 |
VanessaE |
celeron55: you could try this yourself if you'd try using some high rez texture pack (any one, doesn't matter if HDX or not) and visit the spawn on my server. |
| 18:20 |
celeron55 |
VanessaE: i won't |
| 18:20 |
VanessaE |
you have to see how drastic the view range has to change to see what REALLY happens. |
| 18:20 |
VanessaE |
then you're lazy. |
| 18:20 |
Taoki |
PilzAdam: Wasn't it wanted_fps? That one is set to 60 |
| 18:20 |
celeron55 |
more of working on other things than lazy, and the computer that is fast enough to maybe show something isn't in use at the moment |
| 18:20 |
VanessaE |
idc if you actually try to TUNE the code, I care if you try to see it happen at all. |
| 18:20 |
VanessaE |
in other words, I care if you PLAY the damn game for two minutes to see it happen. That's it. |
| 18:21 |
celeron55 |
do you seriously think i haven't EVER seen that happen? |
| 18:21 |
celeron55 |
go to hell |
| 18:21 |
VanessaE |
besides, I'd think a slow computer would show it more. |
| 18:21 |
Taoki |
PilzAdam: In minetest.conf, the only options are fps_max and fps_wanted |
| 18:21 |
VanessaE |
celeron55: I'm not talking about minor changes in view distance because of a few trees here or there. I' |
| 18:21 |
celeron55 |
it's tuned for slow computers running at slow FPS requiring larger proportional viewing range changes per frame |
| 18:22 |
VanessaE |
I'm talking about changes on the order of 100-150 nodes' distance just by turning around and looking the other way. |
| 18:22 |
celeron55 |
VanessaE: if you won't try adjusting the value i mentioned, i'm not going to try to take this forward at all; just so that you know |
| 18:23 |
VanessaE |
celeron55: I've given up trying to help tune the engine, because you'll just reject my change anyway. |
| 18:23 |
|
tswett left #minetest-dev |
| 18:23 |
celeron55 |
VanessaE: so you don't expect anything from me either; good |
| 18:23 |
VanessaE |
so all I have left is to point out bugs and faults when I find them. |
| 18:24 |
proller |
on mountain maps peoples wants more range, like 200+ |
| 18:24 |
Exio |
PilzAdam: 8 cores? threads? what? |
| 18:24 |
Anchakor |
seriously C++ isn't that hard to learn :) |
| 18:24 |
Exio |
;P |
| 18:24 |
PilzAdam |
Exio, 4 hyperthreaded physical cores |
| 18:25 |
Exio |
8 threads then |
| 18:25 |
* Taoki |
wishes there wouldn't be so much conflict on the dev team and solutions could be found |
| 18:25 |
Taoki |
PilzAdam: Same on my machine. I've an i7, which is 4 cores and 8 threads (hyper-threading) |
| 18:25 |
hmmmm |
if everybody here had a very agreeable personality, the result would be a chaotic mess |
| 18:26 |
Jordach |
youre still forgetting one thing: minetest targets low-end machines |
| 18:26 |
Jordach |
not your i7s and Xeons |
| 18:26 |
Exio |
why should it target *only* low-end machines |
| 18:26 |
hmmmm |
minetest only runs well on this machine :/ |
| 18:26 |
hmmmm |
it's unplayable on my laptop |
| 18:26 |
Taoki |
Jordach: I don't think targets is the right word. More like aims to support. But true too |
| 18:26 |
Jordach |
it ran FINE on a > 1GHZ Tower |
| 18:26 |
VanessaE |
Exio: because at the time it was written, c55 only had a low-end laptop :P |
| 18:27 |
Exio |
VanessaE: i'm retyping the low-end |
| 18:27 |
VanessaE |
s/written/started/ |
| 18:27 |
Jordach |
you should fix memory leaks before adding any new feature. |
| 18:27 |
Exio |
Jordach: GHz doesn't mean anything man btw |
| 18:27 |
VanessaE |
Jordach: most have been fixed. |
| 18:27 |
Jordach |
Exio, it had 256mb of ram |
| 18:27 |
Exio |
Jordach: the only mem leaks "left" are in irrlicht iirc |
| 18:28 |
Jordach |
then do what optifine does. |
| 18:28 |
Exio |
Jordach: what version was it? |
| 18:28 |
Jordach |
0.2.x |
| 18:28 |
Jordach |
0.3.x had 21fps |
| 18:28 |
Jordach |
0.4.x has 12fps |
| 18:28 |
Jordach |
(0.2 had 30) |
| 18:28 |
VanessaE |
Jordach: same or equivalent map, same or equivalent game content? |
| 18:28 |
Anchakor |
seems like nobody is against finding a solution which works for all configs, problem is *somebody* bossing people arround to work on it |
| 18:29 |
Taoki |
I'm running latest GIT, and apparently FPS adaptation doesn't work the slightest |
| 18:29 |
Exio |
Jordach: i guess you are trolling then |
| 18:29 |
Jordach |
VanessaE, vanilla games |
| 18:29 |
Jordach |
new maps each time |
| 18:30 |
VanessaE |
Anchakor: no one's bossing anyone around - but I have to ask you seriously, how much time has to elapse between filing a bug report or issue, and expecting a fix for it? (assume a relatively simple issue) |
| 18:30 |
hmmmm |
why should you expect a fix for it anyway? |
| 18:30 |
hmmmm |
it's released without warranty |
| 18:30 |
VanessaE |
Jordach: to be fair, you'd need to compare exact equivalent maps/game content. |
| 18:30 |
celeron55 |
anything from zero to infinite; it's up to the details of finding a reasonable fix |
| 18:30 |
VanessaE |
hmmmm: "without warranty" does not mean "without any intent to fix bugs that are reported to us" |
| 18:31 |
VanessaE |
when I say "expect" in that sentence, I don't mean it the way you seem to have interpreted it. |
| 18:31 |
celeron55 |
VanessaE: seriously, what you say is full of bullshit; it's not like a bazillion of bugs hadn't been already fixed |
| 18:31 |
celeron55 |
i don't understand you at all |
| 18:31 |
hmmmm |
yeah, seriously, i've noticed it too |
| 18:31 |
hmmmm |
you have this holier-than-thou attitude like we're not doing crap here and you have all the answers and what not |
| 18:32 |
VanessaE |
*facepalm* |
| 18:32 |
Taoki |
:( |
| 18:32 |
hmmmm |
try developing minetest and then come back with the same attitude |
| 18:33 |
VanessaE |
which one of us is telling others to "go to hell" and calling names now? |
| 18:33 |
hmmmm |
neither? |
| 18:33 |
VanessaE |
[06-25 14:21] <celeron55> do you seriously think i haven't EVER seen that happen? |
| 18:33 |
VanessaE |
[06-25 14:21] <celeron55> go to hell |
| 18:33 |
hmmmm |
oh |
| 18:33 |
VanessaE |
yeah, "oh" |
| 18:34 |
VanessaE |
and you wonder why I seem to have an attitude????? |
| 18:34 |
hmmmm |
that was a page up |
| 18:34 |
celeron55 |
i did; and it's perfectly reasonable after the replies i got |
| 18:34 |
Taoki |
I think VanessaE means we could do even more about some things |
| 18:34 |
VanessaE |
Taoki is close. |
| 18:35 |
hmmmm |
i get what vanessa says |
| 18:35 |
VanessaE |
what I mean is the wrong things are getting the focus right now, if only because that's what is interesting to each of the people working on this project. |
| 18:35 |
hmmmm |
she says that we have this apathetic attitude about things that don't directly affect us, and we ought to fix everybody's problems |
| 18:36 |
hmmmm |
but ought is just ought, who says that something ought to be, and why is it "ought"? |
| 18:36 |
Taoki |
It is true that it's hard to work on something when you don't feel motivated enough on that feature. I can say that from experience |
| 18:36 |
Anchakor |
who wouldn't be pissed with being bossed around how he spends the free time he chooses to dedicate to what esentially is a hobby |
| 18:36 |
Taoki |
However, if a feature is broken, I do personally believe that's something to be urgently fixed (if it's an official feature in the engine) |
| 18:36 |
sokomine |
most of you do not seem to play the game much. that's understandable - there's only so much time you can spend on anything. the game got improved a lot in the past - it is now much more fun than it was in the 0.4.2 days or so. still, there are problems around which the users encounter and which trouble them... |
| 18:36 |
VanessaE |
bug fixes are more important than new features, especially when they affect user-facing things in the project. |
| 18:37 |
VanessaE |
this is programming 101 stuff here guys, I mean come on. |
| 18:37 |
Taoki |
Farmesh for example (last time I tried it) wasn't broken but outright destroyed. Even if it's a feature I know many don't use. Broken features don't sound like something good to have |
| 18:37 |
Jordach |
until you play your own game, you will never know how bad / good it is |
| 18:37 |
hmmmm |
taoki, it was pending removal (or some kind of revival, celeron likes it) |
| 18:37 |
Anchakor |
this is Project Management 101, not Programming 101 |
| 18:37 |
Taoki |
I see |
| 18:37 |
hmmmm |
but farmesh just can't be used |
| 18:37 |
Taoki |
I only like it cuz it allows large view distances without losing FPS. Or well, I thiink that's its purpose anyway |
| 18:37 |
hmmmm |
the framerates... |
| 18:37 |
PilzAdam |
this is an Open Source project, nobody has the right to get any attention from developers; everyone just does what he wants |
| 18:38 |
hmmmm |
whattt!? |
| 18:38 |
Anchakor |
most open source projects have 0 project mangement and it is fine... others have lots of it and it is fine |
| 18:38 |
hmmmm |
taoki, how do you get high framerates with farmesh? |
| 18:38 |
hmmmm |
last time i checked i got about 5 fps with it on |
| 18:38 |
Taoki |
hmmmm: I don't. I get 10 times less FPS |
| 18:38 |
Taoki |
I meant I think its purpose was to improve frame rate |
| 18:38 |
hmmmm |
exactly, it's broken and crap and needs to be scrapped completely |
| 18:39 |
hmmmm |
it looks bad, it's inconsistent, and slow |
| 18:39 |
Exio |
i wonder |
| 18:39 |
Taoki |
I would be ok with removing it if it's not fixed |
| 18:39 |
hmmmm |
celeron and i were talking about how farmesh can be done better a while ago |
| 18:39 |
Exio |
did anyone try https://github.com/minetest/minetest/pull/789? |
| 18:39 |
celeron55 |
farmesh was a prototype from the start; it's something i'd have in a personal branch if i made it these days |
| 18:39 |
Taoki |
I'd instead like to see some other LOD system though. To allow for huge draw distances without loss of FPS |
| 18:40 |
hmmmm |
we were thinking, generate a very small texture with the approximate colors for each visible side of the mapblock |
| 18:40 |
Exio |
you mean, making far-mapblocks simple when drawing them |
| 18:40 |
Taoki |
Maybe after some distance, nodes are combined and rendered as one node. After even more distance, 3 nodes combined, then 4 and so on |
| 18:40 |
hmmmm |
like mipmapping |
| 18:40 |
hmmmm |
the farther away you are, it uses the less detailed version of the texture for that mapblock |
| 18:40 |
celeron55 |
rendering multiple nodes as one isn't going to look like it's further in the distance |
| 18:41 |
celeron55 |
you need something more like what hmmmm is saying |
| 18:41 |
Taoki |
mm... yeah |
| 18:41 |
celeron55 |
(maybe; it's what my intuition tells me) |
| 18:41 |
celeron55 |
it's somewhat a heavy thing to test anything though |
| 18:42 |
Anchakor |
hmmmm: you mean like 3 sprites 1 for each axis? I thought about that too |
| 18:42 |
celeron55 |
there's like everything involved |
| 18:42 |
PilzAdam |
Exio, yes, I tested it |
| 18:42 |
hmmmm |
anchakor, yeah. |
| 18:42 |
PilzAdam |
Exio, I havent noticed anything bad about it (tested performance and stuff) |
| 18:43 |
Exio |
VanessaE: can you try it? with your 4000+ nodes? |
| 18:43 |
Exio |
PilzAdam: same here, that is why i'm asking |
| 18:43 |
VanessaE |
what, farmesh? |
| 18:43 |
Taoki |
I assume farmesh was meant to be a geometry LOD system. Personally I find the idea of farmesh good... but sadly the system is currently broken\ |
| 18:43 |
Exio |
no, https://github.com/minetest/minetest/pull/789 |
| 18:43 |
Taoki |
If I enable farmesh, I get polygons thrown in my face and FPS is 5 times slower |
| 18:43 |
PilzAdam |
Taoki, download 0.3.x and test it there |
| 18:44 |
VanessaE |
Exio: texture atlas is disabled on my client already anyway, I don't see how that pull would change anything. |
| 18:44 |
celeron55 |
farmesh is implemented with throwing each polygon separately to the GPU |
| 18:44 |
celeron55 |
it's not going to be fast on modern GPUs |
| 18:44 |
Exio |
VanessaE: for checking if it didn't break anything in the middle |
| 18:44 |
celeron55 |
don't even talk about it's speed :P |
| 18:44 |
VanessaE |
oh. maybe I'll try it. |
| 18:44 |
PilzAdam |
VanessaE, turning the setting off and completly removing it from core are two very different things |
| 18:45 |
VanessaE |
PilzAdam: I am well aware of that. I just didn't understand Exio's point of requesting the test. |
| 18:45 |
Exio |
i guess if it passes your tests, it is 99% bug free in corner cases ;P |
| 18:48 |
Taoki |
Ah, I think I can tell why wanted_fps was not working. I had minimum view distance to more than 35 nodes |
| 18:48 |
Taoki |
Not it would appear to be working, but ugly low draw distance |
| 18:49 |
Taoki |
**now |
| 18:50 |
Exio |
what is your gpu, btw? |
| 18:50 |
Taoki |
I wonder why it's still so slow to render simple block faces. I mean in an environment like Minetest, one could expect over 60 FPS with reasonable draw distances |
| 18:51 |
Taoki |
Especially since celeron55 mentioned block surfaces are now combined and faces merged into one face where possible |
| 18:51 |
Taoki |
Exio: Radeon HD 6870 |
| 18:51 |
PilzAdam |
Taoki, do you look at a tree with fancy leaves enabled? |
| 18:51 |
Taoki |
PilzAdam: I have that option on. Will try with it off then |
| 18:52 |
Taoki |
Ah... without it trees are opaque. Uuuuuugly :P |
| 18:53 |
VanessaE |
Exio: had to re-clone for some reason. anyway, compiling now. |
| 18:53 |
VanessaE |
Taoki: same GPU as me. Windows or linux? I don't remember now which you used. |
| 18:54 |
Taoki |
VanessaE: Linux, and the fglrx driver |
| 18:54 |
VanessaE |
ok, so basically the same setup as me. |
| 18:54 |
Taoki |
Minetest seems to work faster on the open-source Radeon driver, but I need frlgx for higher-end games |
| 18:54 |
Taoki |
nice |
| 18:56 |
|
iqualfragile joined #minetest-dev |
| 18:57 |
Taoki |
PilzAdam: FPS adaptation is SLIGHTLY working. If I set my minimum draw distance very high then back down to 50, it slowly begins decreasing the actual view distance till it's enough to get 60FPS. But not the other way around: If distance is initially low, it doesn't try going higher as long as it keeps to 60 fps |
| 18:58 |
VanessaE |
Exio: ok, I'm on my server now - fresh git clone + kahrl's patch. |
| 18:58 |
PilzAdam |
Taoki, can you try the default settings? |
| 18:58 |
Taoki |
So if you start with a high draw distance it will go lower till you get 60 fps. But if you start with a low one, it doesn't go higher as long as it stays 60 |
| 18:58 |
Taoki |
ok |
| 18:59 |
Exio |
so |
| 19:00 |
Exio |
that is gpu is better than mine, nvm :P |
| 19:00 |
VanessaE |
Taoki: that's been my general experience alos. |
| 19:00 |
VanessaE |
also* |
| 19:01 |
VanessaE |
Exio: looks normal. Nothing unusual so far. |
| 19:02 |
hmmmm |
hmmmmmm i have a question about lua callbacks |
| 19:02 |
Taoki |
PilzAdam: With wanted_fps at 30 it seems to be slightly increasing |
| 19:02 |
hmmmm |
is there any way to store information along with a registered callback? i want to pass certain parameters to it if a certain option is present |
| 19:03 |
hmmmm |
for example i'd like to be able to do minetest.register_on_generated(WANT_VMANIP | WANT_HEIGHTMAP, function (blah blah blah) |
| 19:04 |
Taoki |
surprisingly, with wanted_fps 30 I still don't get less than 60 |
| 19:04 |
Taoki |
Well, about 55 at least |
| 19:04 |
sapier1 |
hmmmm you always can change the data stored saving the function in a sub element and store the data to another one |
| 19:06 |
Taoki |
Yeah now it gets to about 40 |
| 19:08 |
hmmmm |
actually this is kinda hard |
| 19:08 |
hmmmm |
i need t ochange environment_OnGenerated much more than i wanted to |
| 19:09 |
sapier1 |
why? in worst case you could register a single callback making that callback distribute it to other ones within lua |
| 19:10 |
sapier1 |
ok ok |
| 19:10 |
sapier1 |
special callback handling |
| 19:11 |
hmmmm |
i'd have to make a different on generate |
| 19:11 |
hmmmm |
on_generate_ex() also passes a table of optional parameters |
| 19:12 |
hmmmm |
based on what the mod doing the registering wants, that table will get populated with whatever |
| 19:16 |
celeron55 |
hmmmm: what are you trying to do? |
| 19:16 |
celeron55 |
uhm |
| 19:17 |
celeron55 |
well at least don't make a yet another function, just make an optional second parameter to register_on_generated() |
| 19:17 |
|
proller joined #minetest-dev |
| 19:17 |
Taoki |
Is the character model with divived limbs part of Minetest officially? |
| 19:17 |
Taoki |
I'm seeing that on VanessaE's server, but the latest source blend isn't updated |
| 19:17 |
Taoki |
Arms and legs are still whole blocks there |
| 19:18 |
VanessaE |
that's stu's model |
| 19:18 |
celeron55 |
IIRC somebody made a second version of it in addition to yours and released it |
| 19:18 |
VanessaE |
it's not part of minetest and probably won't be. |
| 19:18 |
Taoki |
ok |
| 19:18 |
VanessaE |
(someone here already said the difference in file size was too great or some such) |
| 19:28 |
Jordach |
which with todays internet |
| 19:28 |
Jordach |
thats absolute bullshit |
| 19:28 |
Jordach |
size is no longer a constraint |
| 19:29 |
sapier1 |
jordach you're kidding? |
| 19:29 |
kahrl |
today's internet has the only ISP available around here essentially cut off your internet after you use a few GB per month |
| 19:29 |
PilzAdam |
Jordach, not everyone is blessed with a fast internet connection like you have |
| 19:30 |
sapier1 |
kahrl german telecom tries to establish "flatrates" cut down to 256kbit after budget is exceeded ;-) |
| 19:31 |
kahrl |
sapier1: genau :) |
| 19:31 |
sapier1 |
wait its been 384 ... but I've read they try to avoid regulation by setting it to 2mbit |
| 19:32 |
sapier1 |
but real problem is priorized data transfer to their own or paying services |
| 19:33 |
kahrl |
some areas even only have LTE or some bullshit like that |
| 19:52 |
Taoki |
celeron55: Is it really a good idea to let Minetest send things that aren't rendered to the video card? It does feel like this might be making it slower instead... |
| 19:55 |
celeron55 |
Taoki: can't you understand that the reason why MT is running slow on your beast GPU is because MT sends stuff to be rendered in so small pieces and does not store them on the GPU |
| 19:56 |
Taoki |
Ah... that I didn't understand yet. |
| 19:56 |
Taoki |
I assume it can't be fixed? |
| 19:56 |
celeron55 |
of course it can, but it's not exactly trivial |
| 19:56 |
celeron55 |
also, both need to be fixed at the same time, because either done on their own is useless |
| 19:57 |
Taoki |
I think it would be a very important thing to fix, since FPS is very slow due to it |
| 19:57 |
Taoki |
Maybe not the ost important, but I'd say one of the |
| 19:57 |
celeron55 |
i'm not 100% sure it's the main reason for a given kind of slowness, but it sure creates very different kind of GPU utilization than modern games do |
| 19:58 |
Taoki |
From what I can think of, it's probably a huge reason. If each face or polygon is sent individually than as a whole, I'm surprised it even works as fast as now |
| 19:59 |
celeron55 |
...ehm |
| 19:59 |
celeron55 |
they are sent as individual mapblocks (to put it simply) |
| 20:00 |
celeron55 |
and that is not large enough batching |
| 20:00 |
Taoki |
Ok, to some extent that is good. But if the GPU doesn't keep then and the CPU has to send the model each frame, I think that means a lot of slowness. |
| 20:00 |
Taoki |
Pretty sure actually. Although I could be wrong, that sounds like a really bad thing |
| 20:01 |
celeron55 |
storing those on the GPU doesn't give any more performance at least on my laptop |
| 20:01 |
celeron55 |
(also it's kind of wonky to do in irrlicht, you set a flag and then hope that it maybe does what you want in the background) |
| 20:02 |
Jordach |
how about we delete unused chunks |
| 20:02 |
Jordach |
in ram |
| 20:02 |
Jordach |
that is where performance is lost. chunks that are "loaded" but not used. |
| 20:02 |
Taoki |
Has anyone tried setting that flag in Minetest? Which line of code can I try it at? |
| 20:03 |
celeron55 |
i'm trying to find it ATM |
| 20:03 |
PilzAdam |
Jordach, blocks are unloaded after some time, there is a setting for this |
| 20:03 |
Taoki |
ok. Let me know please, I'd really like to test this |
| 20:03 |
PilzAdam |
one for client and one for the server |
| 20:03 |
Jordach |
PilzAdam, yes, i know of the delete chunks after x seconds |
| 20:03 |
Jordach |
but even that doesnt prune very quickly |
| 20:03 |
celeron55 |
vertex data stored on GPU like that is usually called a VBO |
| 20:03 |
Taoki |
Again, I could be wrong. But the thought of sending data to the GPU every frame when the GPU could simply keep it sounds ludicrous to me (on a general 3D knowledge) |
| 20:04 |
Taoki |
Yes, I think it's the VBO part |
| 20:05 |
celeron55 |
Taoki: in mapblock_mesh.cpp, search EHM_STATIC; and in main.cpp, uncomment line 1576 (setMinHardwareBufferVertexCount) |
| 20:05 |
Taoki |
Most engines have VBO as a setting. So if this can be figured out I believe it should be an option |
| 20:05 |
celeron55 |
the latter because the default minimum size of VBO'd buffers in irrlicht is 500 |
| 20:05 |
Taoki |
Awesome, thanks. Will try it out now |
| 20:05 |
celeron55 |
also, you will experience horrible memory leaks |
| 20:05 |
celeron55 |
because irrlicht doesn't handle deletion of VBOs properly at all |
| 20:06 |
celeron55 |
(at least 1.7 doesn't) |
| 20:07 |
Taoki |
celeron55: I wonder. Could we add an #ifdef check to detect the Irrlicht version? Any only enable it with +1.7 then? |
| 20:07 |
celeron55 |
of course; but i don't think it's fixed |
| 20:07 |
Taoki |
ok |
| 20:07 |
Taoki |
Will see how faster it is, really curious |
| 20:08 |
celeron55 |
i'm curious too |
| 20:08 |
PilzAdam |
celeron55, I get 60+ FPS in a jungle where I formerly got 20 |
| 20:09 |
PilzAdam |
and constantly increasing RAM usage |
| 20:09 |
|
sapier joined #minetest-dev |
| 20:10 |
Taoki |
It is a LOT FASTER! |
| 20:10 |
Taoki |
I enabled full view range and so far nothing under 60 FPS |
| 20:10 |
Exio |
it doesn't perform that well for me |
| 20:10 |
Taoki |
Damn... I never thought I'd see a view range this large at 60 FPS in Minetest |
| 20:11 |
Jordach |
dun dun durr |
| 20:11 |
celeron55 |
something like calling IVideoDriver::removeHardwareBuffer for mapblock meshes that are deleted should be done |
| 20:11 |
Taoki |
Exio: Can depend a lot on drivers and hardware. For me it does miracles |
| 20:11 |
PilzAdam |
with full view range looking at a huge jungle with fancy leaves enabled and I still get 50 FPS |
| 20:11 |
Exio |
but i can have more mapblocks when looking at it |
| 20:11 |
proller |
btw Irrlicht Engine version 1.9.0 |
| 20:11 |
Jordach |
make VBOs a conf setting |
| 20:11 |
celeron55 |
Exio: well, what hardware? |
| 20:11 |
Exio |
celeron55: gt 610 (low-end and old-ddr3 nvidia gpu, the cheapest) and if matters, bulldozer x6 6100 the cpu |
| 20:11 |
Exio |
(3.3 but turbo at 4ghz) |
| 20:11 |
Taoki |
only now I'm starting to get 40 FPS at full view range. |
| 20:11 |
Taoki |
I can't tell how many nodes that is but it's reasonably far |
| 20:12 |
Taoki |
proller: Hold on, I'll look in my system packages |
| 20:12 |
Taoki |
Anyway, for my hardware at least, this is a HUGE improvement |
| 20:12 |
PilzAdam |
celeron55, overall I would guess 400% performance increase |
| 20:12 |
Taoki |
It's probably 3-5-7 times faster |
| 20:12 |
Jordach |
fuck me backwards. |
| 20:12 |
Jordach |
my gpu supports VBOs |
| 20:12 |
proller |
lets make config value for it |
| 20:12 |
celeron55 |
the funny thing is, i've said this like a million times and this is the first time anyone actually bothered trying it |
| 20:12 |
Exio |
it is mem leaky |
| 20:12 |
proller |
run_fast=1 |
| 20:13 |
Taoki |
proller: +1 |
| 20:13 |
Exio |
run_fast_but_consume_1mb_of_ram_every_second |
| 20:13 |
PilzAdam |
the RAM fills up very quickly, though |
| 20:13 |
Taoki |
proller: No. If it's called VBO the option should be called VBO too. It's that way for most engines |
| 20:13 |
Jordach |
if we used cleared unused chunks, then it shouldnt leak allover the place |
| 20:13 |
proller |
now very cheap memory, no problem 8) |
| 20:13 |
PilzAdam |
its not usable in "normal usage" |
| 20:13 |
celeron55 |
Taoki: so does it consume infinite memory on your computer and what version of irrlicht is it? |
| 20:13 |
Exio |
1.8 here |
| 20:13 |
Taoki |
celeron55: So far no excess RAM usage |
| 20:14 |
Exio |
now it got stable |
| 20:14 |
PilzAdam |
celeron55, 1.7.3 here and each loaded block increases the RAM usage |
| 20:14 |
celeron55 |
so it could be that 1.8 fixes it; needs more testing though |
| 20:14 |
Taoki |
My Irrlicht version is 1.8.2 |
| 20:14 |
Taoki |
I'll keep exploring and see |
| 20:15 |
Exio |
fwiw i'm using a 256x texture pack |
| 20:15 |
Exio |
i'll try with default |
| 20:15 |
Taoki |
Default textures here |
| 20:15 |
Taoki |
I can test if with Irrlicht 1.8 the problem still exists, will go exploring on my local server now |
| 20:16 |
Exio |
it works very well with a damn lot of mapblocks |
| 20:16 |
Exio |
but with less, it is the same :P |
| 20:16 |
Taoki |
Exio: All I can tell is that at big view distance, it's awesomely faster |
| 20:16 |
celeron55 |
anyhow, seems to turn out that actually it doesn't need larger batches at all |
| 20:17 |
PilzAdam |
celeron55, Ill test if 1.8 cleans up the memory |
| 20:17 |
Exio |
and if c55 said it didn't make any difference with "low-end hardware" (even if mine is low-end-but-new-ish) |
| 20:17 |
Taoki |
Sadly, memory is increasing for me too. 380 MB so far |
| 20:17 |
Taoki |
I wonder if anything can fix that |
| 20:17 |
Exio |
it seems so |
| 20:17 |
PilzAdam |
Taoki, I was at 2.5 GiB |
| 20:17 |
celeron55 |
Taoki: that amount is probably just regular operation if you're exploring places |
| 20:18 |
celeron55 |
or, well, could be |
| 20:18 |
Exio |
if there is a leak, in 1.8, it is small :P |
| 20:18 |
Taoki |
650 after flying a bit forward. So yes, the memory leaks are true |
| 20:18 |
Taoki |
Yes, it keeps adding as I explore |
| 20:18 |
Exio |
that is obvious |
| 20:18 |
Exio |
mapblocks are always in ram, even air uses ram |
| 20:18 |
Taoki |
On the other side, wasting such a good improvement would be a crime. So what can be done at all? What causes the leaks? |
| 20:19 |
celeron55 |
MT will start deleting mapblocks from memory only after 5 minutes of not rendering them, by default |
| 20:19 |
celeron55 |
23:11:45 < celeron55> something like calling IVideoDriver::removeHardwareBuffer for mapblock meshes that are deleted should be done |
| 20:19 |
Taoki |
I see |
| 20:20 |
Taoki |
celeron55: What if it were done instantly after not rendering them? Would it hurt anything, and fix the leaks with this? |
| 20:20 |
Taoki |
PilzAdam: And yes, overall I would say an average of 40% improvement too. Possibly more depending on circumstance, at first it felt like a lot more |
| 20:21 |
Taoki |
Either way, the improvement is huge |
| 20:21 |
PilzAdam |
Taoki, +0 |
| 20:21 |
PilzAdam |
(400%) |
| 20:21 |
celeron55 |
mapblock_mesh.cpp:1233 maybe |
| 20:21 |
celeron55 |
as long as that is done in the main thread of the client |
| 20:21 |
celeron55 |
i think it is |
| 20:21 |
celeron55 |
or hope it is |
| 20:21 |
celeron55 |
otherwise it's getting messy |
| 20:22 |
celeron55 |
but that place in the code doesn't have the device pointer so that needs some logistics |
| 20:22 |
Taoki |
yeah |
| 20:22 |
celeron55 |
(it's complete bullshit that irrlicht doesn't free it by itself when the mesh is freed) |
| 20:23 |
celeron55 |
(it could do it easily if it wanted) |
| 20:23 |
Taoki |
It's pretty sad; I can't waste such an improvement, but the memory leaks aren't acceptable either |
| 20:24 |
* Taoki |
thinks |
| 20:24 |
Taoki |
You said after 5 minutes of not rendering them. Where is that code, and what happens if it's made instant? |
| 20:24 |
celeron55 |
aaaactually |
| 20:25 |
celeron55 |
it has access to IGameDef... no, that doesn't give access to IrrlichtDevice either |
| 20:25 |
celeron55 |
it could be a shortcut for doing that for now though |
| 20:26 |
hmmmm |
could do it like minecraft and only keep a largeish box radius around the player loaded |
| 20:26 |
PilzAdam |
tested a build with 1.8 same leaks, and worse performance |
| 20:26 |
Taoki |
Should work. It should be possible to get the device by referencing from another file from what I remember |
| 20:26 |
hmmmm |
taoki, i don't think gpu bandwith is the problem, video cards do the occlusion on their own |
| 20:26 |
celeron55 |
of course you can put it in a global, but that isn't going upstream by any chance |
| 20:26 |
Taoki |
PilzAdam: I can confirm the leaks too. I think the leaks themselves decrease performance, after VBO initially improves it a ton |
| 20:26 |
PilzAdam |
*slightly worse |
| 20:26 |
Taoki |
So vbo without the leaks should mean huge improvement on some cards |
| 20:27 |
Taoki |
hmmmm: Well, the VBO's improve performance quite a lot |
| 20:27 |
kahrl |
celeron55: gamedef->tsrc()->getDevice()? |
| 20:27 |
hmmmm |
VBO is something differen, i was talking about what you said earlier |
| 20:27 |
celeron55 |
kahrl: good catch |
| 20:27 |
celeron55 |
PilzAdam: go test that |
| 20:27 |
Taoki |
hmmmm: Ah, ok. |
| 20:27 |
Taoki |
celeron55: If you put it on a pastebin I can test too |
| 20:28 |
PilzAdam |
celeron55, gimme a second |
| 20:28 |
celeron55 |
in mapblock_mesh.cpp:1233, do m_gamedef->tsrc()->getDevice()->removeHardwareBuffer() for each meshbuffer of m_mesh |
| 20:28 |
hmmmm |
so why is irrlicht 1.8 slower exactly? |
| 20:28 |
celeron55 |
hmmmm: many people say so, but nobody has yet said why |
| 20:28 |
PilzAdam |
hmmmm, I head 1.8 is generally slower |
| 20:28 |
celeron55 |
(outside MT too) |
| 20:28 |
hmmmm |
newer versions of things should never be slower than older ones |
| 20:28 |
PilzAdam |
*heard |
| 20:29 |
sapier |
hmmmm tell that to eclipse developers ;-) |
| 20:29 |
hmmmm |
yeah we heard, it'd be nice to do a side-by-side comparison though |
| 20:29 |
Taoki |
Anyway, I know that for some cards and drivers VBO can be problematic instead. So IMO this must be a minetest.conf option. But it needs to happen |
| 20:29 |
Taoki |
And I'll try that too |
| 20:30 |
|
kaeza joined #minetest-dev |
| 20:30 |
celeron55 |
i have never heard of a card that says it supports VBO but breaks if actually used with it |
| 20:30 |
kahrl |
isn't removeHardwareBuffer in IVideoDriver? |
| 20:30 |
celeron55 |
uhm |
| 20:30 |
celeron55 |
yes it is |
| 20:30 |
celeron55 |
so yet another -> there! |
| 20:31 |
Taoki |
celeron55: For me it depended on engine some time ago. Years ago for instance, enabling VBO in Second Life caused very jittery loading |
| 20:31 |
Taoki |
Of course, that's a TOTALLY different type of architecture |
| 20:31 |
celeron55 |
oh |
| 20:31 |
celeron55 |
it indeed may cause jitter |
| 20:31 |
celeron55 |
that's why it's an option |
| 20:31 |
Taoki |
yes |
| 20:31 |
Taoki |
But a damn good option in this case :D |
| 20:31 |
celeron55 |
(the GPU can be slow at storing it) |
| 20:32 |
celeron55 |
(that is, meant to be used so that everything is loaded into it at game startup, which we can't do) |
| 20:32 |
Exio |
if the gpu ram is fast, the VBO will make the stuff way faster :P |
| 20:32 |
Taoki |
For me there's no jitter however, so it's good on my hardware at least |
| 20:32 |
Taoki |
yes |
| 20:32 |
PilzAdam |
celeron55, what do I pass to removeHardwareBuffer()? |
| 20:33 |
Taoki |
celeron55: mapblock_mesh.cpp:1234:34: error: ‘class irr::IrrlichtDevice’ has no member named ‘removeHardwareBuffer’ |
| 20:33 |
celeron55 |
each meshbuffer of m_mesh |
| 20:33 |
celeron55 |
Taoki: what kahrl said |
| 20:33 |
Taoki |
oh |
| 20:34 |
Taoki |
It doesn't find IVideoDriver() either. What's the include file for it? |
| 20:35 |
Exio |
did you mean ->getVideoDriver() |
| 20:35 |
PilzAdam |
and segfault |
| 20:36 |
Taoki |
<+kahrl> isn't removeHardwareBuffer in IVideoDriver? |
| 20:36 |
Taoki |
m_gamedef->tsrc()->getDevice()->IVideoDriver()->removeHardwareBuffer(); |
| 20:36 |
celeron55 |
m_gamedef->tsrc()->getDevice()->getVideoDriver()->removeHardwareBuffer() |
| 20:36 |
Exio |
Taoki: http://irrlicht.sourceforge.net/docu/classirr_1_1_irrlicht_device.html |
| 20:36 |
celeron55 |
read the irrlicht docs |
| 20:36 |
PilzAdam |
for(u322 i=0; i<=m_mesh->getMeshBufferCount(); i++) |
| 20:36 |
PilzAdam |
m_gamedef->tsrc()->getDevice()->getVideoDriver()->removeHardwareBuffer(m_mesh->getMeshBuffer(i)); |
| 20:36 |
celeron55 |
PilzAdam: so it actually doesn't work? 8) |
| 20:37 |
celeron55 |
lol |
| 20:37 |
celeron55 |
i<= |
| 20:37 |
PilzAdam |
oh, damnit, Lua... |
| 20:37 |
Exio |
haha |
| 20:37 |
Taoki |
I forgot to add the ; at the end due to Lua habit :P |
| 20:37 |
PilzAdam |
it increase slower |
| 20:37 |
PilzAdam |
+s |
| 20:39 |
PilzAdam |
ok, it doesnt use infinite ram now |
| 20:40 |
PilzAdam |
but the performance isnt better than normal... |
| 20:41 |
Exio |
is it enabled? :P |
| 20:42 |
PilzAdam |
the performance is only better if it stays in RAM |
| 20:42 |
PilzAdam |
so its not useable :-/ |
| 20:43 |
celeron55 |
welcome to the fun irrlicht world |
| 20:43 |
celeron55 |
8D |
| 20:43 |
Taoki |
Not sure if the memory leak still exists, might be fixed. Performance still seems to be improved though |
| 20:44 |
celeron55 |
next you'll find yourselves browsing through the (actually quite readable) irrlicht sources figuring out what it does in the opengl backend |
| 20:44 |
Taoki |
Yes... pretty sure that performance remains as improved with the removing of those drivers |
| 20:45 |
Exio |
celeron55: where is the 5 minutes timeout defined? |
| 20:45 |
PilzAdam |
Exio, minetest.conf |
| 20:45 |
Exio |
aw :P |
| 20:45 |
Exio |
#client_unload_unused_data_timeout = 600 |
| 20:45 |
Exio |
i see, thanks |
| 20:46 |
celeron55 |
hmm actually that's 10 minutes |
| 20:46 |
PilzAdam |
wait, it works better in 1.7.3 |
| 20:46 |
celeron55 |
whatever |
| 20:46 |
PilzAdam |
its only not good in 1.8 |
| 20:47 |
PilzAdam |
another reason not to upgrade to 1.8 |
| 20:47 |
Taoki |
PilzAdam: I can't tell if the memory leaks are solved after that loop, but performance is surely still improved |
| 20:47 |
PilzAdam |
Taoki, what Irrlicht version? |
| 20:47 |
Taoki |
1.8.2 |
| 20:47 |
Taoki |
It's the latest in my distro and I don't have an 1.7 |
| 20:48 |
celeron55 |
PilzAdam: did you do the setMinHardwareBufferVertexCount thing? |
| 20:48 |
PilzAdam |
yea |
| 20:48 |
PilzAdam |
maybe I messed something up... |
| 20:48 |
celeron55 |
well it could be that 1.8 does something that is not optimal on your GPU; can't really know |
| 20:49 |
PilzAdam |
we can make it optional in minetest.conf so people can test it themselves |
| 20:49 |
Taoki |
Sounds good |
| 20:49 |
Taoki |
If you add the commit now I can test it with VanessaE |
| 20:49 |
PilzAdam |
how to call that setting? |
| 20:49 |
Taoki |
PilzAdam: VBO. It's the correct name and most engines call it that |
| 20:50 |
PilzAdam |
so enable_vbo |
| 20:50 |
Taoki |
sure |
| 20:50 |
PilzAdam |
celeron55, should the cleanup be disabled too if vbo is disabled? |
| 20:50 |
Taoki |
Or just vbo though that's a bit too short :P |
| 20:51 |
Exio |
VanessaE: ping? |
| 20:51 |
celeron55 |
PilzAdam: irrlicht does a binary tree search out of all existing meshbuffers when you call removeHardwareBuffer |
| 20:51 |
VanessaE |
pong. |
| 20:51 |
celeron55 |
so... umm |
| 20:51 |
Exio |
VanessaE: are/did you try the atlas remove? |
| 20:51 |
celeron55 |
dunno, getting the setting is probably similarly heavy |
| 20:52 |
celeron55 |
i'd say just call the removal always |
| 20:52 |
hmmmm |
storing a boolean is similarly heavy!? |
| 20:52 |
Taoki |
Calling it always sounds good to me too |
| 20:52 |
celeron55 |
well storing a boolean is of course cheaper |
| 20:52 |
Taoki |
I mean, it makes sense |
| 20:53 |
PilzAdam |
celeron55, and driver->setMinHardwareBufferVertexCount(50); can be called always too? |
| 20:53 |
celeron55 |
that can be called always; it only takes effect for meshes with the EHM_STATIC flag |
| 20:53 |
kahrl |
could getHardwareMappingHint be called to see if removeHardwareBuffer must be called? |
| 20:54 |
celeron55 |
i was just going to search if something like that exists |
| 20:54 |
celeron55 |
of course that way in that case |
| 20:54 |
VanessaE |
Exio: yes, and it had no visible effect, which I guess means it worked. |
| 20:54 |
VanessaE |
Exio: I saw no issues at all with that patch |
| 20:54 |
* Exio |
bugs kahrl, c55 and PilzAdam about merging it |
| 20:55 |
Taoki |
http://code.google.com/p/opennero/source/browse/vendor/Irrlicht/current/include/EHardwareBufferFlags.h?r=849 This is somewhat inspiring |
| 20:55 |
kahrl |
celeron55: SMesh doesn't have it, SMeshBuffer has getHardwareMappingHint_Vertex and _Index |
| 20:55 |
Taoki |
I wonder if the vertex buffers would also improve anything |
| 20:55 |
Taoki |
Apart from VBO's, there's also FBO\ |
| 20:55 |
Taoki |
Frame Buffer Objects or something |
| 20:56 |
PilzAdam |
ok, it always segfaults when I shut down minetest |
| 20:57 |
Taoki |
I wonder: What happens if we change the buffer type (that thing I linked shows it) |
| 20:57 |
Taoki |
Maybe some are even faster and don't cause the leak? |
| 20:58 |
celeron55 |
Taoki: it doesn't mean what you think it does; read the doc of setHardwareMappingHint |
| 20:59 |
Taoki |
There's also EHM_DYNAMIC and EHM_STREAM |
| 20:59 |
Taoki |
ok |
| 20:59 |
PilzAdam |
now the question is why does it segfault? |
| 20:59 |
celeron55 |
Taoki: those mean it's not stored on the GPU |
| 20:59 |
Taoki |
oh, useless then |
| 20:59 |
celeron55 |
PilzAdam: the answer comes when you run it in gdb with a debug build of irrlicht, i guess 8) |
| 21:00 |
Taoki |
PilzAdam: Can you use a function to if() check if the meshbuffer exists before removing it? That should fix it |
| 21:00 |
Taoki |
if(m_mesh->getMeshBuffer(i)) |
| 21:00 |
PilzAdam |
nope tested it |
| 21:00 |
Taoki |
hmm... |
| 21:01 |
celeron55 |
irrlicht does that already |
| 21:03 |
PilzAdam |
ummm |
| 21:03 |
PilzAdam |
the backtrace doesnt even show any Irrlicht functions... |
| 21:06 |
|
sokomine joined #minetest-dev |
| 21:06 |
Taoki |
I'm surprised you can't detect if the meshbugger you're getting == null however. Normally anything should allow that |
| 21:09 |
PilzAdam |
(gdb) bt |
| 21:09 |
PilzAdam |
#0 0x0000010000000010 in ?? () |
| 21:10 |
PilzAdam |
I have an Irrlicht and Minetest debug build |
| 21:11 |
celeron55 |
it's 42 |
| 21:11 |
celeron55 |
it's the answer |
| 21:11 |
celeron55 |
well no, umm |
| 21:11 |
celeron55 |
well the stack is borked |
| 21:12 |
celeron55 |
i'd throw it in valgrind instead and hope for the best |
| 21:12 |
PilzAdam |
what command line parameters? |
| 21:13 |
hmmmm |
ugh this is so messy. so in order to do what i want to do, i'm going to have t ochange make_registration() to return a function that takes a function and a table of parameters, and inserts that into registered_on_generateds, and then i have to change runCallbacks and all this nonsense |
| 21:13 |
celeron55 |
defaults should do |
| 21:13 |
hmmmm |
because it's no longer a table of functions, it's a table of tables of functions and options, and it's only a single specific callback that uses this |
| 21:14 |
celeron55 |
why don't you just special case your registration function |
| 21:14 |
celeron55 |
don't use make_registration() or runCallbacks |
| 21:14 |
hmmmm |
i'd have to rewrite the universe |
| 21:14 |
celeron55 |
nobody is going to do the same in the long time anyway |
| 21:14 |
hmmmm |
alright, i have a better idea |
| 21:14 |
celeron55 |
and when somebody does, then it's worth the job |
| 21:14 |
hmmmm |
i add a new api that switches it on |
| 21:15 |
hmmmm |
completely internal |
| 21:15 |
PilzAdam |
celeron55, :-/ nothing useful |
| 21:15 |
PilzAdam |
==17945== Access not within mapped region at address 0x0 |
| 21:15 |
PilzAdam |
==17945== at 0x6FAE2F: MapBlockMesh::~MapBlockMesh() (mapblock_mesh.cpp:1236) |
| 21:15 |
kahrl |
hmmmm: maybe it would be cleaner to add a 'callback' decoration type? |
| 21:15 |
kahrl |
but I don't know what you are trying to do |
| 21:15 |
hmmmm |
erm, this isn't a decoration :) |
| 21:15 |
celeron55 |
hmmmm: what if you added a new API function to get the vmanip in on_generated |
| 21:16 |
celeron55 |
and leave it otherwise the same |
| 21:16 |
PilzAdam |
celeron55, might it be that one of these (m_gamedef->tsrc()->getDevice()->getVideoDriver()->removeHardwareBuffer(buf);) is NULL |
| 21:16 |
PilzAdam |
+? |
| 21:16 |
hmmmm |
that's an option too |
| 21:16 |
celeron55 |
PilzAdam: oh, can be of course |
| 21:16 |
PilzAdam |
wait, gamedef doesnt exist after returning from the_game()? |
| 21:16 |
celeron55 |
hmmmm: i think it's the best thing you can do, assuming there's nothing making it inconvenient to implement |
| 21:16 |
Taoki |
Logically, only one thing could explain the segfault: Something removes the buffers before that function runs upon exit |
| 21:16 |
hmmmm |
alright, that's the best choice then.. i'll have it fail if called outside of on_generated |
| 21:16 |
Taoki |
Or the mesh is not referenced properly which isn't the case |
| 21:16 |
celeron55 |
PilzAdam: that's an easy fix then 8) |
| 21:17 |
Taoki |
So what removed the buffers before shutting down Minetest? |
| 21:17 |
Taoki |
Ah... or that :P |
| 21:17 |
Taoki |
Which implicitly means the buffers don't |
| 21:17 |
celeron55 |
PilzAdam: umm actually no, you can't know it in there... ehm |
| 21:17 |
PilzAdam |
if(m_gamedef) doesnt work :-/ |
| 21:17 |
celeron55 |
of course, it's a dangling pointer 8) |
| 21:18 |
Taoki |
Needs to be de-referenced perhaps |
| 21:19 |
PilzAdam |
cant I just try {..} catch(segfault) ? ;-) |
| 21:20 |
PilzAdam |
celeron55, the dtor is called from MapSector::deleteBlocks(), what if I let it just set a flag or something? |
| 21:20 |
kahrl |
the scary thing is that since this just accesses a pointer variable in TextureSource this might have actually worked if we were less lucky |
| 21:20 |
Taoki |
PilzAdam: What if you try if(*m_gamedef)? |
| 21:21 |
kahrl |
and then would have become the untraceable bug that noone will ever find |
| 21:21 |
PilzAdam |
Taoki, that doesnt even compile |
| 21:21 |
Taoki |
ouch. Was supposed to dereference it |
| 21:22 |
celeron55 |
the problem is really that ClientEnvironment is destructed after the Client (=gamedef) destructor is done, because it exists as a member of Client |
| 21:22 |
|
sapier left #minetest-dev |
| 21:22 |
celeron55 |
umm... i think |
| 21:24 |
celeron55 |
the fix? well, allocate Client::m_env dynamically so you can control when it's freed 8) |
| 21:25 |
celeron55 |
(should work) |
| 21:25 |
celeron55 |
(it's hackish of course but technically not wrong at all) |
| 21:25 |
hmmmm |
ah this is a much better idea, thanks celeron |
| 21:27 |
hmmmm |
i generalized it to VoxelManip:get_mapgen_object(["vmanip", "heightmap", "biomemap", "heatmap", "humiditymap"]) |
| 21:27 |
PilzAdam |
heres the diff is anyone is interested: https://gist.github.com/PilzAdam/5862595 |
| 21:29 |
* Taoki |
is interested to see it upstream :) Testing part of it manually still, hoping to find a check |
| 21:32 |
celeron55 |
PilzAdam: for a quick and not-touching-everywhere fix, you could of course just add a bool to MapBlockMesh that will be set in MapSector::deleteBlocks() before deleting them |
| 21:33 |
celeron55 |
dunno what should be considered upstream quality regarding to this |
| 21:34 |
celeron55 |
not that really at least |
| 21:34 |
* Taoki |
is up for anything that works. And is of course upstream quality too |
| 21:36 |
Taoki |
If only we could get m_device there... |
| 21:37 |
Taoki |
m_device->getVideoDriver() |
| 21:37 |
Taoki |
Instead of doing it through m_gamedef->tsrc() |
| 21:38 |
BrandonReese |
That's a big improvement, it's playable with draw full range enabled. I get ~ 60fps with draw full disabled and ~25 with it enabled, it would have been around 8-10 before |
| 21:38 |
celeron55 |
BrandonReese: what kind of hardware? |
| 21:38 |
PilzAdam |
hm, I just noticed that the RAM still fills up slowly when flying over many blocks |
| 21:39 |
PilzAdam |
there is a leak left |
| 21:39 |
PilzAdam |
(and FPS decrease too) |
| 21:39 |
BrandonReese |
ATI Radeon HD 7560D |
| 21:39 |
Taoki |
FPS decrease is prolly related to the leak |
| 21:41 |
Taoki |
Performance slightly decreases for me too as the leak takes place I think |
| 21:42 |
BrandonReese |
yeah Memory usage continues to climb |
| 21:47 |
PilzAdam |
heres the diff that sets the flag: https://gist.github.com/PilzAdam/5862737 |
| 21:49 |
Taoki |
Awesome |
| 21:49 |
Taoki |
I wonder where the other leak could be tho.. |
| 21:49 |
kahrl |
you could initialize clearHardwareBuffer to false and set it to true when you call setHardwareMappingHint |
| 21:50 |
PilzAdam |
kahrl, that wouldnt really help |
| 21:50 |
kahrl |
PilzAdam: I know, just an observation |
| 21:50 |
PilzAdam |
its used to indicate if gamedef exists |
| 21:50 |
|
salamanderrake joined #minetest-dev |
| 21:51 |
PilzAdam |
oh, yea, Ill do that |
| 21:51 |
PilzAdam |
valgrind doesnt find any leaks :-/ |
| 21:57 |
Taoki |
Will test more too, not sure why any leaks would still exist |
| 21:57 |
PilzAdam |
holy... this speeds things really up; 11 FPS in valgrind |
| 21:57 |
Taoki |
yeah :) |
| 21:58 |
VanessaE |
with my luck all of these improvements will still not help on my setup :) |
| 21:59 |
Taoki |
VanessaE: You have my setup, and for me it helps a ton. Surely it will for you too, maybe some other issue |
| 21:59 |
VanessaE |
ok |
| 22:01 |
Taoki |
PilzAdam: And that speedup is explainable. VBO likely takes a lot of load off the CPU, who had to send to the GPU each frame. Valgring is prolly a bit CPU intensive (last I remember), so the improvements is even more visible |
| 22:05 |
PilzAdam |
grrrr... why does this leak hide in valgrind? |
| 22:07 |
VanessaE |
PilzAdam: because you're searching for it, of course. :P |
| 22:07 |
kaeza |
try other more aggressive options |
| 22:07 |
PilzAdam |
anyone patient enough to fly arround with valgrind with 2FPS and load some blocks? |
| 22:07 |
Taoki |
PilzAdam: Does Valgrind detect if something is truly a leak or not? Maybe it's just using memory badly and not necessarily leaking... |
| 22:08 |
Taoki |
PilzAdam: Will try it as well now |
| 22:09 |
PilzAdam |
be sure to run it with --leak-check=full |
| 22:09 |
PilzAdam |
I use: valgrind --leak-check=full --log-file=valgrind.log bin/minetest |
| 22:10 |
Taoki |
will do and paastebin |
| 22:10 |
kaeza |
now Taoki's client is leaking 'a's |
| 22:10 |
* kaeza |
shuts up |
| 22:10 |
Taoki |
:3 |
| 22:10 |
celeron55 |
it might not be technically a leak, because irrlicht could free it at shutdown time |
| 22:10 |
celeron55 |
but leave it around until then |
| 22:11 |
celeron55 |
(irrlicht likes doing that) |
| 22:11 |
Taoki |
Sometimes I wonder what Minetest would have looked like if we chose OGRE |
| 22:12 |
PilzAdam |
round |
| 22:13 |
VanessaE |
kaeza: no, see, it's not leaking a's, he's just using a slightly different wording, like "haagen dasz" :D |
| 22:13 |
celeron55 |
it would still have a command line UI because ogre doesn't contain any GUI capabilities |
| 22:17 |
Taoki |
The default Ogre samples and sample browser have a GUI |
| 22:20 |
Taoki |
Damn Valgrind is slow |
| 22:22 |
Taoki |
Interesting. Sometimes chunks are loaded / generated into view without increasing memory usage and causing the leaks. I think |
| 22:29 |
Taoki |
PilzAdam: http://paste2.org/ymHZjIJP |
| 22:31 |
Taoki |
One huge log... 2 MB. Barely found a pastebin that accepted it x_x |
| 22:38 |
Taoki |
PilzAdam: Does it help and explain what's happening? |
| 22:42 |
* Taoki |
feels alone |
| 22:47 |
Taoki |
celeron55: Can you deschipher anything of importance from that log? |
| 22:48 |
Taoki |
Funny thing: On VanessaE's server, memory usage is still slightly increasing although I'm no longer exploring |
| 22:49 |
|
dzho joined #minetest-dev |
| 22:50 |
Taoki |
Even more funny thing: I was debugging a code when suddenly, everyone I was working on it with went AFK :) |
| 22:55 |
PilzAdam |
Taoki, that log is very helpful for fixing more memory leaks in the future :-) |
| 22:55 |
Taoki |
Well, at least it did something :) |
| 22:55 |
Taoki |
Nothing on the memory leak with VBO's though? |
| 22:58 |
PilzAdam |
have you compiled minetest in debug mode? |
| 22:58 |
Taoki |
Don't think so |
| 22:59 |
PilzAdam |
well, there are no line numbers in the log |
| 22:59 |
PilzAdam |
so its not very useable |
| 22:59 |
Taoki |
I'll comiple in debug mode and run valgrind with the same parameters again |
| 23:00 |
PilzAdam |
only the part under "HEAP SUMMARY:" is interesting to find memory leaks |
| 23:00 |
Taoki |
Hopefully I'll have a new log in about 30 minutes or more |
| 23:02 |
Taoki |
So after I compile MT with the Debug flag in cmake, I just run valgrind the same way, right? |
| 23:03 |
PilzAdam |
yep |
| 23:03 |
Taoki |
ok, let's see how this works |
| 23:03 |
PilzAdam |
Id recommend to make a short test first to see if everything works (i.e. line numbers) |
| 23:03 |
PilzAdam |
also get a debug build of irrlicht |
| 23:04 |
PilzAdam |
(maybe its helpful) |
| 23:04 |
Taoki |
A debug build of irrlicht would be too advanced. I use Irrlicht from the system-wide installation (Linux software packages) |
| 23:04 |
PilzAdam |
just apt-get install libirrlicht<something>-dbg |
| 23:04 |
PilzAdam |
(or whatever package manager you have) |
| 23:05 |
Taoki |
irrlicht-debugsource? |
| 23:05 |
Taoki |
or libirrlicht1_8_debuginfo |
| 23:05 |
PilzAdam |
ehm, what distro? |
| 23:05 |
Taoki |
openSUSE |
| 23:06 |
Taoki |
I guess I'll just install both. Once I do that, will cmake automatically detect the change and compile Debug minetest with Debug irrlicht? |
| 23:06 |
PilzAdam |
I usually rm bin/* CMakeCache.txt and run cmake and make again |
| 23:06 |
PilzAdam |
just to be sure that it links correctly |
| 23:07 |
Taoki |
I can do that. But it will all be re-detected properly? How do I know it uses debug Irrlicht? |
| 23:07 |
PilzAdam |
good question |
| 23:08 |
PilzAdam |
just hope that it works, its not that important that you have a debug build of irrlicht |
| 23:08 |
Taoki |
Will compile MT again and give it a try, hopefully it will |
| 23:09 |
Taoki |
I set CMAKE_BUILD_TYPE to Debug, but that might affect only the Minetest source and not Irrlicht source. If the cmake setup is done properly though, it will try to use debug Irrlicht too |
| 23:09 |
PilzAdam |
it should be irrlicht-debuginfo |
| 23:09 |
Taoki |
Good, I installed it too |
| 23:12 |
kahrl |
Taoki: you can look at src/CMakeFiles/minetest.dir/link.txt to see the link command it uses |
| 23:20 |
Taoki |
Alright, in valgrind now and making a new log |
| 23:27 |
Taoki |
434 MB, a minute then posting log |
| 23:27 |
PilzAdam |
<PilzAdam> only the part under "HEAP SUMMARY:" is interesting to find memory leaks |
| 23:28 |
Taoki |
will do |
| 23:33 |
Taoki |
Even the text under heap summary is too large to post anywhere... |
| 23:33 |
PilzAdam |
zip it |
| 23:34 |
Taoki |
http://www.sendspace.com/file/3rhaux |
| 23:35 |
Taoki |
Amazing how 6.5 MB becomes 250 KB with one zip |
| 23:36 |
Taoki |
Anbyway it's showing some code functions now. Sure hope it's our memory leak too |
| 23:38 |
kahrl |
most of these leaks seem to be in fglrx_dri.so |
| 23:38 |
kahrl |
these could be the VBOs |
| 23:39 |
Taoki |
The part specifying code functions: http://paste2.org/5U31mtUF |
| 23:39 |
kahrl |
unfortunately fglrx_dri.so seems to have been compiled with something that destroys stack frames (-fomit-frame-pointer?) so the stacktraces aren't helpful |
| 23:40 |
Taoki |
kahrl: Possibly. I assume it's not a fglrx-only issue but could happen with any video driver |
| 23:40 |
Taoki |
I have fglrx from the geeko repository. Only the ATI devs know how they compiled it :P |
| 23:40 |
Taoki |
It's the closed source driver |
| 23:41 |
kahrl |
well how about this solution: 1) apply for a job at ATI, 2) compile a debug build of fglrx_dri.so, 3) ????, 4? profit |
| 23:42 |
Taoki |
It's more likely something between Minetest and Irrlicht |
| 23:42 |
Taoki |
Yeah... what a job as an undercover spy :P |
| 23:42 |
Taoki |
PilzAdam: Any thoughts? Is that being helpful? |
| 23:43 |
PilzAdam |
by 0x584703: MapBlock::reallocate() (basic_string.h:930) <- wtf? |
| 23:44 |
Taoki |
mapgen v7, mentioning just in case :P |
| 23:45 |
Taoki |
Ah, MapBlock. That sounds more related to the problem... |
| 23:48 |
PilzAdam |
"irr::scene::SAnimatedMesh::getMeshBuffer(unsigned int) const (SAnimatedMesh.h:135)" |
| 23:49 |
Taoki |
Doubt that's related, nodes aren't animated meshes |
| 23:49 |
Taoki |
Well, it mentions mesh buffer... |
| 23:50 |
PilzAdam |
I guess kahrl is right |
| 23:51 |
kahrl |
yeah, that particular stack trace looks like leftover data from a previous call |
| 23:51 |
Taoki |
It's strange that fglrx (the video driver) has an importance here. Thought this is an irrlicht issue |
| 23:51 |
Taoki |
No other way to know what causes the leaks? |
| 23:52 |
kahrl |
does the open source driver support VBOs? |
| 23:53 |
Taoki |
Most likely yes. The open-source driver has all features, I only don't use it because it can't handle large textures yet (high-end games lag horribly when VRam is filled and needs to swap ro RAM) |
| 23:53 |
Taoki |
And I'm not switching drivers now... not something I feel comfortable playing with |
| 23:53 |
PilzAdam |
maybe ask some Irrlicht devs? |
| 23:53 |
kahrl |
since the open source driver can be compiled in debug mode it would probably give more helpful stack traces |
| 23:54 |
Taoki |
Well, what to ask them exactly? They don't know the Minetest code |
| 23:55 |
kahrl |
perhaps make an extremely stripped down version of minetest (well, not actually minetest anymore) |
| 23:56 |
kahrl |
which is basically an irrlicht sample that creates meshes in a loop and destroys them |
| 23:56 |
kahrl |
and see if that causes leaks if you set EHM_STATIC and call removeHardwareBuffer |
| 23:58 |
Taoki |
Told them about the problem in short, if anyone's active I'll see what they say |
| 23:58 |
PilzAdam |
what channel? |
| 23:58 |
Taoki |
#irrlicht |
| 23:58 |
Taoki |
Also, something quite interesting: http://irrlicht.sourceforge.net/forum/viewtopic.php?t=37558 |
