Time Nick Message 02:14 paramat RealBadAngel halo now acts on objects and items? so i can close #2080? 02:14 ShadowBot https://github.com/minetest/minetest/issues/2080 -- Object highlight 02:14 RealBadAngel lemme check 02:15 RealBadAngel yes, it does work now with any objects 02:16 paramat ok 02:17 RealBadAngel so, 603 to go ;) 02:19 paramat sure that #2687 is fixed? 02:19 ShadowBot https://github.com/minetest/minetest/issues/2687 -- Node highlighting makes particles inside mesh nodes (plants) hidden 02:19 paramat ^ sofar 02:20 paramat perhaps that can be checked sometime 02:21 RealBadAngel easily, start to dig a node with halo on 02:23 RealBadAngel those were artifacts of halo being done in mapblock mesh together with block mesh 02:23 RealBadAngel halo now is independent 02:24 RealBadAngel its rendered as the last element of the world at all 02:24 RealBadAngel so from very definition it cannot cause any such glitches 02:32 paramat with nametags moved out of world render, is it then possible to fix camera far plane for clouds to 2000 nodes and allow camera far plane for world to be reduced to view range? 02:33 paramat in other words were nametags keeping camera far plane unnecessarily far away? 02:33 RealBadAngel no 02:33 RealBadAngel about camera i do have patch for it almost rdy, whats left is to set proper matrices for rendering clouds 02:34 RealBadAngel so far plane for clouds can be different as for the world 02:34 paramat ok 02:34 RealBadAngel but nametags have nothing to do with far plane 02:35 RealBadAngel atm im figthing with mysterious lags in meshgen, so leaves are slowing it down 02:35 RealBadAngel thats a current priority 02:36 RealBadAngel that has nothing to do with type of vertices used only the total number of them 02:37 paramat now we have such huge forests maybe opaque leaves should be default 02:37 RealBadAngel it was working before 02:37 RealBadAngel so it has to be fixed 02:37 paramat yes 02:38 RealBadAngel glasslike leaves on the other hand are not slowing down meshgen too 02:38 RealBadAngel because glasslike do eliminate shitload of adjacent faces 02:39 RealBadAngel we are hitting some limit there 02:41 RealBadAngel huh i think i got the reason 02:41 RealBadAngel lemme check it for a few times at least 02:42 RealBadAngel just ONCE more.... 02:43 RealBadAngel ok 02:43 RealBadAngel who the fuck said that using reserve will be WAY FASTER? 02:44 RealBadAngel paramat, can you check something for me? 02:46 RealBadAngel kahrl, here? 02:47 RealBadAngel sofar? 02:48 RealBadAngel anyway, making a PR with lags fix 02:51 paramat maybe 02:52 RealBadAngel #3717 02:52 ShadowBot https://github.com/minetest/minetest/issues/3717 -- Mapblock mesh: Eliminate meshgen lags by RealBadAngel 02:53 RealBadAngel please make two builds, one with 3717 and second upstream 02:53 RealBadAngel find a place with shitload of trees, enable minimap and see how fast new blocks are appearing 02:54 paramat btw yes i can be release manager if no one else is desperate to do that, i guess i have a feel for the state of MTGame. although i have no technical knowledge of what needs to be done 02:54 RealBadAngel managers usually have no technical knowledge lol 02:57 RealBadAngel paramat, so, can you test it? 02:59 paramat maybe, later 03:09 paramat RBA would 1 month be enough time for you to get your work into a good state for a release? 03:10 RealBadAngel if there wont be any more suprises like 3717 i think i will need week or two to get renderer and related issues cleaned 03:10 RealBadAngel theres not much left, nametags, sky, clouds 03:11 RealBadAngel and the camera ofc 03:11 RealBadAngel with that done i will be ready for further work on deffered rendering 03:12 RealBadAngel and thats a plan for another release 03:12 RealBadAngel definitely not something that could go in any soon 03:13 paramat ok 03:13 RealBadAngel i do have shitload of time for coding lately, so those two weeks are far more than enough i think 03:14 RealBadAngel you propably have noticed my commits rate lately ;) 03:24 sofar https://github.com/minetest/minetest/issues/2687#issuecomment-184497220 03:27 paramat thanks 03:28 RealBadAngel sofar, ive darkened it on purpose, it was barely visible on very bright nodes like snow for example 03:50 RealBadAngel btw, i have put timers on mapblock mesh creation to get whole time taken 03:50 RealBadAngel i keep getting very strange results 03:50 RealBadAngel http://pastebin.com/EWkdpzFr 03:51 RealBadAngel theres only single mapblock with meshes loaded atm 04:08 RealBadAngel hmmmm, here? 04:13 sofar RealBadAngel: how do you get time? 04:14 RealBadAngel changed it a bit now: 04:14 RealBadAngel u32 start = porting::getTimeNs(); and u32 end = porting::getTimeNs(); dstream<<(float)(end-start)/100000.0< halo on door 05:02 sofar RealBadAngel: when the door is open, point at the top half of the door -> halo on node behind door 05:02 sofar closed door is fine 05:02 hmmmm i don't know why reserve() would make things this much slower 05:02 sofar but it makes closing doors ... twice as hard 05:02 RealBadAngel sofar, why door has two selection boxes? 05:02 hmmmm in theory it should just be a vector capacity check that the majority of the time it bails out on 05:03 hmmmm and in the 1% of the time it'd actually allocate memory 05:03 RealBadAngel it shall have single one on bottom only 05:03 hmmmm but here, it seems like it's always allocating more memory 05:03 sofar RealBadAngel: it doesn't have 2 selection boxes 05:03 sofar RealBadAngel: this is the new mesh door, remember? 05:03 hmmmm is this because the premeshbuffer vector sizes are always really low, like ranging from 2-32? 05:03 RealBadAngel sofar, how can i test them? 05:03 sofar it's all merged in minetest_game 05:04 hmmmm hmm 05:04 RealBadAngel sofar, will test it in half an hour, ok? 05:04 sofar oh, no rush 05:04 hmmmm in the meantime, this is a bad enough regression (and enough people can verify that it is the case) to warrant the PR 05:04 sofar RealBadAngel: I can get some parts of the top half to make the halo correctly (namely the side of the door) 05:04 hmmmm I approve of #3717 05:04 ShadowBot https://github.com/minetest/minetest/issues/3717 -- Mapblock mesh: Eliminate meshgen lags by RealBadAngel 05:04 RealBadAngel hmm ok 05:05 sofar RealBadAngel: also, halo isn't updated when doors are opened/closed 05:06 RealBadAngel hmmmm, what would you say to make another two copies of append with prebuilt conditions? to regain those 150ns 05:06 RealBadAngel imho thats a valid reason 05:07 RealBadAngel i know thats not elegant but will be effective 05:07 hmmmm the thing making append slower is not the additional check, it's because a PreMeshBuffer has another std::vector in it now 05:08 RealBadAngel hmmmm, could you check timings with removing ifs? and extra vector here 05:08 RealBadAngel you can modify only first append without shaders 05:09 hmmmm RBA, to use TimeTaker, do this: 05:09 RealBadAngel if time gained will be insignificant then nvm 05:09 hmmmm TimeTaker t("foobar", NULL, PRECISION_NANO); 05:09 hmmmm and then at the bottom of the function 05:09 hmmmm printf("append: %uns\n", t.stop()); 05:10 RealBadAngel ok, gonna try it now 05:12 RealBadAngel hmmmm, http://pastie.org/10723528 05:13 RealBadAngel whats that in the middle? any idea? 05:13 hmmmm it could've hit a memory reallocation 05:13 hmmmm or maybe a context switch happened 05:13 RealBadAngel sometimes it got even worse 05:13 hmmmm right, that's to be expected 05:13 hmmmm anyway you should read this http://www.tantalon.com/pete/files/gdc04_common_cpp_mistakes_in_games.ppt 05:16 RealBadAngel wow, that 1800 was nothing 05:16 RealBadAngel append: 12839ns 05:18 RealBadAngel anyway, in general, without conditions and premesh buffer still having two std::vectors, 100ns is gained back 05:18 RealBadAngel can i code separate appends? 05:18 RealBadAngel :) 05:19 hmmmm eh 05:19 hmmmm no 05:20 RealBadAngel http://pastie.org/10723533 05:20 RealBadAngel see now 05:20 sofar RealBadAngel: interesting fact about the door halo issue: when the player is lower, problem goes away. 05:20 hmmmm instead of worrying about the performance of a specific function, look at what's taking up the majority of the time relative to the whole frame 05:20 hmmmm yea relative to what... 05:20 hmmmm also nanoseconds are pretty small units of time 05:21 RealBadAngel http://pastie.org/10723528 vs http://pastie.org/10723533 05:21 sofar doesn't reserve() potentially kick off gc? 05:21 hmmmm i just used ns to see the difference 05:21 hmmmm there is no gc in c++.. 05:21 RealBadAngel hmmmm, taking into account that append is called bazillion of times per each mapblock mesh we are talking bout not ns here anymore 05:22 hmmmm instead of saying "a bazillion" it'd be a bit more reassuring if you actually calculated the average number of times it's called per mesh 05:22 RealBadAngel lemme calculated one case 05:22 hmmmm also, keep in mind, we're calculating this in debug mode 05:23 RealBadAngel sure but: 16*16*16 nodes * 1 cuboid = 6 appends * 100ns = 2457600ns 05:24 RealBadAngel extreme one but valid 05:24 hmmmm that's literally the worst case scenario 05:24 hmmmm how about the average 05:24 RealBadAngel yeah 05:24 RealBadAngel but we are talking now but massively used cuboids 05:25 RealBadAngel snow nodeboxes slowing down scenes sounds familiar? :) 05:26 RealBadAngel sometimes i got a feeling i would like to kill paramat for that snow all around ;) 05:27 RealBadAngel if we assume snow is covering whole top of a mapblock, thats 15,36 ms 05:29 RealBadAngel and that you can see in real mapgen 05:31 RealBadAngel sofar, ok, lets see those doors now 05:32 sofar so just place a wooden door in a door frame 05:32 sofar open the door 05:32 sofar and point at the top half 05:33 sofar http://i.imgur.com/Tk7vquI.png 05:33 sofar notice crosshair location 05:36 RealBadAngel yeah, can see that ingame 05:38 sofar now, try this 05:38 sofar dig a hold under your feet so you drop 1 node 05:38 sofar now try from the lower angle 05:39 RealBadAngel ok 05:40 RealBadAngel ok, i think i know the reason 05:40 RealBadAngel will try to fix it 05:40 sofar kewl, I was hoping it would be fixable 05:43 RealBadAngel its about shootline used 05:44 RealBadAngel im reading now code on how to fix it 05:45 paramat yes snow nodeboxes on pines really hit my fps, i did remove snow nodeboxes from tundra recently though 05:49 RealBadAngel paramat, one thing is fps here and another mesh generation time 05:49 sofar man, I didn't realize how hard making a bed was in minetest_game. 05:51 RealBadAngel sofar, the code responisble to get selection_boxes in sight is here: https://github.com/minetest/minetest/blob/master/src/game.cpp#L334 05:51 RealBadAngel sofar, so i believe you have the very same problem with regular boxes, not only halo 05:51 paramat ok 05:51 sofar I didn't see it until today when I switched to halo 05:52 RealBadAngel exactly 05:52 RealBadAngel you have discovered an old bug 05:52 sofar yup, it's indeed there without halo as well 05:55 RealBadAngel so, nodes shall be checked not in line, rather in cone 05:55 RealBadAngel the code i linked would have to be reworked then 05:56 RealBadAngel well, not 05:56 RealBadAngel not a cone 05:56 RealBadAngel that would pop up everything in range 05:56 RealBadAngel damn meshes ;) 05:56 sofar you luv meshes 05:58 RealBadAngel lets see: if we get nodes in cone 05:58 RealBadAngel then first box hit would be a correct one, yes? 05:58 sofar yes 05:59 RealBadAngel well, shitload of math is going to happen ;) 06:09 kahrl thinking about it, it is really obvious that with the reserve()s it should be slow 06:10 kahrl with the reserve(), each time you add 24 vertices you have to reallocate the vector 06:10 kahrl or however many vertices you add each call 06:10 kahrl this takes time quadratic in the total number of vertices 06:11 hmmmm reserve() doesn't necessarily allocate memory 06:11 hmmmm only if the requested size is greater than the current capacity 06:11 kahrl hmmmm: yeah, but doesn't reverse set the new capacity to what you requested? 06:11 kahrl reserve* 06:11 hmmmm you might be thinking of resize() 06:11 kahrl no 06:12 hmmmm oh i misread that 06:12 kahrl I don't think reserve rounds up the capacity to the next power of two or something like that 06:12 hmmmm this is an incredibly stdlib dependent detail 06:12 kahrl right 06:12 hmmmm lemme check clang libc++ 06:13 kahrl well, without the reserve, I'm quite confident that it'll take about linear time (due to amortization) 06:15 hmmmm http://fpaste.org/323334/56033271/ 06:17 kahrl what does the constructor of __split_buffer do? 06:17 hmmmm just assigns variables 06:18 kahrl ah 06:18 kahrl and __swap_out_circular_buffer? 06:18 hmmmm http://fpaste.org/323335/55603529/ 06:19 kahrl I see 06:19 kahrl so it seems like __n is indeed the new capacity 06:20 kahrl this is the g++ one: https://gist.github.com/kahrl/5ffce9f8c1f975f07d78 06:21 kahrl this->_M_impl._M_end_of_storage = this->_M_impl._M_start + __n; 06:21 kahrl that implies to me that is also uses __n as the new capacity 06:21 hmmmm yea 06:22 hmmmm looking for __alloc_traits right now to see if that's the case with clang 06:27 hmmmm oh 06:27 hmmmm come to think of it, this reserve() thing is exactly why irrlicht's mesh buffer append() is so slow 06:28 hmmmm iirc it makes the same mistake here, except on a per-vertex basis 06:43 paramat so kahrl do you approve of 3717? if so i'll merge it soon 06:44 RealBadAngel hmmmm, kahrl, could you agree/disagree on moving nametags to HUD please? #3712 06:44 ShadowBot https://github.com/minetest/minetest/issues/3712 -- Move object nametags to HUD by RealBadAngel 06:47 RealBadAngel also do note that moving it out of world geometry also fixes old weird bugs and is needed at all, in question is atm where to go with them 06:57 kahrl paramat: I do 06:58 paramat ok 07:01 paramat Gael de Sailly visualised the voronoi diagram of our biome system http://i.imgur.com/fFCkzWX.png 07:03 sofar I find stone grassland boring and unlike the name it suggests 07:04 sofar maybe tune it to humidity 30 so the angles tone it down a bit further? 07:04 sofar sandstone grassland isn't much better, though 07:05 sofar I don't like the two '+' crossings at the center, whenever I encounter them it looks really odd in the landscape 07:05 sofar (but, the graph is nice, lol) 07:10 paramat it's cetainly a nightmare, i'll consider tweaks 07:13 sofar http://www.raymondhill.net/voronoi/rhill-voronoi.html may help 07:16 sofar maybe putting 2 biomes right at those intersections that are transitional helps, but that does change the look and feel a lot :) 07:17 paramat thanks. the system is a stretched version of https://upload.wikimedia.org/wikipedia/en/2/29/PrecipitationTempBiomes.jpg 07:18 sofar ah, I didn't know, that's really neat 07:18 paramat stretched/reshaped into a square 07:18 sofar indeed there's +'s in there as well (expected, of course) 07:19 sofar yes, you have to drape it somehow to fit the square somewhat nicely, otherwise you end up with 80% of the same biome 07:20 paramat i researched world major biomes. grasslands could perhaps be smaller, since there are 2 of those biomes. the whole thing has been very difficult to tune 07:21 sofar the original triangular shape is not beneficial 07:22 sofar I'd focus on tryng to get relationships somewhat correct, then map for roughly equal surface area 07:22 sofar it doesn't look like you did a bad job, actually 07:23 paramat yes exactly what i did, also looked at many other diagrams of this type to get a general feel 07:31 RealBadAngel sofar, atm i have no idea how to fix your issue, can you make a ticket with it? 07:31 sofar lol sure 07:32 RealBadAngel i may find a solution later on, right now i would like to finish stuff with camera 07:37 sofar bombs away 07:41 sofar alright, I'm going to bed. I'll read all the hater replies tomorrow :) 08:21 paramat now merging #3717 08:21 ShadowBot https://github.com/minetest/minetest/issues/3717 -- Mapblock mesh: Eliminate meshgen lags by RealBadAngel 08:29 paramat merged 08:32 RealBadAngel thx 11:29 RealBadAngel oke doke, i have clouds working ok with shortened view range :) 11:45 est31 what the hell 11:45 est31 I've thought adding the reserves is a speedup 11:45 est31 I mean, its sort of implicit that push_back itself calls reserve itself as well 11:46 est31 or something equivalent 11:46 RealBadAngel apparently not 11:47 RealBadAngel hmmm was digging the issue further, read logs 11:47 est31 yeah apparently not 11:48 est31 I do agree with you that its faster now 11:48 RealBadAngel we were using our own append because irrlicht one was slow, now you know why it was slow 11:48 RealBadAngel they made the very same mistake 11:49 RealBadAngel we still have circa 100ns per each append to regain, but that would require two another copies of append, hmmm is not quite happy with that ;) 11:50 RealBadAngel but on the other hand that 100ns per append is about 15ms per mablock with snow nodeboxes on the surface 11:51 RealBadAngel which is quite typical situation in cold biomes 11:52 RealBadAngel not to mention spawns on some servers.. 11:54 est31 well, it seems vector.reserve is a pretty dumb function 11:55 est31 or, it doesn't do what I expected it to do 11:55 RealBadAngel rather the second 11:56 RealBadAngel well, at least bug is killed relatively fast 11:56 est31 thats something 11:56 est31 but I'm still thinking whether I need to use that function at all 11:56 est31 for me it became useless, simple as that 11:57 RealBadAngel hmmm was talkin it can be stdlib dependent, its version 11:57 RealBadAngel but certainly we cannot rely on it anymore 11:58 est31 yeah it can be 11:58 est31 but both clang and gcc have the same implementation 11:58 est31 which causes slowdown 11:58 est31 reserve is only useful if you want to conserve memory 11:58 est31 maaan 11:58 RealBadAngel now at HEAD, MeshCollector::append is taking up ~230000 nanoseconds per execution 11:59 RealBadAngel usual time is about 250ns 11:59 RealBadAngel at least now ;) 11:59 RealBadAngel pretty nice difference lol 12:00 RealBadAngel propably it can still be useful, but once per run or something like that 12:00 est31 yeah, I confirm, the issue if fixed for me 12:01 est31 yeah that's the only place its useful 12:01 est31 loop over the whole mapblock once to get the mesh size 12:01 est31 then loop again to generate the mesh 12:01 est31 and then waste your time with walking two times over the same array 12:02 est31 if the mapblock is large enough it doesnt fit into L1 cache lol 12:02 est31 then its mega slow 12:02 RealBadAngel on the other hand you can reserve max capacity 12:02 RealBadAngel that actually could make sense 12:02 est31 The only real use for reserve is if you know the exact maximum size your buffer will ever have 12:03 RealBadAngel 65k 12:03 RealBadAngel we do often cross that and making another buffer 12:03 RealBadAngel especially with those damn leaves :) 12:04 RealBadAngel that could be measured if tradeof is worth it 12:09 RealBadAngel most of the blocks will fit in the single buffer 12:09 RealBadAngel some with heavy forests would have 2 12:11 est31 well seems I've learned something today. 12:12 RealBadAngel hallelujah! 12:12 RealBadAngel :) 12:12 est31 and, I've made that same mistake on another PR as well 12:12 RealBadAngel which one? 12:12 * est31 heading over to #3503 12:12 ShadowBot https://github.com/minetest/minetest/issues/3503 -- Nodebox: Allow nodeboxes to "connect" by sofar 12:13 celeron55_ est31: getting the mesh size isn't a matter of just looping over a mapblock; you have to look up stuff from the node definitions while doing that and they may not fit into any cache whatsoever 12:13 est31 yup 12:14 RealBadAngel ooops 12:14 RealBadAngel (talking bout 3503) 12:16 kahrl reserve usage in #3503 looks fine to me 12:16 ShadowBot https://github.com/minetest/minetest/issues/3503 -- Nodebox: Allow nodeboxes to "connect" by sofar 12:17 kahrl calling reserve once per vector is good; the problem arises when you keep calling reserve on the same vector in a tight loop 12:18 RealBadAngel kahrl, if you have shitload of fences using it then you willl have there quite a nice delay 12:19 celeron55_ calling it once before filling the vector with actual stuff is literally the only way it is meant to be used 12:20 RealBadAngel well, but thats not in mapblock mesh 12:21 est31 yeah the only real usecase for reserve is if you know the final size for the vector 12:21 celeron55_ generally i'd suggest calling it once with a good guess to get fast performance with common sizes and then, if there's too many, let the vector do its power of two allocations to fit the rest 12:21 est31 or a "close" upper bound 12:22 est31 its ideal for deserialisation, where you first send the size of an array then the array elements one by one 12:49 RealBadAngel est31, wanna test #3720? 12:50 ShadowBot https://github.com/minetest/minetest/issues/3720 -- Use real camera clipping and single view_range setting by RealBadAngel 12:50 est31 first tell me what it indends to do :) 12:50 RealBadAngel gain some speed 12:50 est31 ah that thing 12:51 est31 well it has to be documented 12:51 est31 thats one thing 12:51 RealBadAngel and cut the crap with view distance 12:51 est31 cant we wait until farmap for this 12:51 RealBadAngel ofc, that have to be tested 12:51 est31 dont want to step on c55's toes 12:51 RealBadAngel for a few lines of code? 12:52 RealBadAngel celeron55_, what do you think bout this PR? 12:53 RealBadAngel est31, ive made a PR with it for folks to test it first 12:54 RealBadAngel imho it can give real nice speedup on slower machines 12:54 est31 yeah my comments arent really "final" 12:55 RealBadAngel i can feel the game way smoother with this, just give it a try 12:55 est31 RealBadAngel, what do you compare it withß 12:55 est31 ? 12:55 est31 with a minetest where min_range == max_range 12:56 est31 or with a minetest where the ranges differ 12:56 est31 its only a real improvement if it also improves upon min_range == max_range 12:56 RealBadAngel theres single range setting 12:56 est31 i can feel the game way smoother with this 12:56 RealBadAngel theres no max, or auto tuning 12:57 est31 compared to what? 12:57 est31 you didnt get my question 12:57 RealBadAngel just play a bit on selected distance used 12:57 est31 what were your settings before 12:57 RealBadAngel i usually play at 40 12:57 RealBadAngel 240 12:58 RealBadAngel depends on how many leaves are around 12:58 RealBadAngel also check how range affects fps 12:59 RealBadAngel you can easily find best (read steady 60fps) now 13:00 est31 well everybody who likes to tune themselves will like it 13:00 est31 everybody who likes the machine to tune it for them wont like it 13:00 est31 I am neutral on the PR and plan to stay that way 13:00 est31 find devs who approve of it and it can go it 13:00 est31 in* 13:00 RealBadAngel theres speedup measured 13:00 est31 I neither +1 nor -1 it 13:00 RealBadAngel about 10% 13:01 RealBadAngel ask fixer for charts 13:01 RealBadAngel and it does FEEL smother, just give it a chance and play with it :) 13:02 est31 I am neutral and stay neutral 13:02 RealBadAngel you dont care bout +10% FPS? :) 13:02 est31 i have to test that first 13:02 RealBadAngel thats what im asking youo 13:03 est31 last time somebody tested something for one of your patches we had -25% decrease 13:04 RealBadAngel it was long time ago and is fixed 13:04 RealBadAngel together with many other old issues ;) 13:04 est31 I dont believe benchmarks I didnt fake myself :) 13:05 est31 and rendering is broken by the PR 13:08 RealBadAngel whats wrong? 13:08 est31 stuff drawn before other stuff 13:08 est31 e.g. on farms you see water even if its below the soil 13:08 RealBadAngel its not polished yet, i may missed something 13:08 est31 or doors if you look at the roof 13:09 RealBadAngel ive forgot to restore projection matrix, thats propably why 13:09 RealBadAngel anything else? 13:09 est31 I cant confirm an FPS speedup 13:09 est31 sorry, no speedup 13:10 RealBadAngel have you comapared scenes with the same distance? 13:10 est31 yes 13:11 RealBadAngel i think it will be more visible on slower boxes 13:12 RealBadAngel let some folks test is, we will see 13:12 est31 yeah those which have a viewing range of 2 13:12 est31 and still 10 FPS 13:12 est31 well I'm gone 14:52 est31 do we need anything to make it official that paramat is the release manager for the next release? 14:53 est31 ^ kahrl, nore nrzkt sfan5 ShadowNinja celeron55_ ? Do you agree to paramat being release manager for the upcoming release? 15:17 celeron55_ est31: sounds fine to me altough i have no idea what this is actually about 15:18 est31 We didn't have a release since aug 20, and some people want a release 15:18 est31 almost a half year ago 15:23 Fixer why so fast, maybe more fixes? like stutter ones? $%) 15:23 Fixer after fixing stutters that will be perfect release 15:23 est31 discuss that with paramat please 15:24 est31 I hate release discussions precisely because of this 15:24 est31 everybody demanding their pet bug is blocker 15:24 est31 (Nothing against you personally Fixer) 15:24 nrzkt i vote for marking est31 as a blocker 15:24 Fixer haha, yeah :} 15:25 Fixer stutter is my pet bug 15:25 Fixer this is true 15:25 Fixer i love it since 0.3.*, we were close friends since 15:26 est31 lol nrzkt 15:27 sofar I'd like to promote est31 as critical 15:28 est31 releasing 0.4.13 wasnt fun for me 15:28 Fixer but don't release now, i will test some RBA performance PRs 15:29 est31 well it was fun once 0.4.13 was out 15:33 RealBadAngel ive found some old bugs, pretty nice excuse for a release 15:33 RealBadAngel maybe i will locate the stuttering too 15:34 RealBadAngel those ive found were already damn hard to find, so it cannot be any worse lol 15:35 est31 perhaps you can try to fix Fixer's stuttering issues 15:35 Fixer it is only my issue? other people have it too 15:36 Fixer or maybe their hardware is slow as snail and they don't notice stutter at 20 fps 15:37 RealBadAngel est31, it happened to me once, imho it is depending on sand storm on mars, but fixer claims it is phase of the moon responsible 15:37 est31 lol 15:37 Fixer it happens to me every time i play the game, when meshes are generated 15:38 Fixer but horrible ones indeed happen 15:38 est31 meshes arent generated on the main thread 15:38 est31 only thing that happens on main thread is mesh upload to the gfx card 15:39 Fixer whatever, drawtime spikes follow mesh generated spikes on F5 graph 15:39 RealBadAngel est31, but theres visible on graphs that you dont have mesh updates for quite a while, then bang packets of 20-30 at once 15:40 Fixer usual example: https://imgur.com/8Zz4woj 15:42 est31 Fixer, anything you can do to reproduce it 15:43 Fixer ? connect to just-test server or other server with people ? 15:43 Fixer or start singleplayer 15:43 Fixer it is not like you need to look for it, bug starts with the game :} 15:43 est31 you get it both in multiplayer and singleplayer then? 15:44 Fixer yes 15:44 est31 okay, minimal development test, do you get it in that subgame? 15:44 Fixer i can try it, sure 15:45 Fixer some noticable stutter was present on MTG even with flatgen mod 15:47 Fixer est31, even in minimal 15:47 Fixer mapgen 6 15:48 est31 next step would be to find out what takes so long 15:48 est31 Fixer, how large is the drawtime for a stuttering frame? 15:48 est31 usually 15:48 Fixer est31, in usual games? 15:48 est31 no when you stutter 15:49 est31 how large is the drawtime 15:49 est31 is it stutter of 5 seconds 15:49 est31 or of a half second 15:49 est31 or is it just well FPS going from 60 to 59 and back 15:49 RealBadAngel est31, for me it was choking even when going forward, so movement was disturbed 15:49 Fixer est31, some my earlier examples: http://i.imgur.com/OqnXqMs.png or http://i.imgur.com/6qItSmR.png or http://i.imgur.com/CRolH4Z.png or http://i.imgur.com/zGZiPzi.png or http://i.imgur.com/F4jOrj3.png or http://i.imgur.com/kipFEms.png 15:50 Fixer est31, LOL 15:50 Fixer est31, it is smth like 140 to 70 and back to 140 15:50 Fixer est31, and this is from 0.3.* era - http://i.imgur.com/5c071LR.png 15:51 Fixer on different machine 15:52 RealBadAngel fixer, does the camera PR have any impact on the issue? 15:52 Fixer RealBadAngel, let me see 15:52 RealBadAngel it could be auto tuning involved 15:53 Fixer est31, flat mapgen in minimal dev test 0.009 to 0.02 and back 15:53 est31 Fixer, so whats the difference between 0.4.13 and 0.3.* era?? 15:53 Fixer est31, it is stuttering anyway 15:53 Fixer lol 15:53 Fixer just now 0.09 15:53 Fixer from 0.01 to 0.09 on flat mapgen 15:54 Fixer let me record new gif 15:54 Fixer on flat gen 15:54 est31 Fixer, of the diagrams you listed which one would you see as "ok" 15:55 est31 and which one is "stuttering" for you 15:56 Fixer est31, everything, all that spikes are stutters and can be detected by eyes 15:56 est31 Fixer, can you record minetest from 0.3.* era which you say doesnt have the stuttering 15:57 Fixer est31, i think 0.2 probably don't have, but that was different PC 15:57 est31 try it on the same PC 15:57 est31 I want to find out whether its really a regression 15:57 Fixer est31, i've started to notice it somewhere in 2012 15:58 est31 or whether its a bug inherent to minetest or stuff 15:58 RealBadAngel est31, ive experienced that bug last week 15:58 est31 Fixer, you know how to compile minetest? 15:59 RealBadAngel was "working" for half an hour then was mysteriously gone 15:59 Fixer est31, i have celeron55-minetest-0.3.dev-20111021-0-gc349708 15:59 Fixer no need to compile 15:59 Fixer oh wait 15:59 Fixer minetest-0.3.1-win32.zip is good enough 15:59 Fixer this is binary 16:00 Fixer i'm uploading new gif from minidevtest + flat mapgen 16:03 Fixer est31, https://imgur.com/mg7UypX 16:03 Fixer it is latest git one 16:03 Fixer i will try to run 0.3.1 16:09 Fixer 0.3.1 feels so different 16:09 Fixer average fps is 230, lets see the spikes 16:10 Fixer i feeled some stuttering but it was not comparable 16:12 RealBadAngel Fixer, have you checked the PR? 16:13 Fixer RealBadAngel, compiled but not yet checked 16:13 Fixer est31, behold -> https://i.imgur.com/19RI6vy.png 16:13 RealBadAngel im pretty curious if it can help, auto tune code is about that old as you mentioned you remember stuttering started 16:13 Fixer 0.3.1 has stutters 16:14 Fixer RealBadAngel, let me see it now 16:15 Fixer est31, note that average fps was 230 that is near ~5 ms %) 16:15 est31 yeah, 0.3.1 did something right 16:15 est31 what 0.4.13 didnt 16:15 RealBadAngel Fixer, note that we do have lotsa more to do and to display 16:16 est31 perhaps you'll have to turn on fps limiting 16:18 Fixer RealBadAngel, does not fix stuttering, will test performance little later 16:18 RealBadAngel ok 16:19 Fixer est31, will try with it, but with so much performance boost some stuttering could be masked by fps cap 16:26 RealBadAngel est31, btw, since new release is going to happen, maybe this could be merged too? #3616 it needs protocol bump and it was recently bumped 16:26 ShadowBot https://github.com/minetest/minetest/issues/3616 -- Allow to set shader for a node, add special and normal texture defs f… by RealBadAngel 16:26 RealBadAngel we could get rid of hardcoded water surface node and remove duplicate water shader (nodes shader only will do) 16:27 est31 I sort of like it, sort of don't like it 16:27 est31 so I'm neutral 16:27 est31 here too 16:27 RealBadAngel what you dont like here? 16:28 est31 we already had this 16:28 Fixer RealBadAngel, 3166? 16:28 Fixer est31, with fps cap, also added fixed view range in config https://i.imgur.com/q1F3Uyt.png 16:28 RealBadAngel est31, once with forcing filtering. ive removed that 16:28 est31 RealBadAngel, that was the critic point by blockmen not by me 16:28 est31 if you let the server upload the shaders then its a security problem 16:29 RealBadAngel Fixer, yeah i remember about it, a must to be completed asap 16:29 Fixer est31, so still stuttering with fps cap, config here http://pastebin.com/raw/fvHu0BUA 16:29 Fixer RealBadAngel, people were hoping for it in 0.4.14 16:29 RealBadAngel est31, this does not allow sending shaders at all 16:29 est31 if you let the client provide the shaders then its against the minetest principle that the server provides all data 16:29 est31 e.g. you dont have to install anything client side 16:30 RealBadAngel it just lets you in the future to set another shader than default one 16:30 est31 I know what it does 16:30 est31 the game creator can change the shader name 16:30 RealBadAngel for example all the liquids would need another (with reflections for example) 16:31 RealBadAngel this let it define the shader to use without hardcoding node names in the engine 16:31 est31 sorry RBA you wont convince me to +1 it 16:31 est31 I dont want to stall it so I dont -1 it 16:31 RealBadAngel ok, got it 16:31 est31 find others who +1 16:33 RealBadAngel est31, btw one can already freely modify client shaders, not a big deal. just edit files on client side 16:33 sfan5 est31: what is this "release manager" thing 16:33 sfan5 we didn't need one before 16:34 RealBadAngel sfan5, one who will kick your ass for the job not being done? ;) 16:34 sfan5 well my job is pretty easy 16:35 est31 sfan5, release manager coordinates release 16:35 est31 but I dont really know either what they do 16:36 sfan5 in any case 16:36 sfan5 i'm ok with paramat doing it 16:53 RealBadAngel about #3712, can i have more opinions on where nametags should go? 16:53 ShadowBot https://github.com/minetest/minetest/issues/3712 -- Move object nametags to HUD by RealBadAngel 17:33 sofar RealBadAngel: I would, but I don't think you'll like my opinion 17:34 RealBadAngel sofar, go on 17:35 sofar I'd argue that nametags should be like in-world particles, hide behind a corner and you shouldn't be able to see them 17:35 sofar makes for better pvp as well 17:37 RealBadAngel text cannot be world objects because of shading, depth and number of postprocessing effects 17:38 sofar right, and I think that should be addressed 17:38 sofar I don't want it to behave like text. I want it to be a texture that moves with the player in the world 17:38 RealBadAngel imagine bloom, cell on text for example 17:38 sofar in the same way I'd want speech bubbles 17:38 RealBadAngel be it texture or whatever 17:39 sofar maybe even other graphical elements 17:39 sofar player markings, trophies, pixie dust, saussages, that kind of stuff 17:39 RealBadAngel do it with texture, any other gfx element, conclusion is still the same 17:40 RealBadAngel they cannot be here until whole scene is rendered to its final state 17:40 sofar yup, so what if text is cell-shaded? 17:40 sofar bloom should be ok 17:40 sofar dof should be fine, make it fuzzy, idc 17:40 RealBadAngel it looks like pure shit 17:41 RealBadAngel totally unreadable 17:41 sofar people choose shit like cell shading :) 17:41 RealBadAngel not to mention they dont have depth 17:41 sofar they should have depth 17:41 RealBadAngel they dont have 17:41 sofar they should have 17:41 RealBadAngel but they dont 17:41 sofar but they should 17:41 sofar :) 17:41 RealBadAngel also, irrlicht method is broken 17:42 RealBadAngel text are source of serious bugs, very old ones 17:42 sofar I don't think the current method is good anyway 17:43 sofar I'd rather have a pixel-y font that's e.g. 6x9px and monospaced 17:43 sofar and rendered to a neat texture 17:43 Calinou please no pixelated fonts, those are a pain to read and internationalize 17:43 Calinou bitmap fonts are something I'd expect in 2002 games 17:43 Calinou not in 2016 games 17:44 RealBadAngel sofar, hud like things belong to hud (or camera or whatever the place will be) 17:44 sofar ... and there's the i18n warrior ;) 17:44 RealBadAngel but hands off the renderer 17:44 sofar Calinou: how about, optional fonts can be chosen at any resolution? 17:44 Calinou it's already possible to change your font 17:44 RealBadAngel you want DOF to loose focus on pointing the text? :) 17:45 sofar and I want a pixely font but I can't 17:45 RealBadAngel you can, use custom ttf 17:45 sofar since if I choose an 8px font it looks like this: ....___... 17:45 sofar too small 17:45 RealBadAngel there are many fonts that fake 8bit ones 17:45 sofar RealBadAngel: yes, I want DoF to fuzz the text 17:45 Calinou 8px is unreadable on most screens 17:46 Calinou you may be one of those people with perfect eyes, but it's far from everyone 17:46 sofar it's more about the style 17:46 RealBadAngel sofar, its reverse, text breaks the DOF effect 17:46 RealBadAngel same as clouds, sky 17:46 RealBadAngel halo no more 17:46 RealBadAngel even selection boxes were breaking it before 17:46 sofar Calinou: exactly! I can't use 8px fonts like I said! it's too small! I said that! 17:47 sofar RealBadAngel: current text does, but what about text rendered like e.g. signslib does? 17:48 RealBadAngel patch the irrlicht to get it working 17:48 sofar make a texture, put it on a surface? 17:48 RealBadAngel simple as that 17:48 sofar that's already working in signs_lib 17:48 RealBadAngel lol 17:48 RealBadAngel do you know how signs lib works? 17:48 sofar yes, I do :) 17:49 sofar it's atrocious 17:49 RealBadAngel its a disease 17:49 sofar agreed :) 17:49 sofar however, the concept of getting a surface in-world with a texture is what I'm after 17:49 sofar texture from text, that is 17:50 RealBadAngel sofar, then you will face another problem 17:50 RealBadAngel delete unused textures 17:50 RealBadAngel good luck with it :) 17:51 sofar exercise left to the reader 17:51 RealBadAngel fyi they all stay until shutdown 17:51 RealBadAngel now maybe will see better the size of that disease calleed signs libg 17:53 sofar signs_lib should be replaced by a careful reimplementation of NDT_SIGNLIKE that renders text in the client from nodemeta 17:53 sofar just like how I did the NDT_CONNECTED stuff 17:53 sofar totally fixable 17:54 sofar on my to-do list after itemstack item renaming 17:54 sofar :) 17:54 RealBadAngel a) you cant store safely stuff in meta 17:54 RealBadAngel b) you cant safely delete textures 17:55 RealBadAngel c) move shit in a chest and all your signs in all adjacent blocks will got deleted and reloaded from server 17:56 sofar well c) is an open issue 17:56 sofar a) I can live with 17:56 RealBadAngel yes, and its not an easy fix 17:56 sofar and I assume b) is an irrlicht bug 17:56 RealBadAngel no its not 17:57 sofar I've seen that PR 17:57 RealBadAngel you cant delete texture from any other thread than main 17:57 sofar so you're saying that the main thread should do texture gc? 17:57 RealBadAngel and you HAVE to be sure, that nothing is using it 17:57 sofar refcounting 17:58 RealBadAngel you can have mesh still being displayed somwhere 17:59 RealBadAngel sure, that all are things fixable, but not easy 17:59 sofar mark the mapblock for refcount removal, have mesh update add the texture to the removal list. 17:59 sofar something like that? 17:59 sofar agreed it'd be .. work 18:02 RealBadAngel and definitely not something that could replace current nametags code any soon 18:02 RealBadAngel do note that it doesnt change behaviour a bit, also it fixes urgent bugs 18:03 RealBadAngel also, if you want fancy gfx above player you can do that already with entities 18:04 RealBadAngel nah, the signs nightmare again ;) better not ;) 18:10 sofar entities can't rotate based on viewer perspective 18:11 RealBadAngel who told you that? 18:11 RealBadAngel items were flat once upon a time, players too 18:12 sofar sprites 18:12 sofar but they have their own rotation 18:12 RealBadAngel they always face you 18:12 sofar ah 18:12 sofar I didn't know that 18:13 sofar ima abuse the heck out of that, then 18:13 RealBadAngel hehehehe 18:14 sofar entity-based rain, here I come 18:14 RealBadAngel simple shader would be easier and nicer i think 18:15 sofar for rain? 18:15 RealBadAngel or particles 18:15 sofar weather effects should be client-side 18:16 sofar we just need to add a server environment "weather" and pass weather status changes to clients 18:16 RealBadAngel but some1 could finish jinxi's work first 18:16 sofar then let the clients handle the visuals 18:18 RealBadAngel https://www.youtube.com/watch?v=DmVRVHpZ428 18:18 RealBadAngel those are particles 18:26 sofar sure, like I said, client should render them 18:27 RealBadAngel irrlicht particles have proper collisions, so we could have nice rains 18:27 sofar yes, absolutely, that's what the client should render :) 18:28 RealBadAngel or fire: https://www.youtube.com/watch?v=LACUkG2GIno 18:28 RealBadAngel they can be used for many effects 18:29 RealBadAngel i would love to see fog done with it, over swamps for example 18:29 sofar yes, fog, rain, snow, lightning, even wind 18:30 sofar hail 18:42 sofar well that fire particle isn't the prettiest 18:50 RealBadAngel but shows that many things can be done with them 18:51 sofar and as long as it's not lua on the server making all those particles for each client... 18:51 nrzkt sofar, +1 18:52 sofar my list of "this could be a client-side lua thing" is slowly growing 18:52 sofar almost all sound effects can go there 18:53 sofar weather only really needs a server state and packet system. Server-lua can manage weather changes. Client-side lua can do localized transformations (e.g. warm biome - rain, cold biome - snow) 18:53 sofar fog in caves, smoke near lava 18:53 RealBadAngel particles are engine so client 18:53 RealBadAngel server just have to order makin them 18:54 sofar yes but the current weather implementations have the server send particle data to each client 18:54 sofar that needs to go 18:54 sofar the client itself should cough up appropriate particles 18:54 RealBadAngel we are not using irrlicht particles yet 18:54 sofar am I in a cold area? is weather telling me precipitation is happening? draw snow particles 18:55 sofar is it windy and I'm in a desert biome? draw sand storm dust 18:55 sofar we don't want the server to make a single particle 18:55 sofar just make client side ABM's 18:56 sofar or something similar 18:56 RealBadAngel check jinxi's code 18:56 RealBadAngel there should be PR open still 18:57 sofar #? 18:57 sofar I can't find a jinxi on github 19:00 sofar RealBadAngel: #2587 ? 19:00 ShadowBot https://github.com/minetest/minetest/issues/2587 -- wip irrlicht particles 2 by obneq 19:01 RealBadAngel yeah, i just found it too 19:09 RealBadAngel btw, why nobody is commenting Jeija's PR? #3713 19:09 ShadowBot https://github.com/minetest/minetest/issues/3713 -- Resend blocks when modified while sending to client by Jeija 20:20 Fixer RealBadAngel, 3720 is much slower on just test mp server standing test, without 3720 is 50fps, with - 30fps 20:29 Fixer RealBadAngel, hmm, looks like it is problem with view range settings actually 21:14 kaeza compiling Minetest with -Wall gives 0 warnings (from the actual MT sources anyway) 21:14 kaeza \o/ 21:14 kaeza still shitton warnings in 3rd party libs 21:15 kaeza gcc 4.8.1, FWIW 21:27 Fixer RealBadAngel, commented on PR 23:02 est31 pushing this little commit in 10 mins https://github.com/est31/minetest/commit/4c654557ecc32620b78c146bd6d90f531a71d25a 23:03 est31 (thanks to jeija he gave the original motivation) 23:09 * celeron55 adds to imaginative list of farmap conflicting things 23:13 nrzkt est31 if you get 5 mins => #3722 23:13 ShadowBot https://github.com/minetest/minetest/issues/3722 -- Avoid loadMedia copy and do some cleanups by nerzhul 23:14 est31 ah you completely rework it celeron55 ... should I still merge it then? probably you either fixed it yourself or removed it I guess 23:15 est31 nrzkt, https://github.com/minetest/minetest/pull/3722/files#diff-34f48ad91ac6c202ac60b0348ae90e30L693 23:15 est31 nrzkt, does that compile with irrlicht 1.7? 23:16 Fixer nice, disabling shaders increases fps by 80% 23:17 nrzkt est31, as it seems no :p i need to this the constness issue. Seems irrlicht 1.9 don't care 23:17 est31 nrzkt, minetest has to compile for irrlicht 1.7 23:17 est31 if it compiles on irrlicht 1.9 too thats good 23:17 est31 but it has to compile on both 1.8 and 1.7 23:19 nrzkt the last fix compiled with 1.8 whereas previous not as it seems, we will see, i add a void* cast to the c_str 23:21 celeron55 est31: at this point it does not really matter anymore 23:22 nrzkt est31 it seems good :) 1.8 has same problems has 1.7 and this is fixed :) 23:26 est31 I really should give that PR a look 23:26 est31 perhaps we can get it in before release 23:26 est31 its not as large as I think it is 23:27 est31 hrmm I can look at it at feb 26. 23:29 Fixer forum error 23:32 est31 is it "ready" as in "only requires a rebase and it can go in"? 23:37 Fixer ahhh, experienced that opaque halo thing