Time Nick Message 03:02 hmmmmm i updated the TODO http://dev.minetest.net/TODO 03:03 hmmmmm why does it seem like i get more and stuff TODO, never less 03:44 D-Man you guys should add a portion of the game where the user can create a server while using the game, and/or local servers people on the same wifi can play. 03:46 kaeza ? 04:06 ShadowNinja Isn't there a pull request for mod .confs? I have use for it in three mods now... 04:15 ShadowNinja Yippe, down to 66 pulls... 04:27 ShadowNinja https://github.com/minetest/minetest/pull/484 I could try to split that out if you want. 06:33 hmmmmm ugh 10:19 Calinou http://forum.minetest.net/viewtopic.php?pid=95633#p95633 10:19 Calinou why every 5.3 seconds? 10:19 Calinou would increasing it increase performance? 10:19 Calinou or decrease it? 10:33 Jordach i'd set it to 180 seconds 11:15 PilzAdam "* Add block tinting (grass, water, sky, etc.) (for biomes)" <- no way, I hate this in Minecraft 11:15 Exio make it a setting 11:25 Jordach make it a settting 11:25 PilzAdam call it "mc = " 11:28 arsdragonfly :set compatible 11:28 arsdragonfly :P 11:28 Zeg9 there should be a color paramtype2 11:29 Zeg9 if only I wasn't lazy 17:23 hmmmm having a bit of a lighting problem 17:24 hmmmm doesn't seem like the vmanip's contents get messed with in any way at all after finishBlockMake... can't really figure it out 17:24 hmmmm and this is with a single thread, so i can only imagine how screwed up multithread generation would be 17:25 hmmmm in theory, there's absolutely no reason why the on_generate lighting calculation should be different from the one in makechunk 17:26 hmmmm everything starts off zeroed out, lighting gets calculated, then it's envlocked, the vmanip is written back and some mapblock things are set, but all that is irrelevant because everything happens within the same exact envlock 17:28 hmmmm if i disable lighting and merely call calc_lighting in on_generate, the entire thing gets lit up; if i zero it out beforehand with setLighting, i get dark shadows at block boundaries 17:28 hmmmm there is no reason why this should be happening 17:28 hmmmm freaking toughest bug i've wrestled with in a while 17:30 hmmmm looking at the games directory just gave me an idea... might be the other mods 17:30 hmmmm shit 17:31 hmmmm let's see without the flowers mod 17:33 hmmmm which isn't the problem 17:37 RealBadAngel hi all 17:39 sfan5 hi 17:44 hmmmm oh fuckme 17:44 khonkhortisan "this shouldn't be happening" one of the well-known phrases programmers say 17:44 hmmmm :( 17:44 hmmmm wanna know what the problem is 17:44 hmmmm i only write data modified in lua to the vm on write_chunk 17:45 hmmmm so when i call calc_lighting before write_chunk, it calculates it with everything as an air node 17:45 hmmmm the same principle would affect set_lighting and update_liquids as well 17:45 hmmmm this was a pretty big showstopping bug 17:47 hmmmm hmmm, unrelated, but i wonder how to get rid of those dumb "star destroyer" shapes in 3d noise terrain 17:49 sapier is there any reason for "merge lua main menu" not beeing on todo list? 17:58 celeron55 is beeing somehow related to bees? 8) 17:58 hmmmm sapier, what do you mean? http://dev.minetest.net/TODO#Things_to_do_right_away 17:58 sapier oh sorry 17:58 hmmmm lol i just added it 17:59 sapier argh :-) 17:59 hmmmm alright so here's how i'm going to do it 18:01 hmmmm i think i'm going to separate some api: there's going to be a emerged_minp, emerged_maxp = vm:emerge(p1, p2); *then* data = vm:read_data(); which is a simple copy of the vm data contents to a lua table, then vm:write_data(data) writes your data back to the vm, but then you have to call vm:commit_data(); in order to vm->blitBackAll(); 18:03 hmmmm and there's no breakage because i made the wise decision of not pushing any of this to upstream individually 18:04 sapier sounds reasonable ... I'd prefere if you not called it "write" as nothing is written in this step 18:04 sapier what about fetch/pull? 18:04 hmmmm get set 18:04 sapier yes 18:07 RealBadAngel guys, when next freeze is planned? 18:08 celeron55 i guess it's not planned 18:09 RealBadAngel i would like to pull bumpmapping code this weekend, thats why im askin 18:10 RealBadAngel ive tested it for over month when i was cut off (played offline and legacy world) so i think its tested enough already :) 18:11 RealBadAngel one thing i must say i felt a bit weird when i downloaded latest code without bumpmapping and tried it 18:12 RealBadAngel it really changes the feel 18:12 hmmmm i wanted an "early" release of the next version, because of the massive performance improvements, but i guess it's not happening 18:13 celeron55 hmmmm: it's mostly up to you, really 18:13 hmmmm people expect big things 18:13 hmmmm but they shouldn't 18:13 celeron55 no they don't 18:14 hmmmm there are at least quite a couple who *do*, i know this for a fact 18:14 celeron55 and even if they do, the only way to make them not is to stop following the imaginative expectations 18:14 hmmmm then they cry about how nothing changes in minetest and it's all worthless 18:14 RealBadAngel whinners will always do so 18:14 hmmmm that one guy pops into my mind in particular..... who was that.. he quit coming around because he was buttravaged 18:14 hmmmm ragequit 18:15 celeron55 well ask yourself: even if you work more, will you finish something that looks like a big change in their eyes? 18:15 celeron55 i guess you'll simply just work more on things that they don't see 18:15 hmmmm but he was basically saying that engine development is "worthless" because it's "good enough" at this point 18:15 hmmmm i told him to get fucked basically 18:16 RealBadAngel he was obviously wrong and we know it 18:16 hmmmm i have a feeling you guys know who i'm talking about but i forget his name 18:16 sapier "nothing changed"? imho even if there is not a single feature added but lots of critical bugs removed or performance increased is worth a release 18:17 VanessaE hmmmm: prestidigitator? 18:17 celeron55 i've never heard that discussion 18:17 hmmmm RealBadAngel, yeah of course he was wrong, but the thing is, he's somewhat representative of the way other casuals feel about minetest development who have no idea what's actually going on 18:17 hmmmm no, not prestidigitator 18:17 VanessaE hrm, dunno then 18:17 hmmmm he wasn't a developer type 18:17 RealBadAngel this one was a really strange one 18:18 hmmmm it wasn't mauvbic, i'm pretty sure... 18:18 RealBadAngel produced really weird code, psedo java style 18:18 hmmmm oh, prestidigitator? yeah 18:18 hmmmm he's a total java fanboy 18:18 celeron55 well actually whether MT is good enough completely depends on what one wants to do with it 18:18 VanessaE can't remember who then 18:18 sapier it's not important who said what just looking for big changes is a bogus aim 18:18 hmmmm meh. if i remember i'll say it 18:19 RealBadAngel not important really 18:19 celeron55 anyway, releasing about now would be a very nice move towards more frequent releases 18:19 RealBadAngel what is important, project like this is never finished 18:19 celeron55 i would approve such highly 18:19 hmmmm me too 18:19 hmmmm but i have a boatload of features that i know lots of people would love 18:19 hmmmm same with RBA as well 18:19 RealBadAngel could we make it with bumpmapping added? 18:20 celeron55 why does it matter? you'll be developing them in no time anyway and they won't be really delayed at all 18:20 hmmmm because he's been waiting since 0.4.6 for this 18:20 sapier imho if we release now we shouldn't add any big feature not already added yet 18:20 celeron55 think about it 18:20 RealBadAngel code is over 1 month old 18:20 celeron55 it's not the version number that matters 18:20 celeron55 it's time that matters 18:20 RealBadAngel no point to keep it away 18:20 hmmmm and as for me, this is sort of a complement to schematic decorations, and if there were a split in between the two, people would start abusing them too much 18:21 hmmmm also 18:21 sapier rba how many ppl have tested it? 18:21 hmmmm different versions do matter, because a lot of people do lots of stuff for releases 18:21 hmmmm they have to update distro repositories etc. 18:21 celeron55 hmmmm: well, a chance of people abusing an incomplete API is a real reason to delay a release 18:21 RealBadAngel many, code is aviable for download for all this time 18:21 celeron55 hmmmm: nothing else that you've said is 18:21 RealBadAngel and more, there are already 3 texture packs that use it 18:22 sapier beeing available doesn't say anything ;-) 18:22 RealBadAngel Haven, HDX and Sphax's 18:22 sapier ok so at least some test 18:23 RealBadAngel also theres script to produce normal maps for any texture pack out there 18:23 VanessaE RealBadAngel: that reminds me, I have an update for you for that 18:23 RealBadAngel the script? 18:23 VanessaE yeha 18:24 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies/minetest/generate-texture-normals.sh 18:24 sapier I guess we should really rethink if "merge window" concept wouldn't be an option 18:24 VanessaE it's multithreaded now thanks to xargs. 18:25 RealBadAngel sapier: http://imgur.com/a/Eq09o#0 18:25 RealBadAngel take a look 18:26 sapier I don't have any concerns about it beeing worth added, it's great! just adding big features right before a release .... ;-/ 18:27 RealBadAngel it was ready before 0.4.7 18:27 khonkhortisan that image has more bump mapping than color 18:27 RealBadAngel i was waitint to test it more 18:27 sapier if there's no quick release to happen I sugges adding all those features as soon as possible and do bugfixing until release 18:28 RealBadAngel i just need to check if files i modified were touched lately 18:29 khonkhortisan Does bump mapping work correctly with facedir? - if I rotate a node 180° on the front face, will the lighting be reversed? 18:29 sapier you should rebase it ;-) 18:29 RealBadAngel bump mapping has nothing to do with facedir 18:30 VanessaE RealBadAngel: maybe he means the current lighting bug where lighting rotates with facedir. 18:30 RealBadAngel ah ah 18:30 RealBadAngel i already fixed that, will pull it soon also 18:31 RealBadAngel sync to current tree is all i need 19:16 PilzAdam RealBadAngel, side note: Taoki wants to talk with you about skydome 19:21 Taoki RealBadAngel: Was mostly curious if you're still working on the skydome. I'm still very unsure of the concept itself, and if it involves a sphere mesh following the player's origin I disagree with the idea (for upstream, of course any optional mod is ok) 19:22 Taoki If anyone wants a skydome, the only way I'd personally vote for and consider ok is a way in the code to automatically generate the mapping (cubemap or spheremap) and give the sky an infinite distance (simply map it to the "infinite" space) 19:24 VanessaE I thought the latter was the plan anyway? 19:25 Taoki But yeah. From my experience at least, the method of having an inside-out textured mesh follow the player is the most hacky and bad way to do a sky. Wouldn't wanna see anyone working hard on doing something in a broken way too 19:25 VanessaE but there were possible plans to make the ecliptic variable based on the player's Z coordinate also 19:26 Taoki VanessaE: Not sure how possible it is with Irrlicht. But the right way is ti somply map the texture to the cackground (in a way that considers view angle) and deform it in such a way so it's a sphere / cube map 19:26 Taoki I'd be tempted to go with a cubemap sky, since that's a lot simpler. But in that case it's harder to animate layers over it, such as the red horrizon color at sunset. 19:27 Taoki Personally, I'd say the current sky system is good in essence. Just needs improvements 19:27 Taoki But as RBA did prove, being able to add textures to the sky is very useful 19:27 VanessaE quite so 19:27 celeron55 i have a branch that implements a basic per-player skybox lua interface 19:28 Taoki I think most importantly, the sun and moon should be possible to texture. For a while I thought it already is... I was pretty sad to hear the sun and moon textures are code-generated 19:28 Taoki celeron55: Does it use the "inside-out mesh following the player" approach? 19:28 celeron55 https://github.com/celeron55/minetest/tree/set_sky 19:28 celeron55 Taoki: of course not 19:28 celeron55 who would do anything like that 19:28 Taoki Good then :) And that sounds like a good idea (your branch) 19:29 Jordach what does the set_sky branch do specially? 19:29 Taoki Any estimation to when that branch will be in? I'd really love to see it 19:29 Taoki celeron55: Also, don't kill me for even remotely suggesting something that Minecraft also has (and therefore "copying it" :P ). But I think this would be very worth considering: http://forum.minetest.net/viewtopic.php?id=6375 19:30 Taoki The screenshot comparison I added in the first post speaks a lot I think 19:30 celeron55 i implemented it because i wanted to try to make this: http://c55.me/random/2013-05/screenshot_1726656136.png http://c55.me/random/2013-05/screenshot_1726683685.png 19:31 celeron55 there's no intention from my part for putting that in; it's up to others 19:32 Taoki ok. And I like that (your screenshots) 19:32 celeron55 that's partly the reason i wanted to add in the singlenode mapgen too 8) 19:33 Taoki What I'd really love to see regarding a Lua API for the sky though, in a way to set any planets and lights at any hour. So you can specify a "sky planet" as a texture, and a position + amount / color of light it emits at any hour 19:33 VanessaE that volumetric colored fog looks beautiful. 19:33 Taoki Similar to how Second Life has the Windlight editor for its sky 19:34 Taoki VanessaE: Yes. That's something that would be lovely for MT too 19:34 Taoki More likely with shaders though 19:34 PilzAdam https://github.com/PilzAdam/minetest/commit/7af479cba466f801c5cb648c8a449877957cb723 19:34 VanessaE I don't think shaders are needed, but what do I know? 19:35 VanessaE (unless piping the fog through a shader will result in better performance, of course) 19:35 celeron55 eh what 19:35 celeron55 so where's the volumetric fog you are talking about 19:35 PilzAdam celeron55, if you are still interested: it turned out that there is no second leak in VBO, you just have to decrease client_unload_unused_data_timeout 19:35 celeron55 is this once again some funky technical term that people have started using without any reality 19:35 Taoki PilzAdam: Looks good to me 19:36 Taoki celeron55: In Minecraft, fog color depends on sun and moon directionally. If the sun is setting for instance: The fog around the sun is orange, while behind the sun (where the moon is rising) it's a plale white 19:36 Taoki In other words, fog matches horrizon + sun / moon color in any direction and position 19:36 celeron55 Taoki: none of your screenshots show the fog being different color at different position 19:36 Taoki Which looks very beautiful and immersive 19:37 celeron55 the fog is continuously the same color in each of them 19:37 Taoki celeron55: They're screenshots so I didn't turn aroun 180*. But trust me, it works that way 19:37 Taoki I checked 19:37 Taoki If you look in one direction in Minecraft when the sun is setting, for is orange. If you turn around 180*, it's pale blue 19:37 celeron55 i still think it just sets the fog color based on what you're mainly looking at 19:37 celeron55 that's not anything more fancy than just dynamically adjusting the fog color 19:38 Taoki Not sure. I think I can see the transition, but I never used a field of view wide enough to cover an 180* area 19:38 celeron55 in any case, it's not volumetric fog 19:38 celeron55 even if it's actually how you explain it, that's just roughly a simple shader line 19:39 * Taoki looks closely at the screenshots, trying to figure out if there is a color fading of the fog or it's all based on where you look at and always the same color at one time 19:39 celeron55 i hate it when people think good-looking stuff requires some fancy technology 19:39 celeron55 it just doesn't make things go forward at all 19:39 VanessaE "fancy technology"? 19:40 VanessaE (shaders are still considered "fancy"?) 19:40 Taoki http://i43.tinypic.com/fnzq0l.png I think the fog riht around the edges is darker and more blue than in the center (where the moon is). Can't quite tell 19:40 Taoki There's likely some gradient there. But to see it all at once it would take a big FOV 19:40 celeron55 VanessaE: yeah sure, thanks for not reading what i said 19:40 RealBadAngel Taoki: sky sphere is centered always, its a different piece of the scene than world 19:41 VanessaE Taoki: definitely a different amount of saturation at the moon versus the horizon, but the hue seems to be the same. 19:41 Taoki RealBadAngel: ok. Does it still require a mesh file though? And does it have unlimited distance? 19:41 VanessaE celeron55: stop being an asshole. 19:41 VanessaE If I missed something, next time try saying "actually I meant X". 19:41 RealBadAngel mesh and unlimited (but for testing purposes i limited it) 19:42 celeron55 VanessaE: frankly i haven't seen any benefit from not being an asshole towards you 19:42 Taoki RealBadAngel: ok. The only way I'd personally consider it correct is finding a way to map it in the code. Sky meshes are really bad IMO, especially when there's a way to generate it more easily 19:42 Taoki It should be possible to generat ea hemisphere and texture it with a simple code. That would also allow it to have a geometry LOD 19:43 RealBadAngel sky model requires moon, sun, star sky, and blue map for dusk to dawn transitions 19:43 VanessaE celeron55: your being an asshole is precisely what's turned me off to the idea of even trying to contribute to (as in, writing more code for) the engine or the main game. 19:43 Taoki RealBadAngel: Yes, the idea is prolly good. But doing it with meshes sounds wrong. It should be possible to do it in code 19:43 VanessaE whether you see previous contributions as a benefit, I don't know, but at least others do. 19:44 Taoki RealBadAngel: Personally though, I like the current sky system. Would love some way to improve that instead, so sphere maps won't be needed 19:44 celeron55 VanessaE: when i try to help you, you just consider it being an asshole too; i've simply stopped trying by now 19:44 RealBadAngel Taoki, meshes are basic of the engine, whats wrong with them? 19:44 RealBadAngel also using meshes make it moddable 19:44 Taoki RealBadAngel: True. It's only for the sky that I find them wrong. I think better formulas for the existing skybox would be bette 19:45 Taoki I'd love to see it moddable. But if possible, with the current system mostly 19:45 RealBadAngel existing method is drawing pixels and boxes 19:45 RealBadAngel which is not moddable at all 19:45 VanessaE Taoki: you're thinking more of a mathematically-defined sphere then? 19:45 Taoki I know. That's what I'd like to see changed 19:45 Taoki VanessaE: Yes, if we really must go for a sphere map 19:45 RealBadAngel wait a bit for my model 19:45 PilzAdam RealBadAngel, only the textures should be modable, the sky itself not 19:46 RealBadAngel you mean meshes 19:46 PilzAdam yea, whatever 19:46 Taoki RealBadAngel: My ideal implementation of a moddable sky is a Lua method to define planets, which are textured sprites that have different positions at each time of day (and emit various lights) 19:46 RealBadAngel and thats the point 19:46 celeron55 Taoki: skybox/skyspehere/whatever is always an actual mesh AFAIK; altough it isn't usually loaded from a file 19:46 VanessaE Taoki: I can see the advantage to it, for sure, but I have to wonder what kind of performance you'd get out of it, since you'd have to basically deform everything that's placed onto the surface of that sphere (at least, at init time) 19:46 RealBadAngel lemme implement real lighting first 19:46 celeron55 (they are easy to generate on the fly) 19:46 RealBadAngel then we can go for modding it 19:47 Taoki RealBadAngel: Yes for real lighting :D 19:47 Jordach RealBadAngel, thats if you ever finish it 19:47 PilzAdam RealBadAngel, have you looked at celeron55's branch? 19:47 Taoki RealBadAngel: But as for the sky, it's the only thing that's worrying me. Since at least / especially for Minetest, I like the current sky system omst. What I don't like about it is that it's currently fixed and un-customizable 19:48 Taoki Yeah, c55's branch for customizable sky sounds like a great start :) 19:48 Taoki **omst = best 19:48 RealBadAngel i havent checked that branch yet 19:49 Taoki So what I'd wish instead is 1 - De-hardcode the sun and moon pixels (horrid implementation IMO) and replace them with a texture, 2 - Remove sun and moon from the code and att a Lua API to define sky planets (shouldn't be hard) 19:50 Taoki Each sky object would have an array of tables under the form { daytime, position_at_this_daytime, light_at_this_daytime } 19:50 celeron55 the sun and moon aren't made of pixels; they're simply untextured polygons 19:51 celeron55 as well as stars 19:51 Taoki yeah. IMHO that's the biggest emergency about them... making them textured at least 20:11 Taoki celeron55: Can you confirm PilzAdam VBO code he linked earlier is fine? Waiting eagerly for it to be in upstream and usable, and he found the solution to all problems with vbo 20:17 Taoki From what I last tested, it's all good now 20:20 celeron55 oh i needed to comment on that 20:21 celeron55 PilzAdam: if that's so, then the Right Way(tm) to do it is to keep the mapblocks in memory equally long as before but delete the meshes earlier 20:21 celeron55 (that's some work though) 20:22 Taoki Currently he added a note about setting the client caching limit very low. Till that bigger work can be done, does that work too (considering it's off by default) 20:22 celeron55 probably no server admin would approve pushing a considerable lower upstream default deletion time 20:22 celeron55 because it increases traffic for no good reason 20:23 Taoki No defaults would change upstream. People would manually have to change it in their minetest.conf together with enabling VBO 20:23 Taoki But current defaults stay the same 20:25 celeron55 in that case i don't really care, but somebody must promise to finish it sometime if it's put in that way 20:26 RealBadAngel in my model sky color is a map 20:27 RealBadAngel very same idea as hmmmm's grass tinting etc 20:28 RealBadAngel sky is shaded basing on sun position 20:29 RealBadAngel when touchin the horizon map causes dawn/dusk effect 20:30 Taoki RealBadAngel: Nice. But if possible, no fixed meshes involved is my suggestion 20:30 Taoki For the sky that is. Everything else is mesh-based of course 20:31 PilzAdam celeron55, would be unload time for meshes be configureable too? 20:31 PilzAdam *the 20:31 RealBadAngel you have seen the screenshots 20:31 RealBadAngel effects are really nice 20:31 RealBadAngel and every piece is moddable 20:32 Taoki They are. But I couldn't get myself to say the method is good still. I'd go for the branch celeron55 posted earlier, which seems to do what I suggested (customization of the current sky and texturing of sun and moon) 20:32 RealBadAngel thats why i got sun smiling, death star or milky way photo 20:33 celeron55 PilzAdam: umm... well i guess so 20:33 RealBadAngel sun and moon are already textured in my model 20:34 RealBadAngel i dont get the point 20:34 celeron55 configuring it will be quite silly though 20:34 celeron55 it should work so that enabling the vbo setting will also enable a lower mesh unload time 20:34 celeron55 oh and now that i think of it 20:35 RealBadAngel celeron55, configuring in a way of putting sun.png into textures/all 20:35 celeron55 remaking the meshes from the mapblocks in memory is going to be a problem 20:35 celeron55 RealBadAngel: i'm talking to PilzAdam 20:35 Taoki RealBadAngel: My point is that IMO doing the sky with meshes is a wrong and hacky way, as a technical concept. And instead I'd rather make the existing sky configurable 20:35 Taoki Ah, sorry 20:35 RealBadAngel i think i shall publish my sky code for you to read it first 20:36 celeron55 because on some GPUs the first time a new mesh is shown creates a small frametime spike, which is diminished currently by mesh generation being spread due to the limited flow of mapblocks from the server 20:36 RealBadAngel i deleted almost whole old sky code and wrote it from scratch 20:36 celeron55 so that requires experimenting and finding some way to not make it horrible 20:38 RealBadAngel Taoki: meshes allows customization. Hardcoded stars dont. 20:38 Taoki I think start should be a texture too 20:38 Taoki **stars 20:39 RealBadAngel they are 20:39 Taoki ok 20:39 RealBadAngel properly mapped in blender ofc 20:39 RealBadAngel but its a texture 20:40 Taoki RealBadAngel: Is at least the sky sphere mapped to infinity? And no longer a model attached in any way to the player and centered to the FOV? 20:40 RealBadAngel sky is another scenenode 20:40 Taoki Ok 20:40 RealBadAngel independent from world 20:41 Taoki That part sounds good at least. If it's mapped to the "background" without having to be attached to anything, the idea might be good 20:41 Taoki If only the sphere was realtime in code too 20:41 RealBadAngel it is 20:42 RealBadAngel i rotate the sphere real time 20:42 PilzAdam celeron55, yea, the meshes get only regenerated if you are really close to them 20:42 Taoki Yeah, I mean not a .x or .b3d file :P 20:42 RealBadAngel so the basic idea is the sphere holds the stars 20:43 RealBadAngel and it rotates with time 20:43 RealBadAngel then comes the sky dome 20:43 Taoki Is the horrizon at sunset + sun & moon also a sphere? And is the sky color itself still a background color? 20:43 RealBadAngel which is coloured 20:43 PilzAdam celeron55, how would that be properly fixed? 20:43 RealBadAngel and covers the sphere 20:43 Taoki If this model happens to be chosen, sun a& moon should be textured planes 20:44 RealBadAngel at night dome is not blueish, so you can see stars 20:45 RealBadAngel at day its blue and covers the stars 20:45 Taoki Ok. Is all of it defined in Lua? I mean, are there no more sun / moon references in the code, and the sky is completely mode-based now? 20:45 RealBadAngel its not lua at all atm 20:45 * Taoki would like to see some screenshots with the default texture set for it 20:45 Taoki ok 20:45 celeron55 PilzAdam: don't ask me 8) 20:46 RealBadAngel Taoki, wait a sec 20:47 celeron55 PilzAdam: how low the timeout must be set for it to work? 20:49 PilzAdam 120 or so 20:49 PilzAdam it depends on how many RAM you want to spend for it 20:49 celeron55 PilzAdam: and do you know why there is so much memory consumption? the reason (i think) is that many meshes get generated up to four times before they are left to stay, as they need to be generated after the neighboring mapblocks are received; as the EHM_STATIC flag is immediately set, the short-time lived meshes are transferred to the GPU too and irrlicht then wants to keep them there for a ridiculously long time 20:49 PilzAdam 120 takes about 900 MiB 20:49 celeron55 one solution there could be to set EHM_STATIC only after the mesh has existed for certain time 20:50 celeron55 and lower the mapblock deletion timeout a bit but not so much 20:50 kahrl the proper solution would be to not generate meshes if they need to be regenerated immediately after :P 20:50 celeron55 kahrl: of course 20:50 kahrl but that would mess with TOSERVER_GOTBLOCKS etc 20:50 celeron55 it's just not quite trivial 8) 20:53 celeron55 in any case there will be a lot of memory consumption on clients of a busy server 20:53 celeron55 as stuff is placed and dug, there is a constant regeneration of meshes 20:53 celeron55 probably filling any amount of RAM if it's up to irrlicht's timeouts 20:54 celeron55 so really, eh, the proper solution would be to have irrlicht actually delete them when minetest wants to 20:54 celeron55 as MT already has proper management for them 20:57 celeron55 maybe we should assign some person to send patches to irrlicht that make it behave sanely 20:57 celeron55 8) 20:58 Calinou but people would need an uptodate version of irrlicht 20:58 Calinou the land would be full of screaming debian and ubuntu users 20:59 RealBadAngel Taoki, http://i.imgur.com/2xEp8Ow.png 20:59 RealBadAngel sphere itself 20:59 sokomine /me screams a bit 20:59 Taoki RealBadAngel: Sadly that's exactly what I was fearing to see :P 20:59 RealBadAngel http://i.imgur.com/xngqHYo.png 21:00 sokomine i think it depends on how difficult irrlicht is to compile. i have no idea about that. generally, linux-users have to compile their own mt 21:00 RealBadAngel glare effect using map 21:00 Calinou sokomine: but they do not want to compile their own deps. at all. 21:00 Calinou I'll never do that 21:00 Calinou RealBadAngel: looks nice 21:00 RealBadAngel http://i.imgur.com/wP3g7FK.png 21:00 RealBadAngel at night 21:01 Taoki RealBadAngel: No more blocky-llooking sun by default? :P 21:01 celeron55 Calinou: but at least stuff would be fixed on *some* time 21:01 celeron55 in 21:01 celeron55 * 21:01 Calinou yeah, still 21:01 RealBadAngel and with textures: http://i.imgur.com/W9vgYNr.jpg 21:01 Calinou Taoki: fun fact: blocky sun looks terrible without AA 21:01 Calinou i'm not against using actual skyboxes, like RealBadAngel pointed 21:01 RealBadAngel blocky? http://i.imgur.com/ETkhTnV.png 21:01 Calinou lol 21:01 Taoki Calinou: Not that terrible, but I can tell the edges 21:02 Calinou Taoki: we can avoid these edges, so why not do it :P 21:02 Taoki RealBadAngel: So... will the spheres be optional? What happens with the actual sky colors? Do they exist, and become customizable in Lua too when you get to that 21:02 Calinou customisable fog, sky colors would be nice 21:03 RealBadAngel you can achieve it with changing the color file 21:03 RealBadAngel no need for lua stuff 21:04 RealBadAngel its all texture pack thing 21:04 RealBadAngel not the code 21:06 * Taoki is still very skeptic and would prefer the current sky system being made texturable. Hopes RBA isn't discouraged though... the idea isn't bad by itself either I guess 21:06 Calinou [Taoki tomorrow: replacing the sun image with a pony] 21:06 Calinou RealBadAngel commits it, gets merged in master 21:07 Taoki haha, that would be one thing to see :) 21:08 Taoki But currently, I'm more in favor of celeron55 addition here (the configurable sky). Would like to see that upstream and how it goes. If that's not good enough either a sphere system could be considered 21:09 Taoki (and if we can't texture the stars some other way) 21:14 PilzAdam celeron55, I tried setting the EHM_STATIC static flag only if the mesh existed for 10 seconds, but there is no noticeable performance benefit left and the RAM increases too (not so fast, though) 21:20 celeron55 PilzAdam: maybe it's not so simple then; i don't really know anymore 21:31 arsdragonfly|pho PilzAdam : https://github.com/minetest/minetest/pull/790 I put the screenshot here 21:33 PilzAdam seems good 21:33 arsdragonfly|pho https://github.com/minetest/minetest/pull/790 and here's another commit 21:34 arsdragonfly|pho Are there any other core devs around? 21:36 arsdragonfly|pho https://github.com/minetest/minetest/pull/783 oh wait the second one should be this one 22:45 Taoki PilzAdam: So... can we still have the VBO setting with manually setting the client data limit, if that system doesn't work?