IRC log for #minetest-dev, 2015-06-04

Time	Nick	Message
00:01	RealBadAngel	est31, here?
00:06		est31 joined #minetest-dev
00:07	RealBadAngel	est31, ?
00:08	est31	I've compiled godot, and opened a web site the same time
00:08	est31	too much for my 8 gb RAM
00:08	est31	system froze
00:08	est31	had to reboot
00:08	RealBadAngel	i think i manage to make something way more nicer than i expected to
00:08	RealBadAngel	https://imgrush.com/LCf8h8L6otDY.png
00:09	RealBadAngel	https://imgrush.com/VXTTEprbkzMl.png
00:09	est31	cool
00:09	RealBadAngel	lava is absolutely amazing
00:09	RealBadAngel	it is animated
00:10	est31	but somehow its not right
00:10	RealBadAngel	you should see it animated
00:10	est31	on the left, the difference is very large, on the right the difference is very small
00:11	RealBadAngel	those are shadows
00:13	RealBadAngel	need to fine tune it anyway
00:14	RealBadAngel	but still as for effect generated on the fly, basing only on 16px textures?
00:14	RealBadAngel	i think thats more just cool :)
00:14	est31	yes
00:14	est31	really cool
00:21	RealBadAngel	i think i will make this an option that will replace "generate normalmaps"
00:21	RealBadAngel	with addition of parallax it looks more complete
00:55		paramat left #minetest-dev
01:01		Darcidride joined #minetest-dev
01:28		leat joined #minetest-dev
02:02		kaeza_ joined #minetest-dev
02:12		minetest-dev103 joined #minetest-dev
02:53		kaeza joined #minetest-dev
02:55		Wayward_Tab joined #minetest-dev
05:16	* cheapie	peeks in
05:17	cheapie	Any progress on the server-randomly-dropping-clients thing that's been happening for... ehh, what was it now... over a year?
05:17	cheapie	(VanessaE's creative server has it worst, but I've seen it elsewhere)
05:17	est31	The problem: how to reproduce locally
05:17	est31	show me, then the bug is almost fixed
05:18	cheapie	Try downloading VanessaE's creative server world, and you may be able to.
05:18	cheapie	Let me grab the link.
05:18	cheapie	Map: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/worlds/Creative_World.tar.bz2
05:18	hmmmm	obviously not.
05:18	hmmmm	that has nothing to do with network connections
05:18	cheapie	Game: https://github.com/VanessaE/dreambuilder_game
05:19	cheapie	As far as I can tell, this is bug #1425.
05:19	est31	no free disk space
05:21	cheapie	It seems like maybe players that are in the process of connecting are being deleted, but ones that are already fully joined and working fine are not.
05:55		Hunterz joined #minetest-dev
06:00		Anchakor joined #minetest-dev
06:58		Calinou joined #minetest-dev
07:08		kaeza_ joined #minetest-dev
07:11		Darcidride joined #minetest-dev
07:36		jin_xi joined #minetest-dev
07:40		OldCoder joined #minetest-dev
08:01		Yepoleb_ joined #minetest-dev
08:03		proller joined #minetest-dev
08:11		selat joined #minetest-dev
08:14		leat joined #minetest-dev
08:22		cib0 joined #minetest-dev
08:28	* VanessaE	peeks in for a minute
08:28	VanessaE	hmmmm: no, you're right that the disconnect/delete isn't network-related (I believe it's related to that playersao rewrite ShadowNinja did a while back).
08:29	VanessaE	but the ghost entities bug is what precipitates it. THAT bug should be reproducible locally, but the disconnect bug is kinda hard to reproduce without at least some significant network latency (to force players to take "too long" to connect - long enough to get "deleted")
08:30	* VanessaE	peeks out and goes to bed
08:34		leat joined #minetest-dev
08:45		leat joined #minetest-dev
09:33		Megaf_ joined #minetest-dev
09:45		leat joined #minetest-dev
09:55		leat joined #minetest-dev
10:14		leat joined #minetest-dev
10:15	Calinou	-- Deprecated ore generation code
10:15	Calinou	it's 2015, should we remove this code? (mapgen.lua)
10:15	Calinou	it's been deprecated for 2.5 years now
10:15	Calinou	it'll break mods that rely on it but I don't know any that does
10:16		leat joined #minetest-dev
10:23		TheWild joined #minetest-dev
10:26		leat joined #minetest-dev
10:36		Amaz joined #minetest-dev
10:53		leat joined #minetest-dev
10:57		leat joined #minetest-dev
11:09		leat joined #minetest-dev
11:13		proller joined #minetest-dev
11:30	Megaf_	If deprecated it should be removed yes
11:38		leat joined #minetest-dev
11:39		john_cephalopoda joined #minetest-dev
11:58		leat joined #minetest-dev
12:00		proller joined #minetest-dev
12:33		est31 joined #minetest-dev
12:33	est31	Calinou, thats a reasonable long amount of time to wait until remov
12:33	est31	e
12:33	est31	reasonably*
12:41		Wayward_One joined #minetest-dev
12:46		cib0 joined #minetest-dev
12:48		SopaXT joined #minetest-dev
12:52		RealBadAngel joined #minetest-dev
13:10		Wayward_One joined #minetest-dev
13:23		Wayward_One joined #minetest-dev
13:25		Wayward_One joined #minetest-dev
13:27		kahrl joined #minetest-dev
13:32		Wayward_One joined #minetest-dev
13:37		Wayward_One joined #minetest-dev
13:41		Wayward_One joined #minetest-dev
14:02		Wayward_One joined #minetest-dev
14:28		hmmmm joined #minetest-dev
14:31	Calinou	I'll go make a pull request
14:37	Calinou	https://github.com/minetest/minetest_game/pull/527
14:49		cib_ joined #minetest-dev
15:04		ReactOsItaly joined #minetest-dev
15:08		Wayward_Tab joined #minetest-dev
15:17		Player_2 joined #minetest-dev
15:50	VanessaE	https://forum.minetest.net/viewtopic.php?p=180777#p180777
15:51	VanessaE	I thought there was supposed to be a patch to stop shit like this?
15:55		ReactOsItaly left #minetest-dev
16:18	VanessaE	sfan5: poke
16:19	kahrl	VanessaE: SN proposed one, but apparently it was never merged
16:19	kahrl	http://ix.io/aIH
16:20	VanessaE	sfan5: possible bug in minetestmapper: I supplied an empty colors.txt with the intent of tricking it into giving me a listing of every node used in the world. 40000 x 40000 image size, but I routed the image output via -o to /dev/null. The mapper ran for about two hours (as opposed to 30 minutes or so) and produced no node listing.
16:21	VanessaE	the command line was: ./minetestmapper -i /backups/minetest/worlds-wednesday/Creative_World/ -o /dev/null --backend leveldb --noshading --geometry "-20000:-20000+40000+40000" > /home/minetest/creative-node-list.txt
16:21	VanessaE	kahrl: right. that's what I thought. I think we now have a legit case to merge it :P
16:22	RealBadAngel	kahrl, your opinion on #2755?
16:23	VanessaE	(that guy's spam issue is MUCH worse than what prompted my suggestion originally)
16:23		SopaXT joined #minetest-dev
16:23	RealBadAngel	hmmmm, i think i cleaned everything already
16:24	kahrl	VanessaE: I think it would be better to not drop the message, instead just shorten it in the receiving client (and only for the recent-chat buffer, not the chat console)
16:25		rubenwardy joined #minetest-dev
16:25	kahrl	c55 seems to agree with that http://irc.minetest.ru/minetest-dev/2014-02-20#i_3591236
16:26	VanessaE	kahrl: I dunno - see, that won't help old clients
16:26	VanessaE	it needs to be done server-side
16:26	VanessaE	dropping the too-long message on the other hand, I agree is a bad idea
16:27	VanessaE	it should be truncated and a warning echoed back to the sender
16:27	rubenwardy	truncated is better than dropping.
16:28	sfan5	VanessaE: I'll look at that later
16:28	kahrl	people won't use old clients for that long, and if they do, it's their fault
16:28		Hunterz joined #minetest-dev
16:28	VanessaE	kahrl: believe me they WILL
16:28	VanessaE	especially mobile users
16:29	kahrl	doesn't mobile have auto update that you can't disable?
16:29	VanessaE	nope
16:29	VanessaE	rather, they often don't update at all
16:30	VanessaE	we got stuck in the 0.4.7 era for a LONG time when those clones first came out, now 0.4.10 has stuck around well past its expiration date.
16:30	VanessaE	that is, the vendors of the clones don't update often
16:31	rubenwardy	s/clones/forks :P
16:31	kahrl	I wouldn't worry about the well-being of people who use crappy clones
16:31		Krock joined #minetest-dev
16:31	rubenwardy	or ports? The server list statistics are surprising.
16:32	VanessaE	kahrl: I am very concerned with them because they make up like 60 or 70 percent of our userbase now.
16:32	VanessaE	rubenwardy: I suppose "ports" is the most accurate term,
16:33	kahrl	when they complain about it, you could take that as an opportunity to inform them about more well-maintained apps
16:33	kahrl	(or you could add an on_chat_message handler that drops long messages)
16:43	RealBadAngel	kahrl, so can you vote my pr?
16:43	VanessaE	kahrl: well, IRC servers routinely truncate messages for similar reasons
16:44	VanessaE	so I don't see why we shouldn't do the same.
16:44	VanessaE	you simply can't rely on client users,
16:44	VanessaE	to update to newer versions of their clients (which, for mobiles, seems to often require a whole new app install).
16:44	RealBadAngel	kahrl, btw : https://imgrush.com/LCf8h8L6otDY.png https://imgrush.com/VXTTEprbkzMl.png https://imgrush.com/br08SqViTF2k.png
16:45	RealBadAngel	^^ thats is effect generated on the fly
16:45	VanessaE	and if fix it on one server (and the server operator updates), you fix dozens of clients in the process.
16:46	kahrl	well, tbh I never liked that (imho) misfeature of IRC
16:46	VanessaE	neither do I
16:46	VanessaE	but that feature isn't there for intelligent people like us.
16:46	kahrl	you type a long message, then if you are lucky minutes later someone tells you that your message got truncated, and then begins the fun of splitting the message (unless you are lucky enough to have a client that splits automatically)
16:46	VanessaE	"this is why we can't have nice things"
16:47	VanessaE	in any case, this needs two fixes.
16:47	RealBadAngel	does shadowbot have the code to handle messages?
16:47	RealBadAngel	it could be ported propably
16:47	VanessaE	one on the server to truncate the message and warn the sender, and on the client there needs to be a fix to prevent the FPS loss that comes with long messages
16:48	VanessaE	(I just tried @6b7fb59 and the FPS loss is still a problem)
16:48	kahrl	RealBadAngel: how much does it cost in performance to change the vertex type to vertex with tangents?
16:48	RealBadAngel	nothing
16:48	kahrl	are you sure?
16:48	RealBadAngel	yes, VanessaE stress tested it
16:48	kahrl	I thought mesh uploads were a bottleneck on some cards
16:49	VanessaE	kahrl: yeah, I ran some benchmarks: http://pastebin.com/8jYr2tMi
16:49	RealBadAngel	vertices are object without a type, kind of vertex inside doesnt matter rly when creating it
16:50	kahrl	so it does cost a little bit
16:50	kahrl	1fps might be devastating on old hardware
16:50	VanessaE	kahrl: that's probably statistical noise - I only ran one test with each mode.
16:51	kahrl	yeah, it could be
16:51	VanessaE	and in each case, fps tended to vacillate by 1 fps
16:51	RealBadAngel	also theres no way to have different kind of vertices at the same time
16:51	kahrl	but it's consistent enough (in the table) that it might not be
16:51	RealBadAngel	all have to be of one kind
16:51	VanessaE	so I took what seemed like the "nominal" value
16:52	RealBadAngel	kahrl, no, she made test with parallax not considering one thing
16:52	kahrl	RealBadAngel: would that be needed? multiple vertex types?
16:52		ElectronLibre joined #minetest-dev
16:52	RealBadAngel	before parallax has no iterations, just one step
16:52	RealBadAngel	now its iterated with default 5 steps (so 4 extra reads from sampler)
16:53	RealBadAngel	with setting iterations to 1, she gained 10fps
16:53	RealBadAngel	about vertex types, no. i need them consistent
16:53	RealBadAngel	and whole mapblock mesh need to have tangents
16:54	RealBadAngel	in the future all meshes will have it
16:54	RealBadAngel	everything whats a bit more advanced than simple bumpmapping requires tangent space
16:54	kahrl	why? what's the use if shaders are disabled (or just basic shaders are enabled)?
16:55		leat joined #minetest-dev
16:55	RealBadAngel	without shaders it wont be just used. and in this case theres no difference in performance
16:55	RealBadAngel	but it will be if we put there code to switch types runtime
16:56	kahrl	are you saying that recalculating tangent takes 0 time?
16:56	kahrl	vertex tangents*
16:56	RealBadAngel	ofc not
16:56	RealBadAngel	but its done only when shaders enabled
16:56	RealBadAngel	and thats a) done in thread
16:57	kahrl	in that case, why send uninitialized data to the video card?
16:57	kahrl	(and unused)
16:57	VanessaE	there's another thing to consider: repeating the shader+bump+para+iter=1 test, minetest is sitting there eating 92% of one core
16:57	VanessaE	so this is clearly CPU-bound still
16:57	VanessaE	(27 fps, 94m view at present)
16:58	kahrl	yeah, meshes are made in a thread, but it's still one of the slowest parts of loading mapblocks
16:58	RealBadAngel	if you insist i can make vertex types dependent on shaders on/off
16:58	RealBadAngel	but it will cost creation time, it will be slower thx to conditions
16:58	RealBadAngel	atm theres no difference in performace with shaders off
16:59	kahrl	well, yuo already added a condition for that in scaleMesh and translateMesh :P
16:59	kahrl	you*
16:59	RealBadAngel	ofc
16:59	VanessaE	kahrl: I don't think this is mesh creation - I'm looking at landscape that's fully loaded up, and there's no active node changes happening, so there's nothing to create
16:59	RealBadAngel	such conditions are everywhere in the engine, dozens of times
17:00	RealBadAngel	also without any templates like hmmm suggested
17:00	RealBadAngel	i tried to use them but its rather not worth it and hard to make
17:01	RealBadAngel	vertices doesnt have a type at all, theyre void *
17:01	kahrl	looking at those, I see an obvious thing that could be optimized
17:01	rubenwardy	It would be interesting to see the statistics on user's computers, and their support of shaders
17:01	RealBadAngel	so flag have to be tested no matter what
17:01	kahrl	don't recalculate the bounding box from scratch, instead translate/scale it by the given factor
17:02	kahrl	that might be enough to outweigh the performance downside of the vertex type switch :P
17:02		leat joined #minetest-dev
17:02	RealBadAngel	kahrl, that code was the copy of irrlicht one
17:03	RealBadAngel	just stripped down to one vertex type
17:03	kahrl	irrlicht code isn't optimized 100%
17:03	RealBadAngel	everythin in irrlicht has such code and thats not a problem
17:03	RealBadAngel	propably not :)
17:04	VanessaE	here's a screenshot of that test, with the debug graphs visible: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot%20-%2006042015%20-%2001%3a03%3a58%20PM.png
17:04	kahrl	you're making it sound like a problem if you're worrying about microoptimizing switches that are called maybe twice per mapblock mesh
17:05	RealBadAngel	kahrl, i can make it, after a thought it can be done easily
17:05	RealBadAngel	i will just make a copy of mesh collector using old type
17:05	RealBadAngel	without switches
17:06	RealBadAngel	my point was, why to complicate code if theres no difference in performance
17:06		cib0 joined #minetest-dev
17:07	kahrl	this is one of the things that would have to measured on a lot of different hardware
17:07	VanessaE	anyone want to write a benchtest program for the purpose?
17:07	VanessaE	:)
17:08	kahrl	meshes have to be uploaded from the main thread, so if a card is slow at that, it will cause framerate to drop
17:08	RealBadAngel	ok, so without shaders i will fall back to video::EVT_STANDARD
17:09	RealBadAngel	with shaders enabled every mesh out there will be using video::EVT_TANGENTS
17:09	RealBadAngel	for starters only mapblock mesh
17:10	RealBadAngel	when migrated all of them, we can eliminate then switches from scaleMesh etc
17:10	RealBadAngel	so detecting the type will be only on shaders enabled or not
17:10	* VanessaE	turns on mipmap+aniso alongside the shaders+bumps+para+iter=1, just to see how it performs...
17:11	RealBadAngel	you tried that already, 10fps for ya
17:11	kahrl	don't you still need the switches for the case of disabled shaders?
17:12	RealBadAngel	that could be made easier i think
17:13	VanessaE	holy crap, that combination is a FPS killer. 17 fps @ 35m, 12 GB RAM usage, 89% of one CPU core.
17:13	RealBadAngel	whole set of functions could be selected to be used depending on shaders state
17:14	VanessaE	I have a feeling that if the RAM usage discussion from yesterday were put into practice, it would boost FPS as well by giving the engine less texture data to chew on at one time.
17:14	kahrl	RealBadAngel: feels like something that could blow up easily
17:14	kahrl	RealBadAngel: what if there's a mesh that came from somewhere you don't control, say from a file
17:15	kahrl	and it has a different vertex type than the function expects
17:15	RealBadAngel	that doesnt contain vertex types
17:15	VanessaE	oh and if I rotate my view around to a part of the map that has a lot of (default tree) leaves, it drops down to just 9 to 12 FPS
17:15	RealBadAngel	thats irrlicht feature only, not the files
17:15	RealBadAngel	VanessaE, stop using 512x, its way too much for mt
17:16	VanessaE	RealBadAngel: the sliding textures problem still exists btw.
17:16	VanessaE	RealBadAngel: I don't normally use HDX at all, I usually just use default textures -- for exactly this reason :P
17:16	RealBadAngel	256x is good enough, with it and slower hardware i get steady 60fps
17:16	RealBadAngel	and i do have 4gb of ram :P
17:16	VanessaE	"slower hardware".. meanwhile this is an AMD R9 280X. that's NOT slow hardware by any stretch
17:17	VanessaE	besides, this is HDX512 for these tests because it's the heaviest load I could think to put minetest under.
17:18	RealBadAngel	you propably put more swap to test (and ram usage)
17:18	VanessaE	nope.
17:18	VanessaE	the whole thing just fits into my available RAM.
17:18	VanessaE	(I have 16 GB)
17:19	kahrl	RealBadAngel: well we don't control what vertex type comes out of a ISceneManager::getMesh call (or similar), and the docs don't specify it so we can't rely on anything there
17:19	RealBadAngel	out of irrlicht mesh we can know
17:19	kahrl	it might only return S3DVertex today but what if the next version adds support for formats with tangents?
17:20	RealBadAngel	thats what we do check in scaleMesh for example
17:20	RealBadAngel	those enums are irrlicht ones
17:20	kahrl	yeah, and I think that's still needed
17:20	RealBadAngel	that doesnt hurt that much imho
17:21	kahrl	you could probably shorten the code using getVertexPitchFromType (or an equivalent lookup table), at the expense of adding casts
17:21	* VanessaE	turns off all shaders and leaves mipmap+aniso on.... 30 FPS, 114m view range, 8.3GB RAM usage, 100 percent CPU usage on one core plus another 1-5 percent on another.
17:23	RealBadAngel	kahrl, i dont think so.
17:24	RealBadAngel	as i said, vertices in meshbuffer are void *
17:24	RealBadAngel	only way to get its type is ->getVertexType();
17:24	kahrl	ah right, there's lots of casts already
17:26	kahrl	so you could do: u8 vertices = (u8) buf->getVertices(); for (u16 i = 0; i < vertex_count; i++) { (S3DVertex)(vertices + istride)->Pos += vec; }
17:26	kahrl	where stride is the result of getVertexPitchFromType
17:27	RealBadAngel	kahrl, getVertexPitchFromType parameter is a type you should get from mb->getVertex(type)
17:28	RealBadAngel	you just overcomplicated the code :)
17:29	kahrl	err add an additional parenthesis around (S3DVertex)(vertices + istride), but yeah
17:29	kahrl	why would it be more complicated? to me, less branches means less complicated
17:30	kahrl	and it's less repetition
17:30	RealBadAngel	instead of one switch we do have addition, multiplication and call to get the stride
17:31	RealBadAngel	maybe less repetitive but that code will be slower for sure
17:31	VanessaE	here's an updated benchmark post with those two new tests added in: http://pastebin.com/2yYx1CuE
17:32	VanessaE	(also I hate how pastebin destroys my formatting)
17:32	kahrl	and doing "vertices[i].Pos" doesn't involve an addition and a multiplication?
17:34	RealBadAngel	vertices + i*stride
17:35	RealBadAngel	that will be recalculated for every step
17:36	RealBadAngel	oh, so it will be even worse, switch is one per meshbuffer, that is per every vertex in it
17:37	kahrl	vertices[i].Pos is just a shorthand for (type)((u8)vertices + i sizeof(*vertices) + offsetof(type,Pos))
17:37	kahrl	have you coded any assembly?
17:38	rubenwardy	Are you suggesting he optimises it by writing it in assembly?
17:38	RealBadAngel	yes, a lot
17:38	RealBadAngel	but it was long time ago
17:38	RealBadAngel	long before c++
17:39	RealBadAngel	kahrl, ok i will test your idea
17:40	RealBadAngel	VanessaE, why from benchmark theres missing comparision that was showing that current shaders code is faster?
17:40	kahrl	you can get rid of the multiplication by incrementing vertices by stride every iteration
17:40	kahrl	but I'm pretty sure the compiler would optimize that to the same code
17:41	RealBadAngel	everything related to tangent space is about 30% faster
17:41		leat joined #minetest-dev
17:41	kahrl	brb
17:41	RealBadAngel	ok
17:42	VanessaE	RealBadAngel: because testing with your patch requires recompiling is all.
17:42	RealBadAngel	atm all you can read from the benchmarks is that new code is slower
17:42	RealBadAngel	which is absolutely false
17:42	VanessaE	I'll do that now.
17:42	RealBadAngel	:)
17:43	RealBadAngel	also, using shaders in general should be faster
17:44	RealBadAngel	because from vertex shader is missing calculating tangent space
17:51	VanessaE	RealBadAngel: http://pastebin.com/Avs3S9VK
17:52	VanessaE	wait, I put that result in the wrong column
17:53		selat joined #minetest-dev
17:54	* VanessaE	runs another test and corrects the columns...
17:58	VanessaE	RealBadAngel: http://pastebin.com/z66FC6YL
17:58		MinetestForFun joined #minetest-dev
17:59	VanessaE	your new shaders code is definitely faster.
18:00	VanessaE	roughly +10 fps (if you compare upstream line 21 with your code line 46)
18:01		leat joined #minetest-dev
18:01	VanessaE	(and +14 fps if just looking at line 21 by itself)
18:06	RealBadAngel	good :)
18:06	RealBadAngel	kahrl, ok that works
18:07	RealBadAngel	i will replace the switches in other functions
18:07	VanessaE	however, it still has to be noted that the view range was somewhat variable, so figure a 10% margin of error
18:08	RealBadAngel	i can see improvemnt here too
18:08	RealBadAngel	with all the stuff enabled and 256x i get always 60fps
18:08	VanessaE	sure you get 60fps but what about the view range?
18:08	RealBadAngel	with 100 iterations for parallax fps has dropped for me to 30fps
18:11	RealBadAngel	with 16px textures but with parallax and bumpmapping on the fly it starts to drop below 60 with 325 distance
18:11	RealBadAngel	parallax + bumpmapping on the fly is way more costly than regular ones
18:12	RealBadAngel	normals on the fly means 8 extra reads from sampler, parallax 20 extra reads
18:12	RealBadAngel	comparing to 2 reads if maps are supported
18:23	RealBadAngel	kahrl, well replacing the switches with stride thingy caused 50% fps drop
18:23	RealBadAngel	also enormous lags, many mapblocks stay long time without visible surfaces
18:29		crazyR_ joined #minetest-dev
18:29		crazyR_ joined #minetest-dev
18:30	RealBadAngel	kahrl, hold on, that was something different i think, rebuilding again
18:48		est31 joined #minetest-dev
18:52		Hijiri joined #minetest-dev
18:55		greenman_ joined #minetest-dev
18:59		proller joined #minetest-dev
19:04		SopaXT joined #minetest-dev
19:09		cib_ joined #minetest-dev
19:24		MinetestForFun joined #minetest-dev
19:53		Player_2 joined #minetest-dev
19:54		Hijiri joined #minetest-dev
20:14		RealBadAngel joined #minetest-dev
20:14	RealBadAngel	2015-06-04 22:13:29: ACTION[main]: Server for gameid="minetest" listening on 0.0.0.0:65401
20:14	RealBadAngel	huh?
20:20		Wayward_Tab joined #minetest-dev
20:20		proller joined #minetest-dev
20:22		leat joined #minetest-dev
20:23		Amaz joined #minetest-dev
20:24		kaeza joined #minetest-dev
20:27		troller joined #minetest-dev
20:32		leat joined #minetest-dev
20:34		kaeza_ joined #minetest-dev
20:34		diemartin joined #minetest-dev
20:36	RealBadAngel	btw, an idea, when setting fancy trees to false, previously transparent areas on leaves are black, thats a bit ugly
20:36		ElectronLibre left #minetest-dev
20:37	RealBadAngel	https://imgrush.com/YYGVhlYGtQo3.png
20:38	RealBadAngel	having green under transparent pixels looks a bit better
20:40	RealBadAngel	https://imgrush.com/9HayohkVyMsk.png
20:40	RealBadAngel	^^^ thats modyfied default_leaves.png
20:42	Wayward_Tab	I agree, that looks much better
20:42		leat joined #minetest-dev
20:44		jin_xi joined #minetest-dev
20:44	RealBadAngel	also it doesnt have to be single color, texture can be made to have full pattern, only apply the transparent mask to it
20:46	RealBadAngel	with that black areas, trees get way too dark
20:48		Hijiri joined #minetest-dev
20:52		leat joined #minetest-dev
20:59		leat joined #minetest-dev
21:02		leat joined #minetest-dev
21:04		proller joined #minetest-dev
21:15		leat joined #minetest-dev
21:24		Hijiri_ joined #minetest-dev

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