Time Nick Message 00:01 RealBadAngel est31, here? 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 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*. 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 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 11:30 Megaf_ If deprecated it should be removed yes 12:33 est31 Calinou, thats a reasonable long amount of time to wait until remov 12:33 est31 e 12:33 est31 reasonably* 14:31 Calinou I'll go make a pull request 14:37 Calinou https://github.com/minetest/minetest_game/pull/527 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? 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 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 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 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 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:40 kahrl [off] if I'm a little grumpy today, it's because the hot weather won't let me get any rest :( 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 [off] many of which are brain-dead stupid, 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 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 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 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: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 + i*stride)->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 + i*stride), 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 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:54 * VanessaE runs another test and corrects the columns... 17:58 VanessaE RealBadAngel: http://pastebin.com/z66FC6YL 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 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:30 RealBadAngel kahrl, hold on, that was something different i think, rebuilding again 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:36 RealBadAngel btw, an idea, when setting fancy trees to false, previously transparent areas on leaves are black, thats a bit ugly 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: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