| Time |
Nick |
Message |
| 00:44 |
|
Void7_ joined #minetest-dev |
| 01:20 |
sofar |
ugh, is there no way to intercept on_punch for an entity so I can play a death animation? |
| 01:22 |
sofar |
I guess I have to make it immortal and do all the damage calculations myself, then |
| 01:30 |
sofar |
enough procrastination, I need to write the movement code now :/ |
| 02:02 |
|
misprint joined #minetest-dev |
| 02:24 |
|
Void7_ joined #minetest-dev |
| 03:28 |
|
yasnothil joined #minetest-dev |
| 03:29 |
|
Zeno` joined #minetest-dev |
| 04:07 |
|
gregorycu joined #minetest-dev |
| 04:14 |
|
DI3HARD139 joined #minetest-dev |
| 04:24 |
|
est31 joined #minetest-dev |
| 04:57 |
|
Zeno` joined #minetest-dev |
| 04:59 |
gregorycu |
#4025 |
| 04:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/4025 -- Fix for Main Menu uses a lot of CPU by gregorycu |
| 05:00 |
Zeno` |
people will complain that the clouds don't move as fast as the did before :D |
| 05:01 |
gregorycu |
I was actually more worried about the click-responsiveness |
| 05:01 |
gregorycu |
But even 5fps is fine |
| 05:01 |
est31 |
what bout making cloud movement not dependent on fps? |
| 05:01 |
gregorycu |
It's not |
| 05:01 |
gregorycu |
Clouds move at the same rate regardless |
| 05:01 |
gregorycu |
(I think the default for the setting in question is 20fps) |
| 05:01 |
Zeno` |
Yes, sorry est31 (I was being facetious) |
| 05:02 |
Zeno` |
*shrug* looks good to me |
| 05:02 |
est31 |
Zeno`, i didnt know it either :) |
| 05:02 |
Zeno` |
est31, heh |
| 05:07 |
Zeno` |
Physical id 0: +68.0°C (high = +80.0°C, crit = +100.0°C) :/ |
| 05:08 |
Zeno` |
85% |
| 05:08 |
Zeno` |
90C |
| 05:08 |
Zeno` |
I think I'll bbl |
| 05:08 |
gregorycu |
Zeno must have had the main menu open |
| 05:09 |
DI3HARD139 |
lol |
| 05:14 |
est31 |
an even better fix would be to make the clouds drawing use less cpu |
| 05:14 |
est31 |
if thats possible somehow |
| 05:16 |
gregorycu |
That's not the issue here |
| 05:16 |
gregorycu |
Well |
| 05:17 |
gregorycu |
The reason the CPU heats up is because drawing the clouds are so trivial |
| 05:17 |
gregorycu |
That not a lot of time is spent with graphics related operations |
| 05:17 |
gregorycu |
But instead, in code that prepared the cloud for drawing |
| 05:18 |
gregorycu |
Maybe we can make it better, for instance, cache the results of the perlin noise stuff rather than recalculating |
| 05:18 |
gregorycu |
But yeah, this brings the main menu in-line with the in-game-menu, so I think at the very least, we should do this |
| 05:19 |
est31 |
yeah +1 to the patch |
| 05:20 |
gregorycu |
I'm going through the issues tagged "Performance" to see if I can get rid of some easy ones |
| 05:23 |
sofar |
minetest.find_nodes_in_area_under_air never returns any nodes for me... weird |
| 05:25 |
sofar |
ahh silly me |
| 05:30 |
DI3HARD139 |
Im surprise CPU temps are high. My CPU is usually idling at the main menu |
| 05:31 |
gregorycu |
If you want to reproduce the bug, set your max_fps to be very large |
| 05:32 |
gregorycu |
I managed to make one CPU max out |
| 05:32 |
gregorycu |
With the patch, minetest uses ~0% CPU in main menu for me |
| 05:32 |
DI3HARD139 |
is around 300 good? |
| 05:32 |
gregorycu |
Make it 1000 |
| 05:32 |
DI3HARD139 |
thats what I currently have it set to. |
| 05:32 |
DI3HARD139 |
ok. checking now |
| 05:33 |
gregorycu |
It should use 100% of one core |
| 05:34 |
|
Zeno` joined #minetest-dev |
| 05:34 |
DI3HARD139 |
Only using roughly 80% atm |
| 05:35 |
gregorycu |
What's your FPS? |
| 05:35 |
gregorycu |
Surely not 1000 ? |
| 05:35 |
DI3HARD139 |
481 |
| 05:35 |
gregorycu |
Interesting |
| 05:36 |
DI3HARD139 |
constant. Thats using HDX256 though |
| 05:36 |
gregorycu |
Ahh ok |
| 05:36 |
gregorycu |
Basically, the more crap your graphics card is, the more CPU it will use |
| 05:36 |
gregorycu |
It's strange |
| 05:37 |
DI3HARD139 |
Thats OGL for ya. |
| 05:37 |
gregorycu |
Anyway, no need for massive FPS in main menu |
| 05:37 |
DI3HARD139 |
What GPU are you using? |
| 05:38 |
gregorycu |
HD 5700 |
| 05:38 |
gregorycu |
A model in that series, I can't remember which |
| 05:38 |
gregorycu |
The users reporting the issue were on laptops |
| 05:39 |
DI3HARD139 |
lemme get on my laptop. It has a Quadro 1000m |
| 05:40 |
gregorycu |
lol, you don't have to |
| 05:40 |
gregorycu |
But if you want, I'm not gunna stop you |
| 05:43 |
|
Hunterz joined #minetest-dev |
| 05:43 |
DI3HARD139 |
83% avg and 200fps |
| 05:44 |
gregorycu |
Do you have a fps_limit of 200? |
| 05:45 |
DI3HARD139 |
nope. I dont use FPS caps. Nor Vsync |
| 05:45 |
gregorycu |
Cool, if you make your fps_limit 20, you'll use next to no CPU |
| 05:45 |
Zeno` |
20? Wouldn't that be yucky to play? |
| 05:46 |
DI3HARD139 |
^ |
| 05:46 |
gregorycu |
lol |
| 05:46 |
gregorycu |
Not the main menu |
| 05:46 |
DI3HARD139 |
I like to maintain 60 if possible. Or if I have no choice 30 |
| 05:46 |
gregorycu |
In the main menu? |
| 05:47 |
gregorycu |
You're wanting to see the effect of decreasing the fps_max on the main menu, this is how :P |
| 05:47 |
gregorycu |
Or take my patch |
| 05:47 |
Zeno` |
oh, heh |
| 05:47 |
gregorycu |
I'm 99.9% certain my patch will fix the issue for the user |
| 05:48 |
gregorycu |
So, any investigation is for your own benefit DI3HARD139, unless you can +1 my patch that is |
| 05:48 |
Zeno` |
firefox is using 25% cpu! |
| 05:48 |
Zeno` |
sitting on the google homepage... no wonder my cpu is hotter than usual |
| 05:49 |
Zeno` |
Maybe I could limit its FPS somehow |
| 05:49 |
hmmmm |
[01:18 AM] <gregorycu> Maybe we can make it better, for instance, cache the results of the perlin noise stuff rather than recalculating |
| 05:49 |
hmmmm |
incredible |
| 05:49 |
est31 |
google uses you for mining bitcoins |
| 05:49 |
hmmmm |
perlin noise is still a bottleneck |
| 05:49 |
gregorycu |
hmmmm: Well, it is for the main menu cause it represents a significant chunk of CPU processing |
| 05:49 |
gregorycu |
In-game, probably less of a slice |
| 05:50 |
hmmmm |
this is a problem on android i take it? |
| 05:50 |
gregorycu |
It would be. But the issue was reported on laptops. |
| 05:50 |
DI3HARD139 |
Zeno': Have ya cleaned the heatsink out lately? |
| 05:50 |
hmmmm |
very interesting |
| 05:50 |
DI3HARD139 |
and changed the thermal compound? |
| 05:50 |
Zeno` |
DI3HARD139, about 20 minutes ago |
| 05:50 |
gregorycu |
#2226 |
| 05:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/2226 -- Minetest main menu uses a lot of CPU |
| 05:50 |
hmmmm |
on PCs at least, main menu takes up 1% cpu if anything at all |
| 05:51 |
hmmmm |
but the real question is should anybody be working on optimizing this so close to release |
| 05:51 |
gregorycu |
Did you check my patch? I mean, the contents? |
| 05:51 |
gregorycu |
We don't have to merge this now |
| 05:52 |
Zeno` |
I'm not sure if that really classifies as an optimisation per se, but even if it is we don't have to stop work just because a release is imminent :p |
| 05:52 |
hmmmm |
oh |
| 05:52 |
hmmmm |
that's really sweet and simple |
| 05:52 |
hmmmm |
sure, i approve of it |
| 05:52 |
Zeno` |
me too |
| 05:52 |
est31 |
me too |
| 05:52 |
Zeno` |
quickest approval ever |
| 05:53 |
gregorycu |
\o/ |
| 05:53 |
hmmmm |
pause_fps_max is like 15 by default right? |
| 05:54 |
gregorycu |
20 |
| 05:54 |
hmmmm |
yeah ok |
| 05:54 |
hmmmm |
and later on we'll (i will or you if you really want to) optimize clouds |
| 05:54 |
gregorycu |
Sounds good to me |
| 05:55 |
hmmmm |
a large enough buffer could be generated once and looped around |
| 05:55 |
hmmmm |
nobody is going to notice |
| 05:55 |
gregorycu |
Something to keep in mind, if the user has fps_max set to something very high |
| 05:55 |
hmmmm |
like one 80x500 strip of noise |
| 05:55 |
gregorycu |
(And we don't take my change) |
| 05:55 |
gregorycu |
We'll still churn through a lot of CPU |
| 05:55 |
gregorycu |
Cause drawing the clouds in the GPU is trivial |
| 05:56 |
VanessaE |
hmmmm: weren't clouds once done exactly like that at one time? |
| 05:56 |
gregorycu |
But yeah, should be optimised |
| 05:56 |
hmmmm |
vanessae, not to my knowledge. |
| 05:56 |
Zeno` |
But... what about the people who like to watch the clouds for hours looking for new shapes and patterns? |
| 05:56 |
hmmmm |
i wonder if there's a way to loop around a scene node in irrlicht |
| 05:56 |
hmmmm |
or tile it |
| 05:57 |
hmmmm |
cloud_strip_size = |
| 05:57 |
hmmmm |
they can set it to a zillion if they want |
| 05:57 |
Zeno` |
could we just do a shader that makes nice smoke |
| 05:57 |
Zeno` |
I suppose people would miss the nice clouds |
| 05:58 |
hmmmm |
maybe we can bulk generate perlin noise and generate it as a texture |
| 05:58 |
hmmmm |
then use that texture as data for the shaders |
| 05:58 |
Zeno` |
might work |
| 05:58 |
nore |
anyway, even if we keep generating the clouds, but with caching, ot wouldn't be very expensive, would it? |
| 05:59 |
hmmmm |
i feel like this is getting way out of scope though |
| 05:59 |
gregorycu |
Yeah |
| 05:59 |
hmmmm |
it's supposed to be a quick simple optimization |
| 05:59 |
gregorycu |
I'm all for a complicated optimisation if profiling indicates we would get significant gain |
| 05:59 |
gregorycu |
Clouds are only a major problem in the main menu |
| 06:00 |
gregorycu |
I can take a look at clouds later to see if the actual game would benefit |
| 06:01 |
Zeno` |
why use perlin noise for the menu clouds at all? |
| 06:01 |
hmmmm |
what should be used instead..? |
| 06:01 |
hmmmm |
perlin noise is not a heavy operation, the cloud generator is just doing it wrong |
| 06:01 |
Zeno` |
they're just squares ... surely any PRNG could do the job of queuing a new cloud or two that will emerge next |
| 06:02 |
hmmmm |
it takes under 1 millisecond to generate 80x80 of the data |
| 06:02 |
Zeno` |
oh, well that's nothing |
| 06:05 |
hmmmm |
yeah |
| 06:05 |
hmmmm |
i have an idea for a good algorithm to do clouds (and more generally all kinds of smoke) with shaders |
| 06:06 |
hmmmm |
it's just a matter of asking, do the players want that or do they want the characteristic clouds of minetest that they're used of |
| 06:07 |
est31 |
well in the worst case we add an option for the legacy clouds |
| 06:07 |
est31 |
in fact we do require this as shaders are optional |
| 06:09 |
hmmmm |
how do video games usually implement clouds? |
| 06:09 |
hmmmm |
i'm wondering if using perlin to generate them is overboard |
| 06:16 |
DI3HARD139 |
They are usually particle shaders. |
| 06:20 |
Zeno` |
c64, amiga etc used to use just normal random numbers (the clouds are really just an oversized starfield if you look at them in a certain way) |
| 06:21 |
Zeno` |
big blobs instead of points (or balls) |
| 07:02 |
|
jin_xi joined #minetest-dev |
| 07:11 |
|
blaze joined #minetest-dev |
| 07:13 |
jin_xi |
est31: so i have a bad feeling about that pathfinder PR. it got merged w/o much discussion and does a controvesial thing, and i wonder if thats gonna cause headaches for some after release |
| 07:15 |
jin_xi |
its pull no 2651 and the issue is 3453 |
| 07:24 |
nore |
~tell paramat maybe merge #3907 since freeze is today... |
| 07:24 |
ShadowBot |
nore: O.K. |
| 07:25 |
nore |
hmm, interesting, ShadowBot doesn't links PRs when you use ~tell |
| 07:27 |
gregorycu |
#3453 |
| 07:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/3453 -- minetest.find_path returns extremely bloated path |
| 07:29 |
|
bugzapper joined #minetest-dev |
| 07:34 |
|
Zeno` joined #minetest-dev |
| 07:36 |
|
Krock joined #minetest-dev |
| 07:36 |
Zeno` |
will merge #4025 shortly (3 approvals) |
| 07:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/4025 -- Fix for Main Menu uses a lot of CPU by gregorycu |
| 07:37 |
gregorycu |
Thanks Zeno |
| 07:37 |
Zeno` |
np |
| 07:41 |
Zeno` |
done and done and done |
| 07:42 |
Zeno` |
and CPU is still on 27C :D |
| 07:42 |
gregorycu |
Hooray! |
| 07:43 |
gregorycu |
What happens with the bug? |
| 07:43 |
Krock |
roast and eat it |
| 07:43 |
gregorycu |
(Shouldn't github close it automatically?) |
| 07:45 |
Zeno` |
oh.. I'll close it |
| 07:46 |
Zeno` |
it probably would close it if I used github to commit (I dunno... don't trust github heh) |
| 07:46 |
|
Megal_ joined #minetest-dev |
| 07:46 |
gregorycu |
Ahh ok |
| 07:47 |
gregorycu |
Yeah, i didn't have |
| 07:47 |
gregorycu |
"Fixed #blah" in the commit message |
| 07:47 |
gregorycu |
Only the PR |
| 07:47 |
Zeno` |
Those github "merge now" buttons scare me |
| 07:47 |
Zeno` |
I think I used it once and it went all FUBAR |
| 07:49 |
est31 |
they have been changed since |
| 07:49 |
est31 |
github introduced a merge + squash feature |
| 07:50 |
est31 |
basically the same thing we did before all the time |
| 07:50 |
est31 |
no merge commit created |
| 07:50 |
est31 |
and c55 has enabled the feature by default, without a way to not do it |
| 07:51 |
Krock |
So, updated #4016 with est31's comments |
| 07:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/4016 -- tile.cpp: Automatically resize overlaying texture to base dimensions by SmallJoker |
| 07:52 |
Zeno` |
est31, so it will work as expected now? |
| 07:52 |
est31 |
Zeno`, yes, try it :) |
| 07:52 |
* Zeno` |
looks at the green button in terror |
| 07:52 |
est31 |
:) |
| 07:52 |
Zeno` |
heh |
| 07:52 |
est31 |
https://github.com/blog/2141-squash-your-commits |
| 07:53 |
est31 |
and its no april fools joke despite the date |
| 07:55 |
Zeno` |
I'll try it. Although I don't mind just typing it |
| 07:55 |
Zeno` |
gives me a chance to test etc |
| 07:55 |
Zeno` |
overly paranoid perhaps, but *shrug* |
| 07:56 |
Zeno` |
does it let me abort if I click it just as a test? |
| 07:56 |
est31 |
there is a second dialog before, you must do two clicks to merge a pr |
| 07:56 |
Zeno` |
ok, I'm willing to try it out in that case |
| 07:56 |
Zeno` |
next commit |
| 07:58 |
Zeno` |
It may have made committing nore's PR last night easier (git am didn't work) |
| 07:58 |
Zeno` |
I had to branch from an earlier commit, squash, rebase and apply to master... kind of annoying |
| 07:59 |
Zeno` |
but github was saying it would merge no problems so maybe it does fancy stuff |
| 08:02 |
gregorycu |
I'm looking at #3511 |
| 08:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/3511 -- Setting an item's range high results in poor performance |
| 08:03 |
est31 |
gregorycu, thats because we dont do real ray tracing |
| 08:03 |
gregorycu |
Yeah |
| 08:03 |
est31 |
we need to do some improved version of bresenham's algorithm or something |
| 08:03 |
gregorycu |
We basically get every node in a octant, and then see if we collide with it |
| 08:03 |
est31 |
yeah |
| 08:04 |
est31 |
pretty inefficient |
| 08:04 |
gregorycu |
That's reasonably intensive |
| 08:04 |
Zeno` |
oooh, I've done lots of modified bresenham's. I even modified it to rotate and zoom pixmaps heh |
| 08:04 |
gregorycu |
What I suggest that, as a stop-gap measure, when the wield distance is over some threshold, like 20, we precull nodes where the angle to the node is greater than the camera angle |
| 08:05 |
gregorycu |
It's not perfect, but for large draw distances, it should significantly improve performance |
| 08:05 |
est31 |
yeah |
| 08:05 |
Zeno` |
for large draw distances wouldn't error be more applicable anyway (so culling shouldn't make all that much negative difference) |
| 08:06 |
gregorycu |
I'm about to test it out |
| 08:06 |
gregorycu |
How I've implemented it, for nodes near the user, no culling happens, for nodes far away, culling occurs |
| 08:07 |
gregorycu |
And this logic only kicks in when the tool has a large wield distance |
| 08:07 |
gregorycu |
So yeah, as you say Zeno, shouldn't make any difference to correctness |
| 08:09 |
Zeno` |
seems like a valid conclusion |
| 08:23 |
jin_xi |
so im still trying out some stuff for particle collision overhaul: here is a greedy mesher making meshes used for collision detection. now trying to get it to make the right block at the right position. |
| 08:23 |
jin_xi |
http://imgur.com/ZAaYxlz |
| 08:23 |
Krock |
cool structure |
| 08:29 |
jin_xi |
so what i am wondering about is how to let particle systems keep track of map changes. just re-meshing every step is too slow |
| 08:30 |
jin_xi |
and for digging particles many particle systems actually use the same block, so sharing those would be nice |
| 08:31 |
jin_xi |
and i keep thinking that if these problems are solved this method of collision detection could be used for other stuff |
| 08:31 |
jin_xi |
avoiding all the issues with unfitting, non-rotating collision boxes |
| 08:51 |
gregorycu |
I can improve FPS from 22 to 38 |
| 08:51 |
gregorycu |
It's still pretty shit though |
| 08:53 |
jin_xi |
here is another thing i wonder about: irrlicht code comments say its meshmanipulator is not intended for use inside render loops, yet minetest does exactly that |
| 08:53 |
jin_xi |
https://sourceforge.net/p/irrlicht/code/HEAD/tree/trunk/source/Irrlicht/CMeshManipulator.h#l17 |
| 08:56 |
est31 |
no |
| 08:56 |
est31 |
we manipulate the meshes not inside render loops |
| 08:56 |
est31 |
we manipulate them in a separate thread even |
| 09:02 |
jin_xi |
oh ok, well thats good to know |
| 09:06 |
|
davisonio joined #minetest-dev |
| 09:16 |
gregorycu |
I was thinking about bresenham |
| 09:17 |
gregorycu |
But I'm not sure |
| 09:17 |
gregorycu |
I think the current implemention could be modified to scan an small octant, move the origin, then the next octant, move origin, next octant |
| 09:18 |
gregorycu |
With a little bit of overlap |
| 09:20 |
gregorycu |
Maybe I should attempt bresnham |
| 09:28 |
Zeno` |
gregorycu, on an unrelated project I profiled bresenham vs. floating point and the results were not compellingly different |
| 09:28 |
gregorycu |
What do you mean "floating point" |
| 09:28 |
Zeno` |
as long as there is an FPU (what doesn't have one these days?) then the difference is not great |
| 09:29 |
Zeno` |
just using floating point calculations instead of accumulating errors in integers like bresenham |
| 09:29 |
gregorycu |
Right |
| 09:29 |
Zeno` |
but, it depends of course how you optimise it... |
| 09:29 |
gregorycu |
bresenham isn't good enough though, at least, a simple implementation |
| 09:29 |
gregorycu |
It "misses" corners |
| 09:30 |
Zeno` |
it does? |
| 09:30 |
Zeno` |
mine doesn't |
| 09:30 |
Zeno` |
although it would (might) depend on distance |
| 09:30 |
Zeno` |
so you're correct |
| 09:31 |
gregorycu |
https://upload.wikimedia.org/wikipedia/commons/thumb/a/ab/Bresenham.svg/300px-Bresenham.svg.png |
| 09:31 |
Zeno` |
the best thing about bresenham (and it might not even be applicable here) is the reduction down to 4 octants using reflection etc |
| 09:32 |
Zeno` |
oh you mean that... yeah |
| 09:33 |
Zeno` |
I thought you were referring to something else :) |
| 09:33 |
gregorycu |
bresenham basically increments the smaller of the x and y component |
| 09:33 |
gregorycu |
Right? |
| 09:33 |
Zeno` |
normally |
| 09:33 |
gregorycu |
And increments the other by 1, or if the error has built up, 2 |
| 09:33 |
gregorycu |
Or 0 and 1 |
| 09:33 |
gregorycu |
Sorry |
| 09:34 |
Zeno` |
but if you look at optimised versions not really |
| 09:34 |
Zeno` |
If I was in Windows I'd email you the papers I have |
| 09:34 |
Zeno` |
but you'll find them |
| 09:34 |
Zeno` |
unless you'd like me to reboot? |
| 09:34 |
gregorycu |
We don't have to be superfast here |
| 09:34 |
gregorycu |
Nah |
| 09:34 |
Zeno` |
I'll email them to you later in any case (unless you mind) |
| 09:35 |
Zeno` |
they're a good read |
| 09:35 |
gregorycu |
We are currently looking at 1million nodes for a tool with range of 100 |
| 09:35 |
gregorycu |
Looking at a node requires a lookup in a std::map |
| 09:35 |
Zeno` |
*nod* |
| 09:35 |
gregorycu |
So yeah, we don't need a superfast algo to improve that |
| 09:35 |
gregorycu |
Also have to be careful not to slow down tool range < 10 |
| 09:37 |
gregorycu |
I think I have an algo to try |
| 09:38 |
Zeno` |
The gregorycu super-algo! |
| 09:38 |
Zeno` |
(TM)(C)(R) |
| 09:38 |
|
lisac joined #minetest-dev |
| 09:38 |
Zeno` |
Google Cardboard support... |
| 09:39 |
Zeno` |
anyone feel like doing that? :) |
| 09:40 |
Zeno` |
ugh I jumped out of my tank and it destroyed my solar farm |
| 09:40 |
Zeno` |
err... sorry... meant to pm |
| 09:41 |
|
neoascetic joined #minetest-dev |
| 09:41 |
neoascetic |
Does feature freeze mean there will be new release soon? |
| 09:42 |
Zeno` |
neoascetic, yes |
| 09:42 |
neoascetic |
Great! Tried v7 just now and it looks absolutely awesome |
| 09:43 |
Zeno` |
I think paramat is aiming for 1-2 weeks of feature freeze (but don't quote me on that) |
| 09:47 |
neoascetic |
Meanwhile, I've put addition $10 on #3440 |
| 09:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/3440 -- Client side Lua scripting |
| 09:47 |
neoascetic |
I know this is pretty small but anyway... |
| 09:50 |
gregorycu |
$10 how? |
| 09:51 |
gregorycu |
Ahh bounty |
| 09:51 |
gregorycu |
Nice |
| 09:52 |
|
Player_2 joined #minetest-dev |
| 09:57 |
gregorycu |
I've added $15 |
| 09:59 |
neoascetic |
awesome |
| 10:00 |
neoascetic |
I think this feature will be a huge improvement |
| 10:00 |
|
Foghrye4 joined #minetest-dev |
| 10:01 |
neoascetic |
AFAIK the only person who claim bounty from bountysource is me. My own bounties. Lol |
| 10:01 |
gregorycu |
And now mine, apparently |
| 10:08 |
Calinou |
>implying bounties are ever used |
| 10:10 |
gregorycu |
I don't think that was the implication |
| 10:10 |
gregorycu |
Hopefully people can back a few things |
| 10:11 |
gregorycu |
After we somehow give project admins access to the bounty claiming |
| 10:12 |
lisac |
nore: Are you there? |
| 10:18 |
Zeno` |
must have been nore's secret admirer |
| 10:34 |
|
davisonio joined #minetest-dev |
| 10:45 |
|
davisonio joined #minetest-dev |
| 11:00 |
|
davisonio joined #minetest-dev |
| 11:43 |
gregorycu |
hmm... I think I've done it |
| 11:44 |
gregorycu |
A 3d Bresenham thing |
| 11:45 |
gregorycu |
More like some sort of interpolation machine |
| 12:11 |
|
PilzAdam joined #minetest-dev |
| 12:27 |
|
Krock joined #minetest-dev |
| 12:30 |
|
Fixer joined #minetest-dev |
| 12:33 |
|
Amaz joined #minetest-dev |
| 12:40 |
gregorycu |
Fixer: Hello |
| 12:43 |
|
gregorycu_ joined #minetest-dev |
| 12:44 |
|
damiel joined #minetest-dev |
| 12:46 |
|
iangp joined #minetest-dev |
| 12:46 |
|
davisonio joined #minetest-dev |
| 12:51 |
|
DFeniks joined #minetest-dev |
| 13:26 |
|
millersman joined #minetest-dev |
| 13:32 |
Fixer |
gregorycu, ohi |
| 13:32 |
Fixer |
gregorycu, something interesting for me? %) |
| 13:33 |
Fixer |
gregorycu, jitter? 3770? |
| 13:33 |
gregorycu |
#3770 |
| 13:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/3770 -- Fix superflous shader setting updates by ShadowNinja |
| 13:34 |
gregorycu |
Ahh, that thing |
| 13:34 |
gregorycu |
#3511 |
| 13:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/3511 -- Setting an item's range high results in poor performance |
| 13:34 |
gregorycu |
That's what I'm looking at at the moment |
| 13:34 |
|
Zeno` joined #minetest-dev |
| 13:36 |
gregorycu |
Yeah, you can make code much faster by not doing calculations it seems |
| 13:36 |
Zeno` |
amazing :) |
| 13:44 |
Krock |
Rebased #3267 |
| 13:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/3267 -- Standardize the menu button order and sizes by SmallJoker |
| 13:51 |
gregorycu |
This code is blisteringly fast |
| 13:51 |
gregorycu |
But buggy |
| 13:51 |
gregorycu |
And a real PITA to debug |
| 13:56 |
Zeno` |
sounds perfect! |
| 13:56 |
gregorycu |
Like 5 fps to 140 |
| 14:00 |
Zeno` |
really? |
| 14:01 |
gregorycu |
I think that was debug, so it doesn't really count |
| 14:01 |
gregorycu |
But yeah |
| 14:02 |
|
proller joined #minetest-dev |
| 14:02 |
|
davisonio joined #minetest-dev |
| 14:05 |
gregorycu |
Examining 1M nodes is indeed slower than examaning 400 |
| 14:09 |
|
Calinou joined #minetest-dev |
| 14:21 |
|
hmmmm joined #minetest-dev |
| 14:21 |
|
yasnothil joined #minetest-dev |
| 14:31 |
gregorycu |
*sigh* Everything was going so well, until it crashed |
| 14:38 |
|
kaadmy joined #minetest-dev |
| 15:04 |
|
Void7_ joined #minetest-dev |
| 15:06 |
* gregorycu |
is a happy chappy now |
| 15:08 |
gregorycu |
In release build, 250 fps, instead of 30 |
| 15:12 |
PilzAdam |
gregorycu, when using a tool with a high range? |
| 15:12 |
gregorycu |
Yeah |
| 15:12 |
gregorycu |
With a range of 100 |
| 15:13 |
gregorycu |
Range of 200 should be only 2 times slower than 100 |
| 15:13 |
PilzAdam |
what is the performance difference with a range 4 tool compared to a range 100 tool with your new code? |
| 15:13 |
gregorycu |
In terms of FPS? |
| 15:14 |
PilzAdam |
yep |
| 15:14 |
gregorycu |
Hard to tell... I'll try to figure out |
| 15:16 |
gregorycu |
lol |
| 15:16 |
gregorycu |
Give me a sec, for some reason holding a screwdriver results in better FPS than sand |
| 15:20 |
gregorycu |
Ok, so stone pick (range of 3) vs steel pick (range of 150) |
| 15:20 |
gregorycu |
Same FPS |
| 15:20 |
gregorycu |
~240 for me |
| 15:21 |
PilzAdam |
thats great |
| 15:21 |
gregorycu |
It goes from 220 - 240 no matter which tool |
| 15:21 |
PilzAdam |
we could give the creative hand in mt_game a larger range now |
| 15:22 |
gregorycu |
Well, I have to create a PR first |
| 15:23 |
gregorycu |
lol @ destroying things far in the distance |
| 15:23 |
gregorycu |
I can only tell cause the selection box is changing, it's so far away |
| 15:25 |
gregorycu |
I've very happy with this, and it only took me 8 hours |
| 15:25 |
gregorycu |
Time for a hot drink, bb in 10 min |
| 15:46 |
Zeno` |
a nice warm irish cream |
| 15:47 |
gregorycu |
I see what you did there |
| 16:01 |
|
rubenwardy joined #minetest-dev |
| 16:04 |
gregorycu |
#4027 |
| 16:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/4027 -- Make getPointedThing faster by gregorycu |
| 16:05 |
gregorycu |
PilzAdam: You can have a play with that PR if you want to test your creative hand |
| 16:07 |
|
davisonio joined #minetest-dev |
| 16:09 |
|
louiloui joined #minetest-dev |
| 16:17 |
Krock |
gregorycu, so how much better is this change than before? |
| 16:17 |
|
Void7_ joined #minetest-dev |
| 16:18 |
gregorycu |
With the old code, and a tool with wield range of 100, the FPS for me was 30 |
| 16:18 |
gregorycu |
Now it's 240 |
| 16:19 |
Krock |
looks a bit too complex for me :< |
| 16:20 |
gregorycu |
It's a little math heavy |
| 16:20 |
gregorycu |
Oops, I meant to rename a variable before commiting |
| 16:21 |
gregorycu |
Zeno`: Did you want me to fix up aabb3f box = *i; while I'm at it? |
| 16:23 |
gregorycu |
Krock: The old code used to check an octant (which is like a quadrant but in 3d). It would try and intersect distance ^ 3 nodes |
| 16:23 |
|
jin_xi joined #minetest-dev |
| 16:24 |
gregorycu |
My code starts near the camera and moves away, selecting nodes likely to intersect |
| 16:24 |
Zeno` |
gregorycu, I just wondered why you were making copies of objects when copies are not needed |
| 16:25 |
gregorycu |
yeah, the old code did it |
| 16:25 |
Zeno` |
silly old code :( |
| 16:25 |
gregorycu |
I was trying to not change that code so the diff would line up, but it's fucked anyway |
| 16:25 |
gregorycu |
I'll amend it |
| 16:25 |
Zeno` |
lol, cool :) |
| 16:30 |
Zeno` |
gregorycu, I haven't tested but it looks great |
| 16:31 |
Zeno` |
very neat solution |
| 16:32 |
gregorycu |
Thank you |
| 16:47 |
|
turtleman joined #minetest-dev |
| 17:03 |
nore |
gregorycu: did you test with doors though? |
| 17:03 |
gregorycu |
lol doors? |
| 17:03 |
nore |
Their selection box is bigger than the node |
| 17:04 |
nore |
two nodes, to be more precise |
| 17:04 |
gregorycu |
What's the item name? |
| 17:04 |
Zeno` |
yeah, they sang great songs like "Touch Me" and "Gloria" |
| 17:05 |
nore |
doors:door_wood iirc |
| 17:06 |
gregorycu |
No problem with doors it seems |
| 17:06 |
Zeno` |
Well, except that Jim Morrison died |
| 17:07 |
gregorycu |
Are doors nodes or entities? |
| 17:07 |
nore |
gregorycu: oh, interesting but surprising |
| 17:07 |
gregorycu |
Yeah, it selects the door, doesn't select things behind the door |
| 17:07 |
Zeno` |
nore, I thought you were going away for a week |
| 17:08 |
nore |
they are nodes, but how recent if your minetest_game? |
| 17:08 |
gregorycu |
A door is apparently two things |
| 17:08 |
gregorycu |
door_wood_t and door_wood_b |
| 17:08 |
nore |
Zeno`: I am, I am using my phone ;) |
| 17:08 |
Zeno` |
haha, addicted :) |
| 17:08 |
gregorycu |
Probably not that receint |
| 17:08 |
nore |
gregorycu: then this is an old mtg |
| 17:09 |
nore |
Zeno`: maybe :D |
| 17:10 |
nore |
(well, I am visiting Sweden right now, but since I have nothing to do on the evening :)) |
| 17:10 |
gregorycu |
I'll get latest minetest_game |
| 17:14 |
gregorycu |
Yeah |
| 17:14 |
gregorycu |
I broke doors |
| 17:14 |
gregorycu |
FML |
| 17:14 |
gregorycu |
Well, how large can a selection box be? |
| 17:16 |
gregorycu |
Who needs door anyway, amirite? |
| 17:17 |
nore |
I don't know, they could be quite big |
| 17:18 |
nore |
but I think it is reasonable to disallow selection boxes to get more than one node away |
| 17:18 |
gregorycu |
1 is just some value of n |
| 17:19 |
gregorycu |
I think this is already broken, but less obviously so |
| 17:19 |
nore |
or even to disallow them to be bigger than the node, with some kind of way to make them bigger (with a ghost node of something like that) |
| 17:19 |
nore |
something like, a ghost node saying "look at that node instead of me" |
| 17:20 |
gregorycu |
Or I can just special case for doors, and have it always check one node below |
| 17:20 |
nore |
sofar: your opinions on that? (since it was you who rewrote doors...) |
| 17:21 |
nore |
hmm, then maybe a callback to say to the engine that it should check in some direction too |
| 17:22 |
nore |
and add that to the doors code |
| 17:22 |
nore |
(new clients wouldn't be compatible with old servers though) |
| 17:24 |
gregorycu |
Well, my special casing works |
| 17:24 |
nore |
did you try beds too? |
| 17:25 |
gregorycu |
Of course not, I'm not a good developer |
| 17:25 |
gregorycu |
I'll check out beds |
| 17:25 |
nore |
(more special cases I guess) |
| 17:25 |
nore |
so, I think just one node away is reasonable |
| 17:26 |
nore |
with documentation to go with it |
| 17:28 |
gregorycu |
Yeah, beds are also broken |
| 17:28 |
gregorycu |
What prevents me from building over the top of a bed? |
| 17:28 |
gregorycu |
I mean, the part that isn't the node |
| 17:29 |
nore |
So, do you think one node in each direction is a good compromise? What does it give on performance? |
| 17:29 |
nore |
gregorycu: there is another, not pointable but not buildable_to node |
| 17:30 |
gregorycu |
Maybe these things should be entities instead |
| 17:31 |
gregorycu |
I can do 1 in every direction, the perf hit won't be too bad |
| 17:31 |
nore |
no, entities are not a good idea for static things |
| 17:32 |
nore |
There are a lot of problems with entities |
| 17:32 |
sofar |
ideas? he broke it! ;) |
| 17:33 |
nore |
Including /clearobjects, the maximum number of static entities per block, and a lot of other things |
| 17:34 |
nore |
sofar: well, what do you think is better: keep his PR and fix doors and beds, or add the one-node-away check? ;) |
| 17:34 |
nore |
(Which would cost some performance though, even if I think it wouldn't be that much) |
| 17:34 |
|
millersman joined #minetest-dev |
| 17:35 |
gregorycu |
Ok, the one node thing works |
| 17:35 |
gregorycu |
If that's the rule |
| 17:35 |
nore |
I think the one-node-rule wouldn't break any mods |
| 17:35 |
gregorycu |
hmm... |
| 17:35 |
nore |
And it wouldn't cost too much (just a factor 7) |
| 17:35 |
gregorycu |
This must be broken already |
| 17:36 |
nore |
Why do you say that? |
| 17:37 |
gregorycu |
Cause I know how the old logic used to work |
| 17:39 |
nore |
Ah, and what was the problem? |
| 17:40 |
gregorycu |
The old code used to do the +1 trick |
| 17:41 |
gregorycu |
The problem with the old code |
| 17:41 |
gregorycu |
Well |
| 17:41 |
sofar |
how would we fix doors and beds? sorry, I missed the proposed change |
| 17:41 |
gregorycu |
Don't worry about doors and beds, the amendment will work |
| 17:41 |
* sofar |
still confused, has espresso |
| 17:42 |
gregorycu |
nore: Do you know what a quadrant is? |
| 17:42 |
sofar |
gregorycu: you could even optimize it |
| 17:42 |
sofar |
gregorycu: 1 node up is logical |
| 17:42 |
nore |
gregorycu: yes |
| 17:42 |
sofar |
due to "visual_size" |
| 17:42 |
gregorycu |
sofar: beds are one node across |
| 17:42 |
sofar |
hmm, yes |
| 17:42 |
sofar |
but never down |
| 17:43 |
gregorycu |
sofar: That means I can optimise away 1 of 8 |
| 17:43 |
gregorycu |
nore: Do you know what an octant is? |
| 17:43 |
nore |
gregorycu: yes too |
| 17:44 |
nore |
sofar: the proposed change is to allow nodes to have a selection box extending up to one node away |
| 17:44 |
gregorycu |
nore: Awesome. The old code would test an entire octant for things the player may be pointing at |
| 17:44 |
sofar |
that's fine |
| 17:44 |
sofar |
selection boxes are client-side things |
| 17:44 |
nore |
Yeah, that was what I thought |
| 17:44 |
gregorycu |
nore: So, if the tool had a range of 100, it would search 100 * 100 * 100 nodes |
| 17:45 |
nore |
But, I was unable to make that break doors (although I tried hard, because I thought it would) |
| 17:45 |
nore |
gregorycu: bad for performance, indeed |
| 17:45 |
gregorycu |
Looking at the code, it ensures that the octant also includes slightly more than 1/8th |
| 17:45 |
gregorycu |
More like 101 * 101 * 101 |
| 17:46 |
nore |
Oh, that's why it worked |
| 17:46 |
gregorycu |
Yeah |
| 17:46 |
gregorycu |
So yeah, 1 million nodes are checked |
| 17:46 |
nore |
And that means that selection boxes extending further that one node were also broken |
| 17:46 |
gregorycu |
Yes |
| 17:46 |
nore |
So we're not breaking anything :) |
| 17:47 |
gregorycu |
Correct |
| 17:47 |
* nore |
likes it |
| 17:47 |
gregorycu |
The other thing we could do is store a list of nodes with large selection boxes |
| 17:47 |
gregorycu |
Or whatever, some structure |
| 17:47 |
gregorycu |
And explicitly test them |
| 17:48 |
nore |
hm, I don't know what the best would be |
| 17:48 |
gregorycu |
Probably slower than just increasing the scope of checking |
| 17:48 |
nore |
I think so too |
| 17:48 |
nore |
Increasing the scope looks like a good idea to me |
| 17:49 |
nore |
Best way would also probably be to first check the intersection on the main line |
| 17:49 |
nore |
And then, check the oversized selection boxes that are a bit away |
| 17:50 |
nore |
Using the node that was first found to reduce the number of checked nodes |
| 17:50 |
gregorycu |
Checking a node isn't too slow |
| 17:50 |
gregorycu |
Just when there are a million of them... |
| 17:52 |
nore |
:D |
| 17:52 |
gregorycu |
Bed time for me |
| 17:52 |
hmmmm |
I'm confused |
| 17:52 |
hmmmm |
isn't this hit detection for particles? |
| 17:53 |
hmmmm |
particles are usually very small and unlikely to hit more than one node at a time |
| 17:53 |
nore |
hmmmm: no, it is getPointedThing |
| 17:53 |
hmmmm |
instead of an intersection of several polygons, can't it be a line instead? |
| 17:54 |
hmmmm |
that's the smae thing |
| 17:54 |
hmmmm |
they're both casting rays |
| 17:54 |
hmmmm |
how is this slow? |
| 17:58 |
nore |
hmmmm: what happens is that the current code checks the whole octant |
| 17:58 |
nore |
Instead of just checking the casted ray |
| 17:59 |
nore |
Gtg, bbl |
| 17:59 |
hmmmm |
by octant you mean 2x2x2 cluster of nodes? |
| 18:01 |
jin_xi |
moar like distance^3 |
| 18:01 |
hmmmm |
doesn't make sense to me, i should probably look at what the code is actually doing.. |
| 18:02 |
|
turtleman joined #minetest-dev |
| 18:03 |
|
DI3HARD139 joined #minetest-dev |
| 18:09 |
|
davisonio joined #minetest-dev |
| 18:15 |
kaadmy |
long range tools? :] |
| 18:16 |
|
electrodude512 joined #minetest-dev |
| 18:16 |
Krock |
Wuzzy (IIRC) wrote a teleproter stick with a huge range of pointing a node |
| 18:16 |
Krock |
as destination location |
| 18:16 |
|
Void7 joined #minetest-dev |
| 18:52 |
* sofar |
scratches head and wonders how to get a handle on INodeDefManager inside pathfinder.cpp |
| 18:52 |
sofar |
see https://github.com/minetest/minetest/issues/1701#issuecomment-214022155 |
| 18:56 |
sofar |
anyone know? |
| 18:58 |
jin_xi |
env->gamedef->nodemanager? |
| 19:02 |
sofar |
INodeDefManager *ndef = m_env->getGameDef()->ndef(); |
| 19:02 |
sofar |
that did something... |
| 19:24 |
hmmmm |
guys is it okay if i rant a little bit in this channel |
| 19:24 |
hmmmm |
need to dump my ideas about biomemanager architecture that i came up with while taking a shit |
| 19:25 |
hmmmm |
----------------- so we have a couple of requirements that are unfulfilled by the current implementation of BiomeManager |
| 19:25 |
VanessaE |
hmmmm: well you're off by about 12 hours but go aheaed :) |
| 19:25 |
hmmmm |
it's monolithic, and does not handle separation of concerns well |
| 19:25 |
hmmmm |
- i want to be able to specify unique biome parameters for each mapgen |
| 19:26 |
hmmmm |
- i want the biomemanager to handle all biome related computation - the mapgen should be able to give it parameters x y z and get a result |
| 19:26 |
hmmmm |
so right now there is only one biomemanager shared across all mapgens |
| 19:27 |
hmmmm |
and this is okay to do without synchronization because we made the contract that the biome list becomes read-only after the mod initialization phase |
| 19:28 |
hmmmm |
but each mapgen needs its own set of noise values at any given time, so the workaround is that the mapgens provide the noise objects to the biome calc functions |
| 19:28 |
hmmmm |
this is fine but it disrupts separation of concerns |
| 19:28 |
hmmmm |
because now the mapgen is responsible for knowing what types of noises are needed for biome calculation |
| 19:29 |
hmmmm |
the solution here would be to have a single BiomeManager per thread, clearly, but we don't want to deal with keeping the biome lists across all instances of BiomeManager synchronized |
| 19:30 |
hmmmm |
so we'll retain the single BiomeManager as an element of the EmergeManager and we more clearly define BiomeManager's role as maintaining the biome list and handling the lookups |
| 19:31 |
hmmmm |
we delegate biome *computation* to a new, separate class that each mapgen creates that exists on a per-thread basis |
| 19:31 |
hmmmm |
what its name should be is not known at this point because i'm not 100% sure about what the responsibilities of this class is going to be yet |
| 19:32 |
hmmmm |
but at the very least, it's going to be initialized with some of the same parameters for the mapgen |
| 19:32 |
hmmmm |
but it's not going to be tied *to* the mapgen as the dungeongen is for example |
| 19:33 |
hmmmm |
organizationally speaking, DungeonGen is a complete fuckup |
| 19:33 |
hmmmm |
we do not want to repeat this again |
| 19:35 |
hmmmm |
BiomeCalculator biomecalc(biomemgr, chunksize); ... biomecalc.generateAndCacheBiomes(node_min); .... Biome *b = biomecalc.getBiomeAtPoint(p); I guess? pretty straightforward |
| 19:36 |
hmmmm |
so we're going to have one kind of list of biomes, that is the BiomeManager |
| 19:36 |
hmmmm |
but we're going to have many different ways to compute which of these biomes is chosen |
| 19:37 |
hmmmm |
BiomeCalculator is going to be an interface, and the current approach to calculation (intersection of temperature and humidity) is going to just be one implementation |
| 19:38 |
hmmmm |
which approach to calculation will be used is going to be handled the same way the rest of the biome configuration will be |
| 19:38 |
hmmmm |
per mapgen |
| 19:38 |
hmmmm |
this is going to be generalized in the same way mapgen configuration will be |
| 19:39 |
hmmmm |
there'll exist a mapgen configuration script (so e.g. mapgen_v7.lua, mapgen_singlenode.lua) for each builtin mapgen that's executed upon final determination of the mapgen type |
| 19:39 |
hmmmm |
here, this is where mapgen noise parameters will be set, and biome parameters chosen as well |
| 19:40 |
hmmmm |
while i'm doing this i'd like to remove the mapgen params from the config files once and for all - that was a bad idea due to the sheer amount of configuration bloat but i didn't see it at the time |
| 19:40 |
|
ElectronLibre joined #minetest-dev |
| 19:40 |
hmmmm |
of course this will break reverse compatibility |
| 19:40 |
hmmmm |
i'm going to go off on a limb and say fuck reverse compatibility this time |
| 19:41 |
hmmmm |
people will just need to understand that they need to create a mod for their custom mapgen parameters if they want to make a *new* world with custom params |
| 19:41 |
hmmmm |
of course this won't break previously existing worlds because the parameters have been copied to map_meta.txt |
| 19:41 |
hmmmm |
</rant> |
| 19:42 |
hmmmm |
putting thoughts into words really helps me organize it all |
| 19:42 |
hmmmm |
now i'm going to do it |
| 20:02 |
|
nrzkt joined #minetest-dev |
| 20:18 |
|
Void7 joined #minetest-dev |
| 21:21 |
|
AnotherBrick joined #minetest-dev |
| 21:27 |
|
jhcole joined #minetest-dev |
| 21:28 |
jhcole |
for any minetest-mods dev, issue tracking is disabled for the castle mod; is that on purpose? |
| 21:30 |
VanessaE |
sofar: ^^^ |
| 21:52 |
sofar |
jhcole: no, just means it wasn't enabled originally |
| 21:53 |
sofar |
issues now enabled |
| 21:53 |
jhcole |
sofar: thanks, i'll be making use of it soon :) |
| 22:45 |
|
Megal joined #minetest-dev |
| 22:48 |
sofar |
woot, I got my sheep to jump |
| 22:57 |
|
yang2003 joined #minetest-dev |
| 23:26 |
|
AFK7 joined #minetest-dev |
