Time Nick Message 04:33 RealBadAngel hmmmm, around? 05:22 hmmmm yes? 06:05 VanessaE hmmmm: RealBadAngel probably wants you to +1 the minimap pull request :) 06:06 hmmmm mmmm 06:06 RealBadAngel hmmmm, can you take a look on minimap pr? 06:06 VanessaE told ya ;) 06:07 hmmmm for the minimap shader, there seems to be a lot of math, but what does it do? 06:07 hmmmm there's a lot of .r, are you shading it according to the map light? 06:09 RealBadAngel that math is generating normalmap on the fly 06:10 RealBadAngel .r is read from the heightmap 06:10 hmmmm ahh okay, that makes sense, i didn't get to the part where the textures are uploaded yet 06:10 hmmmm if shaders are disabled, what happens to the minimap? 06:10 RealBadAngel its flat 06:13 hmmmm what's the reasoning behind the 'step' logic in getTextureAverageColor? 06:13 RealBadAngel i do just sample higher res textures 06:13 hmmmm one, you're assuming that textures are always going to be square. is this valid? two, i don't get why in the first place 06:14 RealBadAngel i need a color, most used (or close to) 06:15 RealBadAngel if theyre not square theyre animations 06:15 RealBadAngel so i got first frame sampled 06:15 hmmmm i'm not too familiar with that 06:16 hmmmm VanessaE, is that a valid assumption? 06:16 VanessaE yuep. 06:16 VanessaE yep* 06:16 VanessaE particularly if height is more than 2x the width, you can assume it's an animation 06:16 hmmmm right 06:17 hmmmm but this does not do that 06:17 RealBadAngel even if some1 supplied npot2 texture its not a problem 06:17 hmmmm so if the width is greater than 16, then the number of samples is reduced by a factor of 16. ???? 06:17 hmmmm so if I supplied an npot2 texture of 17x17, that's going to take the average of exactly 4 pixels unless I'm mistaken 06:18 RealBadAngel step is reduced 06:18 hmmmm is that really a good idea...? 06:18 RealBadAngel not the resoultion 06:18 RealBadAngel oops, increased 06:19 hmmmm errrr 06:19 hmmmm you're right 06:19 RealBadAngel and after all its not important which pixels i do hit 06:19 hmmmm okay nevermind I mixed something up 06:19 RealBadAngel i just sample SOME of the pixels 06:19 hmmmm yes it's increased, relative to the size 06:19 RealBadAngel hopin to get right colour 06:19 hmmmm okay sorry about that 06:19 hmmmm for some reason I thought that was * 06:19 hmmmm not / 06:20 RealBadAngel best would be most used color but that would make code much slower 06:20 RealBadAngel and avg and sampled one in practice works quite ok 06:20 RealBadAngel colors found are correct 06:20 hmmmm so, this algorithm isn't terribly accurate but you're at least limiting the amount of pixel fetches to 256 06:20 hmmmm roughly 06:21 RealBadAngel something like that 06:21 hmmmm worst case scenario is 31, where it'd be 31 * 31 06:21 hmmmm because step wouldn't == 2 at that point 06:21 hmmmm in any case I hope the result of getTextureAverageColor() gets cached somewhere 06:21 RealBadAngel result is stored in contentfeatures 06:22 RealBadAngel its done only on startup 06:22 hmmmm great 06:22 RealBadAngel f.minimap_color 06:31 RealBadAngel hmmmm, MinimapMode is enum, there are no increment operators for it 06:32 hmmmm what happens if MinimapMode is at RADAR_MODEx4 when you call toggleMinimap again? 06:32 est31 even then one can use c style casts 06:32 est31 no? 06:32 hmmmm yeah, static_cast(static_cast()) is soo god damn messy 06:33 hmmmm you can't see what operation is actually being performed because so much of the line real estate is being taken up by this overly verbose cast syntax 06:34 hmmmm i'm not even half done :\ 06:34 hmmmm brb need a break 06:37 RealBadAngel hmmmm, after minimap mode it will be OFF again 06:38 hmmmm oh, i see, in the default case 06:38 RealBadAngel value will be out of range so brought down to default ( 0 - off) 06:38 hmmmm yeah it works I guess 06:42 RealBadAngel that sleep_ms(10) is copied from mapblock mesh update thread, ive no idea what for it is ;) 06:43 RealBadAngel to make my thread i took it and modified 06:44 RealBadAngel iirc when i deleted that line engine frozen, so i left it as is 06:45 est31 @ sfan5, other win builders 06:45 hmmmm when will a QueuedMinimaUpdate contain NULL for data? 06:45 est31 did you know that cmake comes with cpack which allows to generate installer binaries? 06:46 est31 for windows 06:46 est31 automatically 06:46 est31 sfan5, http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS 06:47 RealBadAngel hmmmm, when block got unloaded 06:48 RealBadAngel it sends then just pos with no data 06:49 hmmmm okay 06:50 RealBadAngel thats a bit messy, because number of mapblock_meshes != minimap_mapblocks 06:50 RealBadAngel blocks that contain only air have no mesh 06:51 hmmmm well between nerzhul 's comments and mine it looks like you have enough to chew on for now 06:52 RealBadAngel sure :) 06:52 hmmmm there's probably more too 06:52 RealBadAngel well i supposed that there will be a few problems ;) its almost 1k lines 06:53 RealBadAngel btw, why you dont like switch-case for modes? 06:53 hmmmm it's repetitive 06:53 RealBadAngel ofc it is 06:53 hmmmm there's a saying, "if code looks like it's repeating itself, it could be done better" 06:53 RealBadAngel nerzhul didnt liked if-elseif 06:54 hmmmm switch is better than if-elseif for this of course 06:54 RealBadAngel you dont like switch-case 06:54 hmmmm but there's an even better one 06:54 hmmmm an array 06:54 RealBadAngel i knew you are going to say that :P 06:54 RealBadAngel lol 06:55 hmmmm in general, if you're comparing a value to one of several constant values, use a switch statement 06:55 hmmmm if the several constant values are consecutive in value AND they all do the same thing aside from using separate values, make it into an array 06:56 hmmmm RealBadAngel, when people make comments on code, you should understand the reason why we're saying it 06:56 hmmmm if you don't, please ask 06:56 RealBadAngel so i did 06:56 hmmmm this goes for any comment 06:57 RealBadAngel if i see the point i dont comment back just fix it 06:57 RealBadAngel but back to that switch case 06:57 RealBadAngel i think it will get a bit complicated at some point 06:57 hmmmm well look 06:57 hmmmm they're all setting the same expression to true 06:58 RealBadAngel im plannin to add shift for a keystroke 06:58 hmmmm the only thing varying between them is the status text 06:58 hmmmm ? 06:58 hmmmm what do you mean 06:58 RealBadAngel modifier on F9 that will toggle also square/round 06:58 RealBadAngel ah, nvm 06:58 hmmmm errm 06:58 RealBadAngel i just figured out the solution 06:59 RealBadAngel i wont switch mode then 06:59 RealBadAngel just toggle shape 06:59 hmmmm set a flag 06:59 hmmmm honestly that's what I would've done if I were coding this 06:59 RealBadAngel so point for an array 06:59 hmmmm have the shape and the zoom separate variables in the first place 06:59 hmmmm there's nothing completely wrong with the way you implemented it 06:59 hmmmm it's just not how I would've 07:00 RealBadAngel ok, now whats the story with sleep_ms(10) 07:01 est31 btw is it regenerating normals on every draw 07:01 est31 ? 07:02 hmmmm I don't really know what sleep_ms(10) does ther 07:02 hmmmm you're not holding any locks inside getMap() from what it looks 07:02 RealBadAngel est31,in shaders theyre calculated on the fly 07:03 RealBadAngel hmmmm, i dont need to i think 07:03 hmmmm right, you don't need to after you changed the way it works 07:05 RealBadAngel later on i will move texture generation back to minimap thread to save main thread time 07:06 RealBadAngel but for that i need to write my own pixel operations workin directly on texture in memory without involving driver 07:07 RealBadAngel so i will treat that memory kinda as screen. main thread will just read from it 07:07 est31 or I guess different irrlicht context if that works 07:08 RealBadAngel i will just double buffer it to avoid flickering 07:09 hmmmm ohh RBA i don't know man 07:09 RealBadAngel so main will display already prepared one while thread will be working on another frame 07:09 hmmmm that sounds good and all but there are incompatibilities 07:09 hmmmm did you read about multithreaded irrlicht 07:09 RealBadAngel yes, thats why i wont use irrlicht for that 07:10 RealBadAngel i just need double buffered fixed size texture 07:10 RealBadAngel with direct access to it, not a problem since i know the format 07:11 RealBadAngel whats im going to do ask irrlicht to make those textures for me, give me format data and nothing more 07:12 RealBadAngel later on i dont need engine to handle it 07:15 RealBadAngel this way or another it has to be done, 4-5fps cost of minimap is worth to be gained back 07:26 RealBadAngel hmmmm, btw, some1 stated when delete has nothing to remove it does nothing 07:26 est31 me 07:26 est31 I said if you do delete NULL it does nothing 07:27 est31 didnt say "nothing to remove" 07:27 RealBadAngel *** Error in `./bin/minetest': double free or corruption (out): 0x0000000002fa5940 *** 07:27 est31 afaik there is no double-delete protection 07:27 RealBadAngel that is what i got when havent checked if theres something to delete 07:27 est31 but a if (data) check wont save you there 07:27 est31 its only true if data is not null 07:27 est31 err false 07:27 est31 and in that case, delete data works fine already 07:28 RealBadAngel im talkin now about MinimapMapblock 07:28 RealBadAngel which is created in mapblock_mesh 07:29 RealBadAngel only place that should be able to delete is minimap thread 07:29 est31 if you delete, set the pointer to null and be happy 07:29 RealBadAngel but when i do that without checks i can see double free error so, a) theres no leak 07:30 RealBadAngel b) who the f... is deleting it for me ;) 07:31 RealBadAngel i delete only data from cache (pos + ptr to minimap mapblock) 07:31 RealBadAngel m_blocks_cache.erase(it); 07:32 RealBadAngel that shouldnt delete pointed object, right? 07:32 est31 afaik erase calls delete, thats ok? 07:32 est31 oh seems not ok :) 07:33 RealBadAngel or destroying mapblock mesh does that 07:33 est31 ok but as you are storing pointers, it should be ok 07:33 est31 because then only those get erased 07:34 RealBadAngel even when i havent manually add that to destructor 07:34 est31 If I'm reading the docs right 07:34 hmmmm wrong. 07:34 hmmmm erase() on iterators calls the destructor. 07:35 hmmmm if the destructor frees memory allocated over the course of the object's lifetime, then great. otherwise, not so much. 07:35 RealBadAngel if (it->second) { 07:35 RealBadAngel delete it->second; 07:35 RealBadAngel } 07:35 RealBadAngel m_blocks_cache.erase(it); 07:35 RealBadAngel i just modifed it so 07:35 RealBadAngel it hits error on delete 07:35 RealBadAngel so, before erase iterator 07:36 RealBadAngel it must be mapblock mesh class destructor 07:36 RealBadAngel i cant see any other explanation 07:37 RealBadAngel actually it cant be it, i keep minimapmapblocks ptrs for air chunks even when mesh for it got deleted 07:37 hmmmm jesus christ. 07:38 hmmmm this code is going into minetest and you people don't even know the correct semantics behind memory management? 07:38 hmmmm :( 07:38 hmmmm now where is this double free happening exactly? 07:39 RealBadAngel hmmmm, i would like to delete the object as im supposed to do so, but something is doing it for me behind my back 07:39 RealBadAngel a sec 07:39 hmmmm delete which object 07:40 RealBadAngel http://pastebin.com/5hNG3imd 07:40 hmmmm right 07:40 hmmmm the "if (it->second) {" there is unnecessary 07:41 hmmmm i can say with certainty you can change that to just "delete it->second; 07:41 RealBadAngel https://github.com/RealBadAngel/minetest/commit/cfc0aa214285493f868bbd9efd08531a74c3e716#diff-c2f90db5de8c33a259c27113939c63c5R1032 07:41 RealBadAngel i cant 07:41 RealBadAngel this is when i got "double free error" 07:41 est31 hmmmm, yes it calls the destructor 07:42 est31 but a destructor for a pointer type (which is integral), does nothing, no? 07:42 est31 also here: http://stackoverflow.com/a/6353169 07:43 hmmmm est31: correct 07:43 est31 (at least nothing on the pointed object) 07:43 hmmmm a pointer is just some number 07:43 hmmmm a destructor does nothing for a pointer 07:43 hmmmm RealBadAngel, sounds like your bug is happening somewhere else. 07:45 RealBadAngel atm i have no idea 07:46 RealBadAngel i will check when it happens 07:46 hmmmm is it possible that you have the same data MinimapMapblock assigned to multiple entries in that map? 07:51 RealBadAngel not possible 07:52 RealBadAngel it is exlusivelly created for each mapblock mesh instance 07:52 est31 I am wondering about adding a new data structure to minetest 07:52 est31 AreaStore 07:53 est31 3 operations: addArea, removeArea, and isInArea 07:53 est31 err replace isInArea with getAreasAround(point) 07:54 est31 because I see the "protection" problem solved from two directions 07:54 est31 the ShadowNinja areas mod defines a large lua table which lists every area on the server 07:55 est31 the tenplus1 protector mod (which bases on earlier mods with the same idea), does get_nodes_near or how its called on every build action 07:55 est31 I've thought: what about combining the two approaches / trading off? 07:56 est31 so instead of having one great list, making an octree and storing areas containing octree elements 07:58 est31 it has other use cases too 07:58 est31 (not just protection) 07:58 RealBadAngel hmmmm, weird, it stopped crashing, i cant reproduce it now 07:58 est31 e.g. technic windmill relies on the area around itself "being free", so that "wind can flow around it" 07:59 est31 right now it re-checks the whole area every 20 seconds 08:01 est31 now my big question is where to store that 08:01 est31 I mean I can think of nice serialisation methods, just where to put the data 08:01 est31 preferrably so that you dont have to load it all into memory 08:01 est31 like current map data for example 08:01 Jasper Hey. I come from a company who wants to ship Minetest on ARM. On our platform, we only have GLESv2. I noticed that Minetest was using Irrlicht, which really doesn't have GLESv2 support -- it just seems to be dead upstream. 08:02 Jasper We could fund / develop a custom GLESv2 renderer, but it would be nice if it was upstream or similar. 08:02 Jasper Any thoughts on this? 08:03 RealBadAngel Jasper, we do already have arm build 08:03 est31 yea but shaders are broken 08:03 RealBadAngel shaders have to be simplyfied for ES 08:03 est31 also its arm android 08:04 est31 which arm platform do you target Jasper ? 08:04 Jasper est31, our own ARM-based OS called EndlessOS 08:04 RealBadAngel one should strip shaders to only care for finalColorBlend and nothing more 08:04 Jasper est31, based on traditional desktop Linux 08:04 RealBadAngel rest of the effects wont work on ES, except for maybe waving plants 08:05 Jasper Does Irrlicht even support GLES? 08:05 Jasper All evidence I could find pointed towards no 08:05 VanessaE hasn't Megaf done that once at least? 08:05 VanessaE (MT + GLES) 08:06 RealBadAngel googlin for irrlicht and GLES show lotsa examples 08:06 Jasper I see an official branch / fork. 08:06 Jasper er 08:06 Jasper unofficial 08:06 RealBadAngel oven on RPI 08:06 RealBadAngel *even 08:07 Hunterz btw is there any izometric map like dynmap known on the bukkit/minecraft? 08:08 est31 Hunterz, there was one I think xyzz did it 08:08 est31 but have no link 08:08 est31 VanessaE has shared one 08:08 Jasper RealBadAngel, yeah, see: http://svn.code.sf.net/p/irrlicht/code/branches/ogl-es/ogles-readme.txt 08:09 VanessaE https://github.com/xyzz/onomatopoeia 08:09 Hunterz thanks 08:09 VanessaE it's way outdated though 08:09 VanessaE doesn't even render nodeboxes :) 08:11 RealBadAngel Jasper, i guess if you will add support for GLES to mt it could be merged 08:11 RealBadAngel i can help you with shaders 08:11 Jasper Any reason you guys use Irrlicht? 08:11 RealBadAngel because c55 picked it some time ago? :) 08:11 * Jasper was just thinking of writing a renderer from scratch 08:12 hmmmm people have been talking about a move to a modern, advanced engine 08:13 hmmmm i advocate OpenSceneGraph 08:13 Jasper I haven't seen any modern, open-source renderer that isn't also just flat out dead. 08:14 Jasper I can't imagine your drawing needs are very complex... 08:15 RealBadAngel heres still lotsa to do 08:16 hmmmm most of the trouble parts are not in rendering, but rather streaming mesh changes to the gpu efficiently 08:16 VanessaE hmmmm: ^^^^ which I've found out, seems to be the cause of my performance issues with minetest of late. 08:17 VanessaE (both in and out of minetest) 08:17 hmmmm ? it's been a problem since the beginning 08:17 hmmmm nothing changed recently in that respect 08:17 Jasper hmmmm, what's your current architecture here? 08:18 VanessaE well yeah it's been a problem, but lately it just seems..worse. in any case it's because a single 2.8 GHz core isn't fast enough to feed these bad-ass GPUs we have now - after some tests, in my case, three is. 08:18 Jasper The silly way to do it would be to have each block as a separate draw call, but that's what I'd imagine minetest is doing... 08:18 RealBadAngel VanessaE, your problems are driver related rather 08:18 VanessaE RealBadAngel: nope. same performance in open source and closed-source drivers. it's a CPU bottlenbeck. 08:18 VanessaE -b 08:19 Jasper VanessaE, I highly doubt that, though. 08:19 hmmmm the individual cube things are called MapNodes and are stored in MapBlocks, which is a 16x16x16-sized array of data about what each block is 08:19 Jasper hmmmm, I'm more wondering how these things are drawn. Is each MapBlock one VBO? 08:19 hmmmm each MapBlock has its own mesh that is generated in a separate thread and then rendered as part of the map 08:19 Jasper Yeah. 08:19 Jasper And I imagine you do some basic software culling on MapBlocks if they don't need to be drawn, then. 08:19 RealBadAngel VanessaE, threads wont automagically spread over aviable cpus 08:20 hmmmm there weren't any VBOs until very recently because of a dumb irrlicht bug causing a memory leak with VBOs in our use case 08:20 Jasper Nice. 08:20 hmmmm yes, software occlusion culling is performed 08:20 VanessaE RealBadAngel: they will if your OS has a good scheduler and those threads need enough CPU time. 08:20 RealBadAngel hmmmm, ive tested lately VBO 08:20 VanessaE RealBadAngel: it's called thread migration 08:20 hmmmm but anyway 08:20 RealBadAngel and havent noticed any leaks 08:20 hmmmm the problem is that any time a MapBlock is changed in some way 08:20 hmmmm it needs to be regenerated and reuploaded to the gpu 08:20 Jasper hmmmm, glMapBufferRange? 08:20 hmmmm this is fine for nVidia but not so much for Intel 08:21 hmmmm dunno, we can't work with raw OpenGL 08:21 Jasper glMapBufferRange is great on Intel, it's all UMA. 08:21 hmmmm honestly Minetest needs a lot of work but doesn't have enough manpower 08:21 hmmmm there are a lot of things that could be tried 08:21 RealBadAngel hmmmm, hold on, problem with VBO code was missed letting hardware know that mesh has changed 08:21 hmmmm it just needs to be tried 08:21 RealBadAngel and forcing reloading of that mesh 08:22 Jasper Well, we'd be interested in funding / doing some of this development. 08:22 Jasper But we really need direction -- we don't want to write anything that would be eventually thrown away. 08:22 RealBadAngel when taken care of it, VBO works just fine 08:22 hmmmm the majority of us have full time jobs :) 08:22 Jasper Me included. 08:22 Jasper My day job is actually writing the GPU driver for this thing :) 08:23 hmmmm we never threw away any contributions unless they did nothing but rewrite a piece of code with absolutely no benefit 08:23 hmmmm yeah, there is an Intel guy in this channel too 08:23 hmmmm can't point out who at the moment but we talked about the same sort of challenges 08:24 Jasper Don't recognize any of the standard Intel guys in here. 08:24 hmmmm celeron55 or kahrl are probably the ones you'd want to talk to if you'd like to get more in depth about the graphics side of this project. i don't work on the graphics at all hardly 08:24 Jasper OK. 08:24 RealBadAngel it needs to be regenerated and reuploaded to the gpu ----> m_mesh->setDirty(); 08:24 Jasper RealBadAngel, yeah, that probably marks it for rebuilding. 08:24 hmmmm RealBadAngel: does that fix the mesh streaming lag problem? 08:24 hmmmm didn't think so! 08:24 Jasper I just didn't know if you guys were attached to Irrlicht at all, given that I'd probably write a custom renderer. 08:25 hmmmm the client is heavily attached to Irrlicht 08:25 Jasper Sure, I'd imagine the code is, but I don't know if you guys are. 08:25 RealBadAngel hmmmm, we need to do that ONLY when vertices has changed - pos or color 08:25 hmmmm certainly not 08:25 hmmmm all of us hate irrlicht 08:25 Jasper vertex colors? 08:25 RealBadAngel yes 08:25 Jasper I suppose it fits the asthetic... 08:26 RealBadAngel vertex color are used for lighting 08:26 Jasper Yeah, for that authentic 80s per-vertex lighting feel. 08:26 RealBadAngel also could be used for EMT_TRANSPARENT_VERTEX_ALPHA materials 08:26 VanessaE hmmmm: zeno has been working off and on to abstract that out a bit so that irrlicht can be dropped in the future. 08:26 hmmmm that's cool. haven't seen zeno in a while 08:26 RealBadAngel in those cases driver has to be forced to reupload mesh 08:26 hmmmm you haven't seen me in a while either though 08:27 hmmmm I promise to be around more often 08:27 hmmmm later, it's 4:30 am 08:27 hmmmm I *need* to go 08:27 VanessaE in that case I'll be hiding more ;) 08:28 Jasper west coast represent 08:28 * VanessaE mumbles something about being in the east 08:28 Jasper i used to be over there 08:34 RealBadAngel Jasper, anyway if you will need any help regarding shaders feel free to ask 08:34 Jasper I'm pretty OK with shades. 08:35 Jasper shaders, rather 08:41 RealBadAngel btw, https://imgrush.com/qr9Ly_nmAwNI 08:42 Jasper Nice seam. 08:42 VanessaE RealBadAngel: first tests of the new skybox code? 08:42 RealBadAngel had to rework irrlicht skyboxes code to support vertex alpha 08:42 RealBadAngel background is black 08:42 RealBadAngel you can see there one face of skybox with different alpha than others 08:43 RealBadAngel so blending skyboxes will be definitely possible 08:43 RealBadAngel also fading in and out skyboxes will be fast 08:43 RealBadAngel its only change colour of 24 vertices per skybox 08:45 celeron55 Jasper: you can ask me if you can't figure out something on your own or need a qualified opinion for whether doing something makes sense 08:45 Jasper celeron55, would you be OK with a custom renderer? 08:45 Jasper celeron55, I'm not sure how much of irrlicht you guys use -- I only started to poke through the code today. 08:45 celeron55 Jasper: what you are wishing to do is really the hardest thing you can imagine doing to Minetest, so keep that in mind; it's also becoming increasingly wanted within the community so that does help though 08:46 Jasper celeron55, also, besides just "support GLESv2", any other goals I should keep in mind? 08:46 Jasper celeron55, heh, anything above the renderer that actually makes the game is just boring code to me. The renderer is the fun part :) 08:47 celeron55 irrlicht does certain things very right, like being able to be packaged separately for linux without any project-specific build-time options and having a liberal license 08:48 * est31 still wonders why that is this important 08:48 celeron55 minetest uses a lot of irrlicht's types like vectors and vertexes and meshes and irrlicht 08:48 est31 (the first part) 08:48 celeron55 +'s model loading 08:48 celeron55 and irrlicht also provides multi-platform windowing and input 08:48 Jasper Because some distributions *really* care about not having packaged libraries. 08:48 celeron55 it even supports android with ES 1 08:48 Jasper To the point of insanity. 08:49 celeron55 that's what you're going against 08:49 crazyR the windowing and input from irrlicht does look really old and outdated thought 08:49 Jasper I was going to use SDLv2 for platform support, most likely. 08:49 celeron55 irrlicht is good, but old 08:49 Jasper I wouldn't go as far to say "good". 08:49 celeron55 well, it's not good anymore because it's outdated :P 08:50 celeron55 it once was, for a library with such licensing and so 08:50 Jasper Yeah. SDLv2 has it beat on the platform support, I feel. 08:50 Jasper And the renderer is just sort of... well, uh. 08:50 celeron55 the renderer is ancient; i know 08:51 Jasper Do you guys use any of its model loading parts? I don't really know what you guys do for models, if anything. 08:51 Jasper All procedural? 08:51 celeron55 irrlicht also has a lot of things that we don't use, like automatic asset loading from zip files and whatnot; so it's not a complete catastrophe 08:51 celeron55 we use irrlicht's model loading support, and basically all of irrlicht's supported model formats are used by modders so if any is dropped, it probably makes someone very sad 08:52 Jasper That's what, exactly? 08:53 celeron55 also image formats 08:53 crazyR celeron55 would it not be possible to create a wrapper with a library to keep irrlicht's model formats supported with what ever its used as a replacement? 08:53 celeron55 https://github.com/minetest/minetest/blob/master/src/server.cpp#L2238 08:53 crazyR then pver time drop the wrapper 08:53 celeron55 this is the server's file extension filter list 08:53 Jasper What is .x? 08:53 RealBadAngel we use obj without mtl and .x 08:54 RealBadAngel i dont remember seeing some1 using another formats 08:54 RealBadAngel d3d models 08:54 Jasper It seems to be an extremely old DirectX format? 08:54 celeron55 crazyR: it's probably reasonably easy to use irrlicht for just loading images and models 08:54 Jasper .obj is easy enough to support. 08:55 celeron55 it's also possible to just copy the model loaders from irrlicht; it's open source with a suitable license anyway 08:55 est31 ^ 08:55 Jasper .b3d seems to be "Blitz Basic 3D" 08:55 * est31 has copied openssl's sha1 08:55 celeron55 similarly as it is to fork irrlicht and replace large portions of it 08:55 est31 into minetest 08:56 celeron55 there are lots of options here; someone smart enough just has to do the work 08:56 Jasper Yeah. 08:56 RealBadAngel loaders are not a problem rather 08:56 Jasper To be genuinely honest, I'm not a big fan of keeping around all the model formats here. 08:56 Jasper But it's not an insurmountable problem. 08:56 est31 and about the gui system: countless people want it to replaced anyway 08:56 RealBadAngel imho internal mesh format counts here, dunno if other engines keep it the same as irrlicht do 08:56 RealBadAngel and we are using it widely 08:56 est31 We'd need to get stats about model formats 08:56 crazyR Jasper. wouldnt it be posible to create a converter for the models. ? 08:56 celeron55 if we research what formats are actually used and see that some are not, then it's fine to drop them 08:57 Jasper crazyR, yeah, that's what I'd prefer to do. 08:57 est31 lets do some bash magic on dreambuilder 08:57 RealBadAngel est31, blends export to obj 08:57 Jasper Everything exports to .obj. 08:58 celeron55 it might very well be that we only need obj, i don't think this is an issue actually 08:58 crazyR would actually make sense to have 1 standard 08:58 celeron55 and even if it is, Jasper isn't going to have to make the loaders, someone else can just fine 08:58 Jasper As for textures, .png + stb_image.h 08:59 est31 RealBadAngel, I guess they are convertible into each other 08:59 RealBadAngel as i said, loaders are not important 08:59 Jasper Yeah. The important thing here is working out the structure of the renderer. 08:59 Jasper And the internal mesh format. 08:59 RealBadAngel whats important is the internal mesh format 08:59 Jasper And even that isn't too important. 08:59 celeron55 people basically only use .png and for some cases .jpg; nothing more needed there 08:59 Jasper Do you support mesh animations at all? 08:59 crazyR im getting excited already :/ thats probably a bad idea though 09:00 est31 I think yes 09:00 est31 but i have no gfx knowledge 09:00 Jasper Do we need to support model animations at all? 09:00 celeron55 Jasper: irrlicht supports mesh animations by specifying frame ranges for each animation, and MT supports that 09:00 est31 how is moving skins done? 09:00 Jasper celeron55, does it do HW skinning? 09:00 celeron55 i don't know what that is 09:00 Jasper I mean, is it a bone-based system? 09:01 Jasper .obj doesn't have ways of specifying bones, so.. 09:01 celeron55 i really don't know any model animation terminology and didn't implement it so you'll have to find out :P 09:01 Jasper The traditional way you do it nowdays is doing joints on the GPU. 09:02 Jasper http://http.developer.nvidia.com/GPUGems/gpugems_ch04.html seems like it has a rough overview 09:02 Jasper haven't read it entirely though 09:03 celeron55 oh. i'm dumb and forgot that we actually use one part of irrlicht that is a problem here: the GUI system 09:03 celeron55 everybody hates it, but there is no replacement 09:03 Jasper Yeah, there isn't any great open-source GUI system out there. 09:03 crazyR haha but that really really really needs replacing anyway :D 09:04 Jasper What widgets do we need, anyway? 09:04 Jasper text input, checkbox, radio button? 09:04 celeron55 but how the mods access the gui is independent of irrlicht though, so it *can* be relatively easily swapped 09:04 celeron55 http://dev.minetest.net/formspec 09:05 celeron55 just very basic things with fixed positioning 09:06 celeron55 this needs to be reworked some day by some technique like client-side scripting or at least by adding custom skinning, but now that those don't exist yet, it makes this task easier 09:06 Jasper Now for a silly question here. 09:07 Jasper Does Irrlicht allow me just calling OpenGL right in the middle of it? 09:07 celeron55 i've never tried 09:07 Jasper Would it be possible to hack this up by replacing parts of this with raw GL, so I can do it piecemeal? 09:07 Jasper OK. 09:07 celeron55 irrlicht is a quite thin wrapper in reality thoughh and it is also not threaded 09:07 celeron55 so you might have luck there 09:08 crazyR this looks interesting althought ive only had a quick glance http://sfgui.sfml-dev.de/ 09:09 est31 ok stats here http://pastebin.com/0r2FTfRv 09:09 Jasper Doesn't look very maintained, but it might be worth a shot. 09:09 celeron55 for one, minetest does implement the main loop itself 09:09 est31 for dreambuilder game 09:09 est31 which is quite large 09:09 Jasper est31, what is a .md 09:09 est31 .md is text doc 09:09 est31 markdown 09:09 Jasper OK. 09:09 Jasper So it uses .x and obj 09:12 celeron55 Jasper: irrlicht renders its scene with three calls; beginScene, drawAll and endScene; i guess if you remove skyboxes and everything from the scene and draw before drawAll leaving the Z buffer intact, you might get a useful result... but it might be that irrlicht's interface has to be extended for this 09:13 RealBadAngel i told ya 09:13 celeron55 Jasper: anyway, try it and report back; it just might work 09:14 Jasper Depends if I get time at work to actually work on this. 09:14 crazyR :( 09:14 Jasper How long do you think it would actually take? 09:15 Jasper My guess would be 1-2 months of off-and-on work. 09:15 Jasper celeron55, I think I would have to first hack up Irrlicht to always use OGL and never use D3D 09:15 celeron55 well, it depends how good you are 8) but i would consider that if you manage to replace *only* the voxel rendering with that, leaving irrlicht in place to do all the complex less performance intensive stuff alongside it, it's not a big task 09:15 Jasper I'd replace skybox rendering and GUI rendering too. 09:16 Jasper My goal here is pure GLES 09:17 RealBadAngel http://code.metager.de/source/xref/irrlicht/source/Irrlicht/CSceneManager.cpp#1380 09:17 RealBadAngel Jasper, i have rewrote skybox rendering already 09:17 Jasper In pure GLES? 09:17 RealBadAngel im doing them on my own with meshes just 09:17 RealBadAngel they have nothing to do with shaders 09:18 Jasper I have no idea why you keep bringing up shaders. 09:18 celeron55 Jasper: RealBadAngel usually just messes around with irrlicht, none of it is really applicable to what you want to do 09:18 Jasper OK. 09:18 RealBadAngel Jasper, you have said you gonna replace skybox rendering 09:18 celeron55 take a look at that code though, it's irrlicht's scene->drawAll which is interesting 09:18 RealBadAngel skybox is just a cube made out of 24 vertices 09:19 RealBadAngel shaders are not involved here 09:19 celeron55 Jasper: i really don't know how long it would take to do all that 09:19 celeron55 an infinite time for most people i'd think; it's not easy 09:19 celeron55 a shorter time if you know what you're doing 09:19 Jasper I mostly do. 09:20 Jasper Irrlicht doesn't even do a depth-prepass. 09:20 Jasper Jesus. 09:20 Jasper I didn't realize it would be *that* bad. 09:20 Jasper let's just throw all that early-Z out the window and shade everything 09:21 RealBadAngel celeron55, all i do care about is internal mesh format, if that will change it will be a mess 09:24 celeron55 Jasper: all i can say at this point is, try jamming in your modern stuff in there and see what happens; you don't have to do all the work as long as there is a base that can be built on 09:24 Jasper Yeah. 09:24 Jasper If I have some extra time this weekend I'll poke at it. 09:26 Jasper For reference, last week's weekend hack was http://magcius.github.io/zelview.js/zelview.html#ydan_scene!0.0060,0.0600,-3.6797,136.1472,590.6298 09:26 celeron55 some people might find it bad that directx support would go away, but i think it is necessary to drop it in the long term 09:26 celeron55 direct3d* 09:26 Jasper So I'm pretty used to writing these kinds of renders. 09:26 Jasper renderers 09:26 Jasper Yeah, I admit I haven't used D3D at all. 09:27 Jasper I just write OpenGL and OpenGL drivers :) 10:07 Calinou we do need to drop it, it's simply obsolete 10:07 Calinou SuperTuxKart did the same thing with their Antartica engine (fork of Irrlicht) 10:22 est31 when all your downstream projects start forking you, you clearly have done something wrong. 10:22 est31 or not done something 10:54 Calinou Irrlicht is mostly unmaintained now 10:56 Hunterz and have ugly bugs like https://github.com/minetest/minetest/issues/1898 10:56 Calinou maybe we should start supplying our own Irrlicht 10:56 Calinou based on 1.9-dev 10:58 est31 based on an unstable rendering engine? 11:00 est31 whatever, I'm no gfx guy, so we should do whatever people who know things think is best. 11:37 sfan5 est31: yes, i know that cmake can use nsis but i never bothered to tale a look at it 12:42 Elinvention what is the unit of measure of player speed? 12:43 Calinou Elinvention, nodes per second 12:43 Calinou default is 4 (walking), 1.35 (sneaking) 12:45 Elinvention if I call player->getSpeed() I get 40 and 13, so I guess it's 10x 12:45 Calinou yes it's Irrlicht units 12:45 Elinvention ok thank you 12:45 Calinou we use BS (BlockSize, even though celeron55 calls it "bullshit"), which is 10 Irrlicht units :) 12:45 Calinou 1 node is 1 BS 12:45 Calinou this is why coordinates may also be 10x 12:45 Calinou (in the C++ code, not in Lua API) 12:46 Elinvention I am trying to add get_player_velocity to lua api 12:46 Calinou players have no velocity server-side, you might have trouble 12:46 Calinou it probably won't work well, if at all 12:51 Elinvention I might be lucky it seems someone implemented server side speed because it works very well 13:09 Calinou does it work with several clients, on a dedicated server? 13:09 Calinou (not an in-client server) 13:11 AnotherBrick anybody had troubles with locale when minetest is compiled by MinGW? 13:12 AnotherBrick and by "troubles with locale" i mean 'Character conversion failed' when trying to chat in non-english 13:15 TeTpaAka related to #2574 13:15 ShadowBot https://github.com/minetest/minetest/issues/2574 -- Character conversion failed 13:18 AnotherBrick so, it's not related to mingw 13:52 est31 5 mins till push https://github.com/est31/minetest/commit/3376d2e114767eef06b87645edefcd2d42696919 15:34 kahrl https://forum.minetest.net/viewtopic.php?f=6&t=12675 15:34 kahrl this should no longer be a thing... 15:34 kahrl what happened to the PR that added prediction for node meta inventories? 16:52 Jasper Calinou, I didn't know SuperTuxKart was maintained, either 16:52 Calinou it still is, quite actively 17:00 Jasper Calinou, we ship that one too, and we also perhaps need a GLES port of it. 17:01 Jasper Calinou, do you know if STK's Irrlicht fork supports GLES? 17:02 Calinou no idea, unlikely 17:53 hmmmm I could've sworn SuperTuxCart dropped irrlicht 17:54 Jasper They forked it into a new engine, but it's still there. 17:54 Jasper https://github.com/supertuxkart/stk-code/tree/master/lib/irrlicht/source/Irrlicht 18:00 Calinou they call it Antarctica 19:05 twoelk could Antarctica be of any use for Minetest? 19:06 Jasper Probably not. 19:07 Jasper And the lead developer of Antarctica left the project because of some drama. 19:07 Jasper So it's also dead. 19:07 Jasper The big features are volumetric lights and deferred rendering, which we don't really need for our art style. 19:23 Calinou https://forum.minetest.net/viewtopic.php?f=18&t=11483&p=182764#p182764 19:23 Calinou do we support Android < 4.0? probably not 19:25 twoelk volumetric lights? There was the Eye Candy discussion a few weeks ago -> https://forum.minetest.net/viewtopic.php?f=5&t=12261 20:35 MinetestForFun Can you give your opinion about this please ? https://github.com/minetest/minetest/issues/2829 (i think it's an easy implemanted and very useful feature...) 20:41 asl97 it can be done easily, just edit the chatcommand.lua, if you need hint on how to do it, just look at another command that allow additional args like deleteblocks 22:10 paramat i discovered what was 'wrong' with mgv7 mountains. to stop them generating everywhere mountain noise had a negative offset, but doing this to 3D noise creates small fragmented volumes, mostly scattered floatlands. instead i added a negative offset to the modulating 2D mountain height noise. first test i get this http://i.imgur.com/0pAUrDZ.png more satisfying mountains with interesting structure and areas of rough hil 22:10 paramat ls, which mgv7 was lacking