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

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/blob/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/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: 161616 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: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/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 :)
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

← Previous day | Channels | #minetest-dev index | Today | Next day → | Google Search | Plaintext