Minetest logo

IRC log for #minetest-dev, 2016-02-16

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:04 Megaf joined #minetest-dev
00:18 STHGOM joined #minetest-dev
01:33 Robby joined #minetest-dev
01:40 RealBadAngel joined #minetest-dev
02:10 STHGOM joined #minetest-dev
02:13 paramat joined #minetest-dev
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 STHGOM joined #minetest-dev
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 Lunatrius joined #minetest-dev
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:12 iamafriend200 joined #minetest-dev
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:02 hmmmm joined #minetest-dev
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();andu32 end = porting::getTimeNs(); dstream<<(float)(end-start)/100000.0<<std::endl;
04:15 RealBadAngel usual timings now are 6-7ms
04:15 sofar hmm yeah, then those numbers are weird
04:15 RealBadAngel but from time to time, they got doubled or tripled
04:15 sofar it's all over the place too
04:16 RealBadAngel http://pastie.org/10723486
04:16 RealBadAngel look now
04:18 RealBadAngel http://i.imgur.com/CmTIQg1.png
04:19 RealBadAngel thats just a single mapblock (with a few nodes) high in the sky
04:19 RealBadAngel lol just saw 97ms
04:20 RealBadAngel 16 times slower than usual time
04:25 hmmmm ?
04:27 RealBadAngel hmmmm, #3717
04:27 ShadowBot https://github.com/minetest/minetest/issues/3717 -- Mapblock mesh: Eliminate meshgen lags by RealBadAngel
04:27 RealBadAngel do you know why using reserve slows meshgen as hell?
04:28 RealBadAngel any ideas?
04:29 hmmmm the answer to that is highly dependent upon your stdlib
04:31 hmmmm those reserves were added by gregorycu and he profiled it and saw an improvement
04:31 RealBadAngel somebody else asked me to add those to my latest commit
04:31 hmmmm it logically makes sense that it would be faster, too
04:31 RealBadAngel and it introduced lags, not only for me, fixer, est31 for example too
04:32 RealBadAngel so, can it be that it is faster for some versions of stdlib and slower in other case, right?
04:33 hmmmm correct
04:34 RealBadAngel so, it is rather not wise to use reserve at all
04:35 hmmmm i don't think so
04:35 hmmmm your testing methodology might be faulty due to integer overflow
04:35 hmmmm you should be using TimeTaker with PRECISION_MICRO or PRECISION_NANO
04:35 RealBadAngel hold on, im testing now something different
04:36 RealBadAngel i was testing impact of reserve other way
04:36 RealBadAngel just compiled two builds, with the patch and without
04:36 RealBadAngel found a place with lotsa trees
04:37 RealBadAngel and was observing minimap and speed at which new blocks are appearing
04:37 hmmmm logically i don't see how the code could be slower with reserve()
04:37 RealBadAngel with reserve, time is like 4-5 times slower
04:37 hmmmm could you use the correct testing procedures and try again?
04:37 hmmmm also I'll try it
04:38 RealBadAngel get upstream and comment out just those reserves
04:38 RealBadAngel ive checked that for 20 times at least
04:39 RealBadAngel commenting out - compile, run, back, compile run and again
04:39 RealBadAngel so same world, and everything
04:45 RealBadAngel hmmmm, how do i enable time takers? uncomment that and then what? https://github.com/minetest/minetest/b​lob/master/src/mapblock_mesh.cpp#L1047
04:45 hmmmm jeez i dunno rba
04:45 hmmmm doesn't seem like MeshCollector::append() is really that slow to begin with
04:46 hmmmm I am testing the function at baa7c8f before any modifications and it's taking up either 0 or 1 microseconds
04:46 hmmmm rarely, it'll take a bit longer
04:47 hmmmm it seems like the median baseline is ~500 nanoseconds
04:47 RealBadAngel nvm then, seeing blocks appearing ratio a few times slower is accurate enough to judge the reserve is slower
04:48 RealBadAngel i wasnt changing anything else and lags are gone
04:48 hmmmm alright
04:48 hmmmm now i updated to master
04:48 hmmmm current head
04:48 RealBadAngel ok
04:49 hmmmm there are two versions of MeshCollector::append()...
04:49 RealBadAngel yeah
04:49 RealBadAngel one for bump/relief (with tangents)
04:49 RealBadAngel and second for any other case
04:49 hmmmm which version am I supposed to be testing?
04:49 RealBadAngel both are affected the same way
04:50 RealBadAngel so test the non tangent
04:50 hmmmm is it just me or is this silly to have two practically identical functions..
04:50 hmmmm who approved of this pr
04:50 RealBadAngel what functions?
04:50 RealBadAngel two append() ?
04:51 RealBadAngel thats not added with this PR
04:52 hmmmm okay
04:52 RealBadAngel i know its a bit repetitive but makes sense when comes to speed
04:52 hmmmm now at HEAD, MeshCollector::append is taking up ~230000 nanoseconds per execution
04:53 hmmmm that's 230 microseconds
04:53 hmmmm which is a bit of an issue
04:53 RealBadAngel yup those are those insane numbers i saw before
04:54 hmmmm and now without the reserves they're back to around ~650-700 ns
04:54 hmmmm slower than the original version for sure, but way better than what's in there right now
04:54 RealBadAngel a bit longer propably because of conditions
04:55 hmmmm right
04:55 hmmmm and i'm testing with a debug build so
04:55 RealBadAngel that could be reason to make another separate code
04:55 hmmmm MeshCollector::append() is being called for every single vertex..?
04:55 RealBadAngel but then you will ask who approved it again ;)
04:56 RealBadAngel not a vertex, but a face
04:56 RealBadAngel rather 4 vertices, 6 indices always
04:57 RealBadAngel i cant remind now if there can be any other case
04:57 RealBadAngel maybe with meshes but not sure
04:59 hmmmm so the number of vertices or indices per append is around like 8/24?
05:00 RealBadAngel 4 and 6 always
05:00 hmmmm errr, 4/6
05:00 hmmmm yea
05:00 hmmmm i forgot this was only a single face
05:01 sofar RealBadAngel: interesting problem with the halo
05:01 sofar RealBadAngel: the new mesh doors
05:01 RealBadAngel sofar, yes?
05:01 sofar RealBadAngel: when the door is open, point at the bottom half of the door -> 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/gd​c04_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/minet​est/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:33 Hunterz joined #minetest-dev
06:40 Lunatrius joined #minetest-dev
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:53 Icedream joined #minetest-dev
06:57 Alduin_ joined #minetest-dev
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:11 Alduin_ joined #minetest-dev
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/wikipedi​a/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 :)
07:45 hmmmmm joined #minetest-dev
07:48 ekem joined #minetest-dev
07:49 cheapie joined #minetest-dev
07:53 xeranas joined #minetest-dev
08:16 paramat joined #minetest-dev
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
08:39 nrzkt joined #minetest-dev
08:48 paramat left #minetest-dev
09:36 Ardonel joined #minetest-dev
09:41 Calinou joined #minetest-dev
11:23 everamzah joined #minetest-dev
11:29 RealBadAngel oke doke, i have clouds working ok with shortened view range :)
11:41 est31 joined #minetest-dev
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 <hmmmm> 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 proller joined #minetest-dev
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:17 proller joined #minetest-dev
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 proller joined #minetest-dev
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 blaze joined #minetest-dev
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 Megaf joined #minetest-dev
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 <RealBadAngel> 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
13:29 Fixer joined #minetest-dev
13:58 STHGOM joined #minetest-dev
14:06 H-H-H joined #minetest-dev
14:16 Fixer joined #minetest-dev
14:22 Hunterz joined #minetest-dev
14:27 kaadmy joined #minetest-dev
14:52 est31 joined #minetest-dev
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?
14:55 yukaputz joined #minetest-dev
15:11 asl97 joined #minetest-dev
15:13 Alduin_ joined #minetest-dev
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:20 blaze joined #minetest-dev
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 Player_2 joined #minetest-dev
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:46 Hunterz joined #minetest-dev
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:21 ElectronLibre joined #minetest-dev
16:22 asl97 joined #minetest-dev
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:41 hmmmm joined #minetest-dev
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:03 proller joined #minetest-dev
17:29 Obani joined #minetest-dev
17:33 sofar RealBadAngel: I would, but I don't think you'll like my opinion
17:34 RealBadAngel sofar, go on
17:35 Krock joined #minetest-dev
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 proller joined #minetest-dev
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 Gael-de-Sailly joined #minetest-dev
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 Robert_Zenz joined #minetest-dev
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 Megaf joined #minetest-dev
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:19 nrzkt joined #minetest-dev
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 rubenwardy joined #minetest-dev
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:38 linkedinyou joined #minetest-dev
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 kaeza joined #minetest-dev
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:01 kaeza joined #minetest-dev
19:05 DFeniks joined #minetest-dev
19:09 kaeza joined #minetest-dev
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
19:09 Alduin_ joined #minetest-dev
19:17 Darcidride joined #minetest-dev
19:43 asl97 joined #minetest-dev
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
20:43 dfelinto joined #minetest-dev
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
21:54 nrzkt joined #minetest-dev
22:30 proller joined #minetest-dev
22:44 turtleman joined #minetest-dev
22:57 est31 joined #minetest-dev
23:01 johnnyjoy joined #minetest-dev
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:24 dfelinto joined #minetest-dev
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:28 ShadowBot` joined #minetest-dev
23:29 Fixer forum error
23:31 jomat_ joined #minetest-dev
23:32 VirusJones joined #minetest-dev
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
23:43 ElectronLibre joined #minetest-dev
23:44 asl97 joined #minetest-dev
23:48 Calinou joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext