Time Nick Message 00:41 Fixer RealBadAngel, mrt_5 is 40% slower than normal one 00:42 RealBadAngel paramat, est31 #3671 00:42 ShadowBot https://github.com/minetest/minetest/issues/3671 -- Use inventory_image in the first place for inventory item mesh by RealBadAngel 00:42 kaadmy huh 00:43 kaadmy i'm getting these messsages printed about 10 a second 00:43 rubenwardy Will this make inventory images appear in hand instead of weild meshes? 00:43 paramat ok 00:43 kaadmy 2016-02-07 16:42:47: WARNING[Main]: Irrlicht: Could not open file of texture: character.png 00:43 Fixer seen that 00:43 RealBadAngel Fixer, what is slower? 00:44 Fixer RealBadAngel, mrt_5 branch that i've compiled some days ago, with shaders and stuff 00:44 RealBadAngel can be ofc 00:44 Fixer did a very big testing this evening 00:45 RealBadAngel its almost complete deferred rendering chain + some heavy duty shaders effects 00:46 RealBadAngel final wont be much slower than that, theres not much more left to add there 00:48 RealBadAngel but also keep in mind thats still WIP, many things can change here 04:06 RealBadAngel hmmmm, here? 04:11 VanessaE clearly not :) 04:23 RealBadAngel or maybe? 04:24 hmmmm ?? 04:25 RealBadAngel hmmmm, ive updated #3662 04:25 ShadowBot https://github.com/minetest/minetest/issues/3662 -- Cleanup selection mesh code, add shaders for halo and selection boxes by RealBadAngel 04:25 hmmmm ok 04:26 hmmmm why did you change some of these video::SColors to const &? 04:26 hmmmm do you realize they're only 4 byte structures? 04:26 paramat http://i.imgur.com/U8Nd9u7.png 04:26 RealBadAngel nerzhul wants everything to be const & 04:27 hmmmm eh.... 04:27 hmmmm video::SColor doesn't need to be 04:27 hmmmm in fact I'd say it makes the code slower instead, and it's messier looking 04:27 RealBadAngel now youre saying? when ive put that on all pos, colors and everything around? 04:28 hmmmm I didn't know that you were going to do that or nerzhul was saying so 04:28 RealBadAngel not to mention endless testing if it still compiles and works 04:28 hmmmm I am not the same person as nerzhul 04:28 hmmmm if the code works as const &, it should work as not-const & 04:29 RealBadAngel btw that *& you mentioned. idk whats that and what for its made like this 04:29 hmmmm maybe it was a typo? 04:29 RealBadAngel ive just removed one parameter in that line, nothing more 04:29 hmmmm oh 04:30 hmmmm well somebody should fix that separately... 04:30 hmmmm why is the node selection part of hud? 04:30 RealBadAngel logical 04:30 hmmmm yes but the hud refers to the heads-up display 04:30 RealBadAngel turn off hud, you dont see selection 04:30 hmmmm i.e. the text and pictures right on the screen 04:30 hmmmm the 2d things 04:31 hmmmm i don't think the selection mesh should be part of that subsystem... 04:31 hmmmm when you turn off the hud, it'd turn off selection as well 04:31 hmmmm is this really what you want...? 04:31 RealBadAngel it was designed like that already 04:31 hmmmm but why 04:31 RealBadAngel and yes, we dont want selection when hud is off 04:31 hmmmm who's we 04:32 hmmmm what do others say about this?? 04:32 RealBadAngel everybody? 04:32 hmmmm and what about the wield tool? why is that disabled along with the hud now?? 04:32 RealBadAngel now? 04:32 RealBadAngel since always 04:32 RealBadAngel why you think ive changed the design? 04:32 hmmmm https://github.com/minetest/minetest/pull/3662/files#diff-3caa81f71bc3ee0838c9b7a1cfcfa6acL492 04:32 hmmmm not the design 04:33 hmmmm look, if (draw_wield_tool) ... is inside of if (show_hud) {. .. 04:33 hmmmm think long and hard about these design consequences 04:33 RealBadAngel hold on a sec 04:33 hmmmm are they actually how the players want minetest to behave? 04:33 hmmmm this is what's most important 04:34 RealBadAngel turning off hud turns off wielded and selection 04:34 RealBadAngel i havent changed that 04:34 RealBadAngel just run the game and see 04:34 hmmmm alright fine 04:34 hmmmm i hate having to load up minetest though 04:35 RealBadAngel go on, i did 04:35 hmmmm yeah but you're actually working on it, I'm not 04:35 hmmmm you still didn't fix the missing space in getPointedThing's declaration 04:36 RealBadAngel looks like you dont remember default behaviour just, you dont play too much, do you? ;) 04:36 RealBadAngel oops 04:37 hmmmm alright, you're right it isn't drawn 04:37 hmmmm and same with selection 04:37 hmmmm this isn't what I would have guessed, but as long as it doesn't change existing behavior on accident 04:38 hmmmm what the hell, getPointedThing() is a mess 04:38 hmmmm THIS is where cleanup is needed 04:38 hmmmm not logging or threading or whatever 04:39 hmmmm i also don't like this "f32 d" - wtf is 'd'? 04:39 hmmmm dong? 04:39 RealBadAngel lookin at me? ;) 04:39 RealBadAngel not mine 04:39 hmmmm but it's not your doing, this is something to be fixed another day 04:39 hmmmm i'm just going to note it and move along 04:40 hmmmm the D value is over 18 inches 04:40 RealBadAngel but i know whats that ;) 04:40 hmmmm also, RBA, you are welcome just as much as everybody else to clean up existing code 04:41 hmmmm for what it's worth, I especially enjoy commits that have more red than green in them 04:41 RealBadAngel slight offset to make lines visible and not mess with face surface 04:41 hmmmm that ^ is totally obvious if you are intimately familiar with the code and understand the convention of "D" 04:42 RealBadAngel but, wheres that space you said i havent fixed? 04:42 RealBadAngel cant see that 04:42 hmmmm PointedThing getPointedThing(Client *client,Hud *hud, const ... 04:42 hmmmm -----------------------------^ 04:42 hmmmm -------------------------------------^ 04:44 RealBadAngel awwwww 04:44 RealBadAngel 6 am, thats why ;) 04:44 hmmmm excuses aside 04:44 hmmmm what happens when tsrc->getTextureForMesh() fails? 04:45 hmmmm what does it return? 04:45 RealBadAngel cant fail 04:45 hmmmm why not 04:45 RealBadAngel it will generate fake one 04:45 RealBadAngel random colors 04:46 RealBadAngel that was made propably to prevent random crashes when you forget to supply texture or make a typo in its name 04:50 hmmmm mmm 04:50 hmmmm the ternary operator was supposed to be in the parameter list like so 04:51 hmmmm u16 shader_id = shdrsrc->getShader(mode == "halo" ? "selection_shader" : "default_shader", 1, 1); 04:52 hmmmm the idea behind that is to cut down on repetitive code 04:52 hmmmm in general it's bad to repeat yourself because it puts a greater mental strain on future developers to remember to change every instance of the repetition 04:52 hmmmm and more likely to make a mistake 04:53 hmmmm anyway, isn't there a Settings::getEnum()? 04:53 hmmmm huh guess not. 04:53 RealBadAngel i havent thought to code it that way, thats indeed better 04:54 hmmmm also I'm not saying this is something to be done right now, but in the future it would be HIGHLY APPRECIATED to start using constants in place of numeric literals for texture layer numbers 04:55 hmmmm only people who work with the graphics a lot know that 0 is the main texture, 1 is something else, 2 is an options texture to be passed along to the shader, etc. 04:55 RealBadAngel thats not any general rule 04:56 hmmmm does it really need to be a rule in order for you to do it? 04:56 hmmmm doesn't it intuitively make sense why this is a good thing? 04:56 RealBadAngel i mean what which layer is 04:56 hmmmm right and this is a cause for confusion 04:56 RealBadAngel thats not a rule 04:56 hmmmm maybe there should be a general rule 04:56 hmmmm or at least a piece of documentation somewhere 04:56 hmmmm /************** 04:57 RealBadAngel in fact in each material each layer is something different 04:57 hmmmm * Shader texture positions for : 04:57 hmmmm * 0 - This is the main texture 04:57 hmmmm * 1 - This is the whatever texture 04:57 hmmmm so on 04:57 hmmmm do you not see how that could be helpful at all...? 04:57 RealBadAngel hold on 04:58 hmmmm source code does not need to be a cryptic, secret code 04:58 RealBadAngel https://github.com/minetest/minetest/blob/master/src/game.cpp#L872 04:59 hmmmm uhhhm 04:59 hmmmm is it just me or is that code completely faulty? 05:00 hmmmm the memory layout of an integer with the value of "1" is not the same as the memory layout of a float with the value of "1.f" 05:00 RealBadAngel whats wrong with it? 05:01 hmmmm that code doesn't smell right at all 05:01 RealBadAngel hm, i havent thought bout it, the code was propablty copied from some irrrlicht example 05:02 RealBadAngel but i saw it being used in many irr apps 05:02 hmmmm well, I'd take a closer look 05:02 hmmmm it could be the source of bugs 05:02 RealBadAngel possible 05:03 RealBadAngel in fact im fighting with something that could be related 05:03 hmmmm right 05:03 hmmmm so listen 05:04 hmmmm I think what that code is trying to do is use the overloaded f32 * version of that function for older irrlichts 05:04 RealBadAngel thx for pointing it out, because it can be really the reason for textures going nuts when i use MULTIPLE shaders 05:04 hmmmm the int layer2 = 2; ... declares and initializes an integer variable with the integer value of 2 05:04 hmmmm the address of that is 0x59405405945 or whatever 05:05 hmmmm now, that ADDRESS is casted to an irr::f32 * without any conversion, because on the x86 architecture at least, you don't need to perform any conversion for different pointer types 05:05 hmmmm so the actual underlying value of "2" is not converted to a floating point "2.f" 05:06 hmmmm in any case, why did you show me this block of code? 05:06 RealBadAngel to show that layers are actually described here 05:06 RealBadAngel by respective uniform sampler names 05:06 hmmmm inside of a random chunk of code? 05:07 hmmmm what are the odds that somebody will actually stumble across that 05:07 hmmmm it needs to be way more visible 05:07 RealBadAngel its general shaders callback 05:07 hmmmm so? 05:07 RealBadAngel where else could it be? 05:07 RealBadAngel if not here, then api 05:07 hmmmm somebody who isn't familiar with the graphics code wouldn't know that 05:07 hmmmm it's not impossible to figure out 05:08 hmmmm but it requires a higher mental load to figure it out 05:08 hmmmm why would you make somebody work harder to understand a piece of your code? 05:08 hmmmm it's not just for you, i hope you realize, it's for everybody 05:09 RealBadAngel do you realize that this demand to comment out setting each texture is kinda absurdly? 05:09 hmmmm how is it absurd? 05:09 hmmmm jeez, you know what, I'll do it if you don't want to 05:09 hmmmm clear, easy-to-understand, maintainable code 05:10 RealBadAngel im not talking about it being clear or something 05:10 RealBadAngel im talking bout that you want commenting out obvious thing being done hundreds of times in the engine 05:11 hmmmm make it self documenting then, by using a constant 05:11 hmmmm instead of writing "1", write "TEX_LAYER_BASE" 05:11 hmmmm or rather 0 05:11 hmmmm TEX_LAYER_NORMAL in place of 1 05:11 hmmmm see? 05:12 RealBadAngel that would mean another PR that introduce that method and use it everywhere 05:12 hmmmm yeah, so? 05:12 RealBadAngel so out of scope of my PR 05:12 hmmmm yes, I know that 05:12 RealBadAngel but indeed good idea for the future 05:12 hmmmm I mentioned earlier "By the way, this is something that would be nice to do ..." 05:12 RealBadAngel ok, i will code that 05:12 hmmmm [11:54 PM] also I'm not saying this is something to be done right now, but in the future it would be HIGHLY APPRECIATED to start using constants in place of numeric literals for texture layer numbers 05:13 RealBadAngel ok ok, ack 05:13 hmmmm okay, back to the PR 05:13 RealBadAngel since im messing all around now with renderer i can easily code it btw 05:14 RealBadAngel whats next? 05:14 hmmmm nothing yet I just want to make a note of something 05:15 hmmmm when to use const & vs. 05:15 RealBadAngel that could be said once for all and just used 05:15 hmmmm prefer const & when you want to pass along a value without copying it, i.e. when creating a copy would be costly 05:15 hmmmm const v3f &? I can see the argument for that 05:15 hmmmm sizeof(v3f) == 16 05:16 hmmmm 8 < 16 05:16 hmmmm in practically every case it'd be more efficient to use const v3f & 05:16 hmmmm const MapNode &? 05:16 hmmmm not so much 05:16 hmmmm sizeof(MapNode) == 4 05:16 RealBadAngel what about const boxes & ? 05:17 hmmmm a pointer is either going to be 4 or 8 so it's not worth it to pass along to a constant 05:17 hmmmm a box is 4 floats, right? 05:17 RealBadAngel iterators fail on that 05:17 hmmmm so that's at least 16 bytes 05:17 RealBadAngel see comment in PR with error 05:18 hmmmm use const_iterator 05:21 hmmmm if a compile error is preventing you from doing something that you should be doing, try to figure out why and fix that, instead of shrugging your shoulders and moving along to the next thing 05:24 RealBadAngel using consts wasnt my goal there 05:24 RealBadAngel i was in that function with small visit btw 05:25 hmmmm in modern minetest code, non-const reference parameters are prohibited 05:25 hmmmm there is a good reason behind this... 05:26 RealBadAngel ok, i can understand that, but i cannot alter code everywhere because im just close to it 05:26 hmmmm it requires adding literally 6 characters 05:26 hmmmm come on 05:26 hmmmm type "const_" 05:27 RealBadAngel it ends up with asking me whats that *& 05:27 hmmmm this is a parameter YOU added 05:27 RealBadAngel no 05:27 RealBadAngel it was here 05:28 hmmmm we're talking about 'boxes' in convertNodeBoxesToMesh, are we not? 05:28 RealBadAngel yeah, just slight offtopic 05:28 RealBadAngel im trying now to change it 05:28 hmmmm well, I won't +1 the code unless this shit is fixed 05:28 hmmmm just fix it, come on.. 05:28 hmmmm i gave you the reason why it won't compile and how to fix it 05:28 hmmmm it requires adding a 6 character string 05:29 hmmmm this is really easy 05:30 RealBadAngel i said im compiling it now 05:32 RealBadAngel ok, const_iterator work 05:33 RealBadAngel pushed 05:33 RealBadAngel anything more? 05:33 hmmmm i haven't gone through everything yet 05:34 hmmmm and still with the f32 *txc 05:34 hmmmm god dammit RBA 05:34 hmmmm okay first of all, is txc modified at all? 05:35 RealBadAngel i told you i havent changed it but put extra comments on it 05:35 hmmmm what's wrong with what I proposed earlier? 05:35 RealBadAngel absurdly long lines 05:35 hmmmm change the name of the parameter, and then use a local variable "txc" for shorthand 05:36 hmmmm this is not an absurdly long line 05:36 RealBadAngel ok, that i can do 05:36 hmmmm you're only modifying *one* line 05:36 hmmmm change f32 *txc to f32 *node_texture_coords or something 05:36 hmmmm then right before you start using txc 05:36 hmmmm add f32 *txc = node_texture_coords; 05:37 RealBadAngel http://pastie.org/10713042 05:38 RealBadAngel before i did that 05:38 RealBadAngel but as you wish 05:38 hmmmm keep that comment too 05:38 hmmmm also I like how you wrote [24] 05:39 hmmmm now finally, are any elements of "txc" modified by convertNodeboxesToMesh? 05:39 RealBadAngel no 05:39 hmmmm then maybe you should make that clear in your code by adding a const modifier 05:40 hmmmm const f32 * 05:45 RealBadAngel table cant change in function, but im not passing a table 05:45 RealBadAngel im passing a pointer, which can change 05:45 hmmmm right, do you know what const f32 * means? 05:46 hmmmm what is the thing that's constant? 05:46 RealBadAngel that i cant alter it 05:46 hmmmm the variable's value, or the value of the f32 being pointed at? 05:46 hmmmm which one? 05:46 RealBadAngel the pointer itself 05:46 hmmmm nope 05:47 hmmmm f32 foobar = 5.f; const f32 *foobarp = NULL; foobarp = &foobar; 05:47 hmmmm now try *foobarp = 2.f; 05:47 RealBadAngel i dont wanna change whats being pointed 05:47 hmmmm correct 05:47 RealBadAngel im changing the pointer itself 05:48 hmmmm const f32 * does what you want 05:48 RealBadAngel and const just forbids me to change the pointer 05:48 hmmmm f32 const * does what you're talking about 05:48 hmmmm const f32 * forbids you from changing the values that the pointer is pointing at 05:49 hmmmm const f32 const * does both 05:52 RealBadAngel http://pastie.org/10713050 05:53 hmmmm dammit no 05:53 hmmmm const f32 * 05:53 hmmmm then change f32 *txc = ... to const f32 *txc = ... 05:57 RealBadAngel if i define const f32 *txc = uv_coords; 05:58 RealBadAngel and wanna try later on change it? txc = txc_default 05:58 hmmmm that's fine 05:58 RealBadAngel logically const here should mean i cannot change it 05:59 hmmmm no, dammit 05:59 hmmmm I already explained this 05:59 hmmmm const before a "type *" means that the underlying values being pointed at are the constant things 05:59 hmmmm const between type and the * means that the pointer cannot be changed 05:59 hmmmm here, let me show an example 06:00 RealBadAngel ah now i get it 06:00 hmmmm you have an int foobar[] = {1, 2, 3}; 06:00 hmmmm now you don't actually intend to modify foobar 06:00 hmmmm you just need to pass it along to a function so it know which foobar values to use 06:00 RealBadAngel ok, i got it 06:00 hmmmm so you define int foo(const int *TheFoobar); 06:00 hmmmm foo(foobar); 06:01 hmmmm inside of foo you might have 06:01 hmmmm int a = TheFoobar[0]; 06:01 hmmmm that's fine 06:01 hmmmm TheFoobar = SomeDefaultFoobar; also works fine 06:01 hmmmm but when you try to do 06:01 hmmmm TheFoobar[0] = 5; 06:01 hmmmm that's going to fail compilation 06:01 hmmmm get it? 06:01 RealBadAngel yeah 06:01 RealBadAngel pushed changed code 06:02 hmmmm fantastic 06:02 hmmmm now one last thing with that function 06:02 hmmmm the use_default_txc - this is totally unnecessary 06:03 hmmmm why not replace that line with: 06:03 hmmmm no 06:03 hmmmm const f32 *txc = uv_coords ? uv_coords : txc_default; 06:03 hmmmm and move the definition of txc_default before it 06:03 hmmmm and make txc_default a static const too 06:04 RealBadAngel default is calculated per box 06:05 RealBadAngel you can have shitload of boxes passed in 06:05 hmmmm I don't get what you mean 06:08 RealBadAngel i need to pass there some complex nodes with more than 1 box to check it 06:09 hmmmm yeah but I don't get how that has to do with what I recommended... 06:11 RealBadAngel i get what you mean, ok 06:12 RealBadAngel but now i would need to predefine txc_default pointer 06:12 hmmmm so what? the way it is right now, that array will get filled with constant values every time that loop is run 06:12 RealBadAngel and then how the heck im supposed to define the table? 06:12 hmmmm unless it gets optimized somehow 06:13 hmmmm with a static const it'll only get filled once and never again 06:13 hmmmm and you can be sure of that by the standard of the language 06:13 RealBadAngel its not static 06:13 RealBadAngel it gets calculated per each box 06:13 hmmmm ohh wait a minute 06:14 hmmmm hold up 06:14 hmmmm you're right it does 06:14 hmmmm okay, you can't make it static const then 06:14 RealBadAngel also if i define pointer before, im not allowed to create a table 06:14 hmmmm I see 06:15 RealBadAngel unless i set specific compiler options 06:15 hmmmm you want to use that array initialization syntax 06:15 hmmmm but it varies for each loop 06:15 RealBadAngel yeah 06:15 hmmmm so you declare it inside of the loop 06:15 hmmmm why not move the const f32 *txc = ... inside of the loop, then? 06:16 hmmmm it takes just as much cpu power as what your code currently does 06:18 RealBadAngel that works 06:18 RealBadAngel lemme just check multiple boxes 06:19 hmmmm and you reduced your code by 3 lines too 06:19 hmmmm isn't that a win? 06:20 RealBadAngel ive cut more like 50 after those comments already 06:20 RealBadAngel i was coding it for both cases using mesh and textures before 06:20 RealBadAngel so thats why there were different scales etc 06:21 RealBadAngel now ive cleaned all those remains 06:21 RealBadAngel pity that we cant texture the simple boxes and have then such thin lines equally visible 06:22 RealBadAngel i kinda liked textured ones 06:22 RealBadAngel like this one for example: https://cloud.githubusercontent.com/assets/2177790/12862216/ba648e94-cc69-11e5-89d2-fdef378cb6eb.png 06:23 RealBadAngel anyway, theres no 100% good code from the start, also man is learning whole life and dies stupid ;) 06:23 RealBadAngel thx for all those clues 06:27 RealBadAngel rebased all those updates, need now to check if everything works as it should 06:27 hmmmm some more minor things 06:27 hmmmm https://github.com/minetest/minetest/pull/3662/files#diff-70868aa6d6b96c0c1623c761500d23c4R975 06:27 hmmmm does convertNodeboxesToMesh(...) really need to be on a separate line? 06:28 RealBadAngel it was too long before 06:28 hmmmm it seems like it's 74 columns if it's put onto the same line 06:29 hmmmm that's well within the acceptable length limits 06:29 RealBadAngel but i added txc = NULL in def , and then removed , NULL from call 06:29 RealBadAngel now it does fit the 80 06:29 hmmmm note that 80 is not a hard limit 06:29 hmmmm 90 is the hard limit 06:29 hmmmm it's just preferred to keep it 80 or smaller if you can help it 06:30 RealBadAngel i just forgot to put it back into one line after removing , NULL from call 06:30 RealBadAngel anythin more? 06:30 hmmmm yes 06:31 hmmmm in Hud::updateSelectionMesh you have two if statements that are the exact same thing 06:33 RealBadAngel you mean dropping old mesh? 06:33 hmmmm yes 06:35 RealBadAngel ok, fixed, whats next? 06:36 hmmmm you never answered me before about why you have m_camera_offset = camera_offset everywhere 06:36 hmmmm is m_camera_offset ever read in a function without a camera_offset parameter? 06:37 RealBadAngel yes 06:37 hmmmm okay then 06:37 RealBadAngel i have to add offset to mesh coords just before displaying it 06:38 hmmmm and another thing 06:38 hmmmm unless I'm mistaken, every single frame, the selection mesh is copied and then freed 06:38 hmmmm is there a more efficient way to do this? 06:39 RealBadAngel i think not, mesh is updated only when pointed thing changes 06:39 RealBadAngel not on every frame 06:40 hmmmm but I see hud.drawSelectionMesh() drawn in draw_* 06:40 hmmmm isn't that called every frame? 06:40 RealBadAngel draw is done each frame 06:41 hmmmm right 06:41 hmmmm so that means the mesh is cloned translated and dropped each frame 06:41 hmmmm but this only needs to be done inside of setSelectionPos(), no? 06:42 RealBadAngel cloned yes 06:42 RealBadAngel but not created 06:42 hmmmm that's still a deep copy of each mesh buffer 06:42 RealBadAngel no 06:42 RealBadAngel it copies vertices only 06:42 hmmmm okay then 06:42 RealBadAngel without materials 06:42 hmmmm still unnecessary copying 06:42 RealBadAngel i have to 06:42 hmmmm and what about indicies 06:43 RealBadAngel i need to apply new colors 06:43 RealBadAngel they do change with daytime and halo fluctuations 06:43 hmmmm yeah i see that 06:43 hmmmm in getPointedThing() 06:44 RealBadAngel once i apply new colors i cannot reuse it 06:44 hmmmm ugh 06:44 hmmmm well it shouldn't be too bad as long as the mesh isn't overly large 06:44 hmmmm or complicated 06:44 RealBadAngel its single mesh anyway 06:44 RealBadAngel its also now way faster than before 06:45 RealBadAngel whole damn mapblock 06:45 hmmmm that was ridiculous 06:45 RealBadAngel cracks are too 06:45 RealBadAngel next step will be those cracks 06:46 RealBadAngel harder to make but in general same way as with halo 06:47 RealBadAngel and btw, thats why we do have cloneMesh here, for speed sake 06:47 RealBadAngel irrlicht one was copying materials too 06:48 hmmmm yea 06:48 hmmmm good thing we don't 06:54 RealBadAngel ok, pushed recent changes 06:54 RealBadAngel anything left? 06:55 hmmmm one nitpick 06:55 hmmmm in updateSelectionMesh, since you're returning right after the selection boxes size check, why have the rest of the function in an else statement? 06:56 hmmmm you can save a line of code and a level of indentation by removing it 06:57 RealBadAngel now thats true 06:59 RealBadAngel done 07:01 hmmmm +1 07:01 RealBadAngel not yet 07:02 RealBadAngel we have missed one thing 07:02 RealBadAngel halo colors doesnt have to be calculated in case of boxes used 07:03 RealBadAngel neither the light level 07:03 RealBadAngel but wait a sec 07:04 RealBadAngel if you specify white boxes in non modified game, arent they fully visible in complete darkness even? 07:04 RealBadAngel need to check that 07:04 RealBadAngel if they are, colors are needed for boxes too 07:08 RealBadAngel hmmmm, http://i.imgur.com/xGTSYcI.png 07:08 RealBadAngel i consider it to be a bug 07:08 hmmmm oh, that's swell.. 07:09 hmmmm i don't think there's a way out of this without querying the surrounding 6 nodes' light levels 07:11 RealBadAngel there isnt, but look at the screenie 07:12 RealBadAngel thats "before" 07:12 RealBadAngel if you set boxes color to white, its visible no matter how dark is around 07:12 RealBadAngel halo responds to light level, so its not visible in complete darkness 07:12 RealBadAngel imho i shall apply the same to boxes 07:13 RealBadAngel that "feature" wasnt just visible with default black lines 07:27 RealBadAngel hmmmm, what do you think about it? 07:27 hmmmm i don't really have an opinion 07:27 hmmmm it needs to be fixed 07:27 RealBadAngel easily now, just multiply boxes colour by vertex colour calculated for mesh 07:28 RealBadAngel but then color calculations have to stay no matter method used 07:34 RealBadAngel damn, SColors cannot be multiplied 08:20 RealBadAngel hmmm, ok fixed the issue with box colors 08:21 RealBadAngel http://i.imgur.com/XluQXAJ.png 08:21 RealBadAngel so the "cheat" is gone 08:33 hmmmm selection meshes are already shaded according to the background? 08:33 RealBadAngel yeah 08:33 RealBadAngel i did the same with boxes now 08:33 RealBadAngel you wont notice any difference with black ones ofc 08:34 RealBadAngel but if you set it to white, effective color will depend on surroundings 08:34 hmmmm oh that was a simple solution 08:35 RealBadAngel just theres no color*color in irrlicht, funny 08:36 hmmmm what does color * color even mean 08:36 hmmmm cross product? 08:36 hmmmm inner product? 08:36 hmmmm something else? 08:36 RealBadAngel blending colours 08:36 RealBadAngel + would be additive blending 08:37 hmmmm https://en.wikipedia.org/wiki/Blend_modes#Simple_arithmetic_blend_modes 08:37 hmmmm ? 08:37 hmmmm Divide? 08:39 RealBadAngel https://en.wikipedia.org/wiki/Blend_modes#Multiply 08:39 RealBadAngel thats what im using 08:39 hmmmm oh derp 08:40 hmmmm "Multiply blend mode multiplies the numbers for each pixel of the top layer with the corresponding pixel for the bottom layer. The result is a darker picture." 08:40 hmmmm are each of these floating point values ranging from 0.0 to 1.0? 08:40 RealBadAngel yes 08:40 hmmmm i guess that'd work 08:41 hmmmm when i looked at that code I thought it was the actual pixel intensity value 08:41 RealBadAngel well, in range 0 -255 (we do use SColor here) 08:41 hmmmm ahh 08:41 RealBadAngel SColorf would be 0 - 1.0 08:41 hmmmm okay nevermind, that answers my question 08:42 hmmmm i was mistaken in thinking that'd cause an integer truncation 08:42 hmmmm looks good to me, then. 08:44 RealBadAngel ok, squashed again 08:44 RealBadAngel seems to be complete right now 08:46 hmmmm aren't you going to push it to upstream? 08:49 RealBadAngel mine upstream? 08:49 hmmmm upstream upstream 08:51 RealBadAngel PR is squashed and rdy 08:51 nrzkt RealBadAngel, link ? 08:51 RealBadAngel https://github.com/minetest/minetest/pull/3662/files 08:52 hmmmm oh, you don't have access anymore do you 08:52 hmmmm i forgot about the time you ragequitted 08:52 RealBadAngel lol 08:52 RealBadAngel thats why i couldnt understand what u are talkin about ;) 08:52 hmmmm i'll push it for ya ol buddy ol pal 08:54 RealBadAngel okay, one next thing solved for deferred rendering 08:54 hmmmm you have a merge conflict with upstream mine 08:54 RealBadAngel ouch 08:54 RealBadAngel hud? 08:54 red-001 nrzkt could you reconsider your -1 for #3657 ? 08:54 ShadowBot https://github.com/minetest/minetest/issues/3657 -- Allow players to drop unknown items and add a setting to remove them on drop. by red-001 08:55 RealBadAngel ofc its hud, inventory meshes 08:57 RealBadAngel i thought ive rebased it? 08:57 Gael-de-Sailly bug with node highlighting: http://i.imgur.com/YOakPa5.png 08:57 Gael-de-Sailly beautiful but not normal 08:58 hmmmm nice 08:58 RealBadAngel Gael-de-Sailly, have you compiled #3662 ? 08:58 ShadowBot https://github.com/minetest/minetest/issues/3662 -- Cleanup selection mesh code, add shaders for halo and selection boxes by RealBadAngel 08:59 Gael-de-Sailly i don't know, that's daily builds PPA 08:59 Gael-de-Sailly that's not merged so, no. 09:00 Gael-de-Sailly trying now 09:00 RealBadAngel i thought youre testing the code we have discussed atm 09:01 RealBadAngel anyway im pretty suprised with that bug screenie, havent heard about any errors with it before 09:01 hmmmm i can't reproduce it 09:01 RealBadAngel and the halo code is here for quite a long time 09:03 RealBadAngel hmmmm, so shall i rebase the PR or you can apply it somehow? 09:03 hmmmm i fixed it 09:04 RealBadAngel thx 09:05 RealBadAngel hmmmm, so, theres a small hotfix needed 09:05 hmmmm ugh what 09:05 RealBadAngel not for this one 09:05 RealBadAngel hold on 09:06 RealBadAngel #3671 09:06 ShadowBot https://github.com/minetest/minetest/issues/3671 -- Use inventory_image in the first place for inventory item mesh by RealBadAngel 09:06 nrzkt red-001, i commented a little thing, else +1 09:06 RealBadAngel i need to remove wield_inventory from here at all 09:06 RealBadAngel wield_image i mean 09:07 Gael-de-Sailly no node highlighting 09:08 hmmmm what about the thing that rubenwardy said about it? 09:08 Gael-de-Sailly i have the black line 09:08 Gael-de-Sailly but in minetest.conf, node highlighting is active 09:09 RealBadAngel Gael-de-Sailly, setting has changed 09:09 hmmmm wieldmesh isn't used at all? 09:09 hmmmm wield image i mean 09:09 RealBadAngel use config menu, under Basic 09:10 RealBadAngel hmmmm, looks like it shouldnt be used for inv at all 09:10 hmmmm getItemMesh is only used for inventory? 09:10 RealBadAngel yes 09:10 hmmmm but it's in wieldmesh.cpp 09:11 RealBadAngel becase it is using its methods 09:11 hmmmm totally obvious 09:11 hmmmm ugh 09:11 hmmmm okay, so does the wieldmesh use getExtrudedMesh then? 09:12 RealBadAngel i plan to unify that later on 09:12 RealBadAngel so both inventories, and hand will be using same meshes 09:12 hmmmm i'd rather wait for others to verify the expected behavior 09:12 hmmmm i don't know how to test this 09:13 RealBadAngel if youre able to see inventories that means it is working 09:13 Gael-de-Sailly node highlighting works 09:13 Gael-de-Sailly the halo is much darker. normal? 09:13 hmmmm alright, fine 09:14 hmmmm will you squash? 09:14 RealBadAngel only screwed thing was using wielded here 09:14 RealBadAngel Gael-de-Sailly, yes i have fine tuned it 09:14 RealBadAngel it was barely visible on bright surfaces 09:14 RealBadAngel hmmmm, a sec 09:15 RealBadAngel done 09:16 RealBadAngel Gael-de-Sailly, with bloom on snow you couldnt actually see it at all 09:17 RealBadAngel now its a bit darker and pulsation is made a bit more visible 09:17 hmmmm wow water nodes in the inventory are very bright 09:18 RealBadAngel hmmmm, minetest game shall remove now all inventory_cube uses 09:18 RealBadAngel engine will render real meshes instead of flat images 09:19 hmmmm ehh 09:19 hmmmm the new wielditems stick out more 09:19 hmmmm is this the way it's supposed to be? 09:19 RealBadAngel wield item? 09:19 hmmmm the wielded item 09:20 RealBadAngel that i havent touched, you must be mistaken 09:20 RealBadAngel mesh changes are about inventories 09:21 hmmmm http://imgur.com/a/VekRJ 09:21 RealBadAngel turn on inventory items animations to see what ive changed 09:21 hmmmm the top is with your commit 09:21 hmmmm the bottom is without 09:22 RealBadAngel i can see snow darker too 09:22 RealBadAngel havent time of day changed? :) 09:22 hmmmm yeah by like 5 seconds 09:23 hmmmm but seriously look at the difference in length between the two wieldmeshes 09:23 hmmmm what is up with that 09:23 RealBadAngel my code havent changed wielded at all 09:23 hmmmm durr 09:23 RealBadAngel i will make build before and after 09:23 hmmmm this is just a magic trick then, right? 09:23 RealBadAngel and compare 09:23 hmmmm ; 09:23 hmmmm :\ 09:24 RealBadAngel propably :) 09:24 RealBadAngel hold on, need to build it 09:24 Niebieski Why the shovel icon looks to the left on one pic and to the right on the other ? 09:25 hmmmm in the bottom image, the inventory mesh is actually the wield mesh 09:25 hmmmm the top is the correct one i think 09:26 RealBadAngel Niebieski, enabled inventory animations 09:26 RealBadAngel selected items do spin around 09:27 Niebieski Oh, well done. 09:28 RealBadAngel hmmmm, but despite using same extrusion cache, meshes are kept separate for both wielded and inventories 09:29 RealBadAngel my code havent messed a bit with wielded 09:32 hmmmm maybe, just maybe, the wieldhand code is using getItemMesh 09:33 RealBadAngel no its not 09:33 hmmmm both getInventoryTexture and getWieldMesh use getClientCached 09:34 RealBadAngel that i modified 09:34 hmmmm in that PR? 09:34 hmmmm that PR only modifies one line 09:34 RealBadAngel no 09:34 hmmmm did you modify it again 09:34 RealBadAngel its the one which made inventories using meshes 09:35 hmmmm i'm talking about 3671 09:35 hmmmm all 3671 does is removes the wield_image check from getItemMesh 09:35 RealBadAngel https://github.com/minetest/minetest/commit/6cd2b3b445bf558fda1e5a7908adef8e3a45449a 09:35 hmmmm but getItemMesh is used in createClientCachedDirect 09:35 hmmmm which is used in getClientCached 09:36 hmmmm which is used in both getInventoryTexture and getWieldMesh 09:36 hmmmm ergo the wieldhand and inventory are using the same mesh 09:36 hmmmm and 3671 just changes that so they're both using the inventory mesh instead of the wield mesh 09:36 RealBadAngel no 09:37 RealBadAngel youre wrong 09:37 hmmmm where 09:37 hmmmm also i've gotta go 09:37 RealBadAngel wield hand is not using client cached 09:37 hmmmm seriously 09:37 RealBadAngel ofc not 09:37 RealBadAngel since long time ago 09:37 hmmmm ?? 09:37 hmmmm look at itemdef.cpp getWieldMesh 09:37 hmmmm ohhhhhh 09:38 hmmmm wohops 09:38 hmmmm nevermind that then 09:38 RealBadAngel that was some old stuff 09:38 hmmmm nvm i missed something 09:38 RealBadAngel kahrl when made wieldmesh scene node made that code obsolete 09:38 hmmmm both of them use clientcached but they access different members 09:38 RealBadAngel ehhhh 09:39 RealBadAngel wield hand is not using client cached at all 09:39 hmmmm seriously g2g 09:39 RealBadAngel nor texture or mesh 11:22 red-001 what is the reason for mods not being able to use aysnc? 16:28 RealBadAngel hmmmm, ive compared colors before (a few commits behind) and current one: http://i.imgur.com/5sSib3x.png 16:29 RealBadAngel none of the last commits could cause that change as i saw in your screenshot imho (do note that you had overall darker world, not only wield mesh) 16:33 RealBadAngel also, #3671 is good to go 16:33 ShadowBot https://github.com/minetest/minetest/issues/3671 -- Use inventory_image only for inventory item mesh by RealBadAngel 16:36 Obani RealBadAngel, your feature of items turning in inventory is really cool ) 16:36 RealBadAngel thx 16:37 red-001 obani !title https://github.com/minetest/minetest/pull/3657 16:37 red-001 !title https://github.com/minetest/minetest/pull/3657 16:37 ShadowBot red-001: Allow players to drop unknown items and add a setting to remove them on drop. by red-001 · Pull Request #3657 · minetest/minetest · GitHub 16:37 Obani red-001, ? 16:37 Obani Also weren't you told to stop acting like this for your PRs ? 16:37 Obani :p 16:38 red-001 ? 16:38 red-001 I don't recall 16:40 RealBadAngel #3612 is also good to go 16:40 ShadowBot https://github.com/minetest/minetest/issues/3612 -- Filmic HDR tone mapping by RealBadAngel 16:41 RealBadAngel now its time to make sky, player and item nametags rdy for deferred rendering too 16:41 RealBadAngel and that should be all the obstacles 16:42 RealBadAngel maybe i will fix and cleanup cracks before introducing new renderer 16:43 RealBadAngel that shouldnt be that hard since i already did almost the same with halo 16:45 RealBadAngel i really would drop them and use particles and fading halo instead but i feel that force is strong with those cracks ;) 16:48 red-001 RealBadAngel so are you planning to add shadow? 16:48 RealBadAngel shadows? 16:48 red-001 yes 16:48 RealBadAngel ofc 16:49 RealBadAngel i do have SSAO workin, later on maybe something better 16:50 RealBadAngel with real renderer many things will be possible 16:51 RealBadAngel well, i dont say that what we have its not real in fact 16:51 RealBadAngel that will stay as default for non-shader version 16:51 RealBadAngel simply the new one will be far better 16:52 RealBadAngel allowing almost everything we could imagine to have 16:53 red-001 that sounds awesome 16:53 RealBadAngel you propably saw some screenies from WIP branch 16:53 RealBadAngel those were just a teaser 16:55 RealBadAngel and tests shows that we gonna be way faster than other games with similar quality 16:56 RealBadAngel if on my box terasology is a slideshow (10-15fps) and i get 60 fps, that speaks for itself 16:56 RealBadAngel not to mention mc with SEUS 16:57 RealBadAngel also soon im gonna get occulus, that will be FUN :) 16:57 red-001 SEUS? 16:58 RealBadAngel Sonic Ether Unbeliveable Shaders (or something like that) 16:59 RealBadAngel google for "minecraft SEUS" and images 17:04 red-001 RBA in cel shading mode the hand is drawn normally 17:04 red-001 could the wuild 17:04 red-001 nvm 17:05 RealBadAngel i dont think that hand should be cel shaded 17:05 red-001 why? 17:05 RealBadAngel but thats doable ofc 17:05 RealBadAngel idk, just thought so 17:06 red-001 it looks a bit strange to me 17:06 RealBadAngel atm im trying to get rid of more strange lookin things that are shaded and shouldnt 17:06 RealBadAngel makin one to be shaded is way simpler than that ;) 17:07 RealBadAngel selection, sky have to be able to write depth (selection can now) 17:07 RealBadAngel nametags should become part of hud 17:08 RealBadAngel clouds cant also write the depth 17:10 red-001 what's the reason behind mods not being able to use async? 17:11 red-001 main menu has async 17:11 RealBadAngel no idea, not my department 17:14 kaadmy RealBadAngel: any info about progress on SSAO? 17:15 RealBadAngel kaadmy, atm im removing all the obstacles to make renderer and PP working flawlessly 17:15 RealBadAngel i have to 17:15 kaadmy ok ;) 17:16 kaadmy good luck 17:16 RealBadAngel when i solve all the issues i can focus on details like lighting, specific effects etc 17:17 RealBadAngel and yes, lighting will become small detail then 17:18 RealBadAngel ssao for example is far more complicated than that 21:36 kahrl made a new PR: #3673 21:36 ShadowBot https://github.com/minetest/minetest/issues/3673 -- Add '/clearobjects quick' by kahrl 21:36 kahrl comments/reviews welcome 21:54 Krock kahrl, code looks good 21:55 paramat any comments/reviews for #3649 ? 21:55 ShadowBot https://github.com/minetest/minetest/issues/3649 -- FindSpawnPos: Let mapgens decide what spawn altitude is suitable by paramat 21:57 Fixer https://forum.minetest.net/viewtopic.php?f=3&t=14023 did few tests, I hope I have not missed anything 21:58 paramat #3671 seems well tested so +1, anyone else want to approve? 21:58 ShadowBot https://github.com/minetest/minetest/issues/3671 -- Use inventory_image only for inventory item mesh by RealBadAngel 21:59 paramat Fixer i'm concerned about alledged extra stutter when shaders are disabled 21:59 Fixer paramat, yeah, I made some graphs about that, it is strange thing 21:59 paramat perhaps it should be better due to no vertextangents? < RealBadAngel 22:01 Fixer paramat, i got 0-2% fps loss with that tangents patch %) 22:01 Fixer paramat, when shaders are disabled 22:01 Fixer paramat, https://cloud.githubusercontent.com/assets/16494741/12893390/902c2bd2-ce99-11e5-9791-2b2ce72dc565.png 22:01 paramat i get 19% increase 22:02 paramat with intel integrated graphics 22:02 red-001 fixer shouldn't that be in engine development ? 22:02 red-001 not general discussion 22:02 Fixer red-001, dunno 22:03 Fixer feel free to move it %) 22:03 red-001 I can't 22:03 paramat it's ok 22:04 Fixer paramat, and you are not conserned with usual stutter :V ? 22:04 paramat i am 22:04 paramat i mean that thread is ok in general 22:04 Fixer that's far from smooth gameplay 22:05 Fixer paramat, try this mg_valleys_spflags = noaltitude_chill,nohumid_rivers is it slow as hell for you? 22:06 paramat those flags shouldn't make it slower 22:06 paramat discuss it with duane 22:10 Fixer paramat, just wanted someone to test, have a strange feeling, will look at it more 22:11 Fixer RealBadAngel, you here? 22:11 Fixer RealBadAngel, have you changed the way meshes uploaded to GPU? 22:13 Fixer or maybe it is mapgen slowness 22:14 paramat the bottleneck is usually mesh rendering not mapgen speed 22:14 Fixer i'm confused 22:14 Fixer now it is really good in singleplayer, and meshes unload regularly in low portions 22:14 Fixer smoother 22:14 Fixer :S 22:15 Fixer this thing is driving me crazy 22:15 Fixer will look more 22:17 Fixer i will make automated mapgen test 22:26 nrzkt Fixer are your running in singleplayer or dedicated server ? 22:27 nrzkt for your tests 22:27 Fixer singleplayer 22:29 nrzkt use the server tab 22:29 nrzkt singleplayer is stupid because server run on the same thread than client 22:29 nrzkt and redo your tests 22:29 nrzkt performance should be better 22:29 Fixer can redo some tests 22:29 nrzkt i think singleplayer method for spawning a server should be removed to use the embedded server method 22:29 Fixer let me test it :} 22:30 Fixer i was thinking earlier about singleplayer and server tabs 22:48 paramat RealBadAngel if you haven't seen this, #3672 22:48 ShadowBot https://github.com/minetest/minetest/issues/3672 -- Inventory items are covering item_image_button labels since 6cd2b3b 23:25 Fixer !tell nrzkt practically same results, will see if stutter is different 23:25 ShadowBot Fixer: O.K. 23:46 Fixer paramat, weird, redone tests, results with shaders enabled look the same, but without shaders has much better performance with less stutter (57 fps instead of 51 fps), can't explain that 23:47 Fixer than previous tests without shaders 23:49 paramat ok good news i guess 23:56 Fixer paramat, it is not good news, for some strange reason results for shader disabled got much better (and less stutter) and very slightly for other cases, that means that smth changed and tests can be debuted 23:59 Fixer maybe it is videocard powersaving 23:59 Fixer creepy stuff