Time Nick Message 01:54 RealBadAngel hm, got a weird problem with global illumination 01:55 RealBadAngel everything got light, even when covered by something else 01:55 RealBadAngel i mean caves are fully lit when using directional light source 01:59 Taoki RealBadAngel: Sure. The light needs to be separately masked by the lightnode levels in the current lighting system. 01:59 Taoki That's one of the challenges with HW lighting. 02:00 RealBadAngel any idea on that? 02:01 Taoki As far as Irrlicht is concerned, realtime lights shine as far as their radius goes (or infinitely if they're sunlight). For Minetest's use case, we need a separate render pass, which contains the area of geometry to be affected by sunlight (similar to the z-buffer, a black and white image of affected faces). 02:01 Taoki Normally we'll want one for each light source, once torches will start using this too. 02:02 Taoki For now, as far as sun / moon are concerned, we need a black & white render pass of all node faces affected by sunlight. The lighting pass for the sun must then be multiplied with this image. 02:03 RealBadAngel wonder how to achieve that 02:04 RealBadAngel we cant use vertex colors because that holds ambient light 02:04 RealBadAngel at least it looks like so 02:04 Taoki Ideally, there should be some way to separate all and any shading into one render pass, and the unlit textured geometry into another. I think some engines can do just that, not sure about Irrlicht. 02:05 Taoki I was hoping it could be done from vertex colors. 02:06 Taoki The lighting baked into vertex colors is kinda exactly what we need to turn into a render pass. Then we can hopefully detect and extract various lightlevels from it knowing the brightness. 255 should be lightlevel 15, 0 should be lightlevel 0. 02:07 RealBadAngel but that means lighting wont be possible without shaders 02:08 Taoki Only areas lit by sunlight have a light level of 15. But there is another problem: What to do when sunlight shines into a cave, and light level gradually decreases the deeper you go near the entrance? 02:08 RealBadAngel otherwise i cant prevent that damn sun lighting everything around 02:08 Taoki Sadly it won't, yes. I can't think of any way that would work otherwise. Although there might be one? 02:08 Taoki I discussed this a while ago actually, but remember finding no solution. What I proposed was something among the lines of: 02:09 Taoki We need a way to mask individual light sources, and restrict them to specific faces. This would have to be done by basically turning (parts of) the existing lighting system into a mask, instead of setting them as vertex colors like we do currently. 02:11 Taoki Problem is, I don't know how we can trick Irrlicht into being told "light X should only shine on surface Y based on the brightness of texture Z", where Z is a grayscale texture we generate in the code using the existinc light system... for any number of individual light sources. I imagine it's possible, but I don't know what trickery it takes. If anyone does, please do help! 02:12 Taoki Idea: If we'll be rendering lightmaps / shadowmaps, we could simply modify these. And combine realtime shadows with the brightness of the existing lighting system. This would kinda be ideal really. 02:14 RealBadAngel i can lit the surfaces based on vertex lighting 02:14 RealBadAngel but ONLY in shaders\ 02:15 RealBadAngel i mean i can allow the surfaces to be lit by HW light 02:15 RealBadAngel but then, whats the point even to enable it? 02:15 RealBadAngel i could just use only the vector to calculate the light in shaders 02:15 Taoki Yeah... combining passes like this requires shaders. Sadly HW lighting will require running with shaders on for this reason, otherwise old lighting system. Can't think of a way around it... doesn't mean there isn't one though. 02:16 Taoki Well the advantage to HW lighting is 1 - It's directional and smooths accordingly, 2 - You can create dynamic shadows. And there's also the right way to go but yeah. 02:16 RealBadAngel to get light levels we need old lighting system 02:16 Taoki Sure... that is always needed. 02:17 Taoki In any approach 02:17 Taoki Mostly because Lua relies on it for mods to know the light level. 02:17 Taoki Wait... 02:17 Taoki Well I had an idea, but surely no one would agree with it >_> 02:17 RealBadAngel but i will need it to enable/disable lighting the surface by sun 02:18 RealBadAngel which is kinda stupid 02:18 Taoki There sort of is another option... but it would require accepting a change in how mods report light. 02:18 RealBadAngel what for having HW lighting when it doesnt care about obstacles on its way 02:19 RealBadAngel then only reason for having it would be shadows 02:19 Taoki The only other option is this: We remove the vertex colors and old light calculations entirely! We make dynamic shadows obligatory, which will guarantee that light cannot shine where it's not supposed to. As for mods that use getLightLevel, we report the real light level instead. 02:19 Taoki So this would not necessarily break existing mods, but they would work differently. 02:19 RealBadAngel but then shadows caused by sunlight in dungeons? 02:20 Taoki Dungeons have a roof, so sunlight won't really get inside. 02:20 Taoki That is, if the whole cave has loaded. 02:20 RealBadAngel HOW? 02:20 RealBadAngel the question is how to block the sunlight 02:21 RealBadAngel it lits every damn visible face 02:21 Taoki If we were to ditch the dependency on the current lighting mechanism, we could enable realtime shadows for sun lights. In that case, the geometry of dungeons itself keeps light from shining inside. 02:21 Taoki Granted however that the ceiling has finished loading. 02:22 Taoki Also note: Normally, when you're in a cave and not seeing anything located outside of it, rendering of the sky is disabled. Sunlight should then be disabled too, which spares the GPU of calculating the shadows for a light we never see. 02:22 Taoki However this rendering stop for the sky is faulty and doesn't always work right 02:24 Taoki https://www.youtube.com/watch?v=NgFxZX7saTQ The sun light basically needs to have shadows like this. Or another approach... as there are many: Volume shadows, stencil shadows, etc. Some allow softness... no point into diving straight into that right now though, sharp shadows are okay too. 02:25 frustrat1d blocky shadows seem oddly fit for minetest :P 02:26 frustrat1d does irrlicht support deferred shading? 02:27 Taoki http://irrlicht.sourceforge.net/docu/example008.html This seems to explain stencil buffer shadows. 02:27 Taoki frustrat1d: I understand it does. It's a pretty basic feature so the latest version really should. 02:28 frustrat1d deferred lighting calculation would allow max light distances greater than 14, at least visually 02:29 frustrat1d not sure how well older hardware would like it though 02:29 Taoki RealBadAngel: Look for the Irrlicht createDevice() function. The last boolean there should be shadows, it needs to be 'true'. 02:30 Taoki frustrat1d: Old hardware should normally support simple hardware lights with basic stencil shadows. This is probably OpenGL 1.0 stuff. 02:30 frustrat1d stencil shadows, sure 02:31 frustrat1d deferred shading requires enough ram and modern enough opengl to handle the g-buffer 02:31 frustrat1d i'm not sure where the cut-off on features is 02:32 frustrat1d but g-buffers can get quite big 02:32 Taoki RealBadAngel: clientlauncher.cpp, lines 542 and 675. params.Stencilbuffer = false; - Change that to true in both. All light sources should now cast shadows. 02:34 RealBadAngel that changes nothing 02:35 Taoki RealBadAngel: So shadows aren't working? 02:35 Taoki If so, it means the materials of surfaces themselves might need to be set to cast and receive shadows, which they currently might not be. 02:36 Taoki That's to enable the system altogether, and I understand it should activate it for all light sources (if they don't explicitly have an option for that). 02:36 Taoki So the next suspect should be the surfaces, which aren't casting or receiving them... 02:42 Taoki RealBadAngel: Make sure the light source is ELT_DIRECTIONAL type. For torches we'll use ELT_POINT. Not sure if we can ever enable support for ELT_SPOT too, might be a neat thing to have :) In any case, all should support shadows. 02:43 RealBadAngel it is directional 02:43 Taoki ok 02:44 Taoki I wonder whether material flags might be why some surfaces don't cast and / or receive shadows. http://irrlicht.sourcearchive.com/documentation/1.7.2plus-pdfsg1-1.1/classirr_1_1scene_1_1ISceneNode_a2841d5077854b9981711a403f33762cd.html 02:46 Taoki They all start with EMF_*. Like EMF_FOG_ENABLE toggles whether fog covers that face or not. I can't find a full list, and am looking whether any have something to do with shadows. 02:48 RealBadAngel ok 02:48 Taoki RealBadAngel: Oh... make sure EMF_LIGHTING is enabled on all materials! Since we currently use vertex colors to simulate lighting, it's most likely not. Though you should be seeing everything black if you didn't set this to true already... unless the old lighting system is still active. 02:49 Taoki There's also EMF_ZBUFFER, we might need it later for things but not currently as important I imagine. 02:50 RealBadAngel ive set all the vertices to 128,128,128 02:50 RealBadAngel then enabled lighting 02:53 RealBadAngel looks like only way to disable light is set EMF_LIGHTING to false 02:53 RealBadAngel lol 02:53 Taoki RealBadAngel: mesh.cpp, lines 88 and 414. mapblock_mesh.cpp, line 1202. content_cao.cpp, lines 211 380 916 940 1384 1420. For starters, all of these need to be set to true (ultimately more) 02:54 RealBadAngel ive enabled lighting in mapblock mesh, for all the nodes, thats enough 02:54 Taoki That's incorrect: Vertice colors must not be set manually any longer. Don't set their colors at all. 02:54 Taoki ok 02:54 RealBadAngel idc about entities now 02:54 Taoki They can come later, it's important for mapblock meshes now. 02:55 Taoki So they still don't cast or receive shadows? 02:55 RealBadAngel i need just a way to not let that damn light lit evertyhing 02:55 RealBadAngel there are completely no shadows 02:55 Taoki Ok... something is going wrong then, there should be. 02:56 Taoki And that is the way: Once volume shadows will work, sunlight should no longer shine indoors incorrectly. 02:56 Taoki That's why I'm bringing this up earlier. 02:56 RealBadAngel http://i.imgur.com/stFxj18.png 02:56 RealBadAngel thats the problem 02:57 Taoki Yes 02:57 Taoki Note: Once shadows do work, we also need to be sure that backfaces cast them! With backface culling enabled, this might need to be turned on separately. But that's a different step. 02:57 RealBadAngel on the surface eerything looks fine 02:58 Taoki AHA! 02:58 Taoki node->addShadowVolumeSceneNode(); 02:58 Taoki node->setMaterialFlag( video::EMF_NORMALIZE_NORMALS, true ); Might also be a safe thing to put on 02:58 Taoki And AHA! (again): light->enableCastShadow( true ); - Put this on the light source. 02:59 Taoki http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_mesh_scene_node.html#ad7cd00b302466dea891c7a0b6b28de19 03:00 Taoki http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_light_scene_node.html#a1520d051fe04bc8c5c8975fb3908161b 03:01 Taoki Basically, the light needs that CastShadow value to be true, and the nodes themselves to have a ShadowVolume scene node attached to them. 03:04 RealBadAngel wont work 03:04 Taoki RealBadAngel: The full example is in the first post here, where someone posted a simple code for a scene with shadows in it: http://irrlicht.sourceforge.net/forum/viewtopic.php?t=39718 There might be more... such as scmgr->setShadowColor to set the shadow color. 03:04 Taoki Really weird then x_x 03:04 RealBadAngel world is not even a scene node 03:04 Taoki Ah 03:04 RealBadAngel pretty weird :) 03:04 Taoki Indeed. 03:05 RealBadAngel the mesh buffers are just drawn one by one 03:05 Taoki I need to go now. Don't forget there's also #irrlicht, someone there must know! 03:05 Taoki Good luck! I'm sure we'll find some way :) 03:05 RealBadAngel cya 03:41 est31 bloom is ugly 03:41 RealBadAngel what about HDR? 03:42 est31 no problem with that 03:42 RealBadAngel well, bloom is an option, some consider it very nice 03:42 est31 you mean this right? https://en.wikipedia.org/wiki/High-dynamic-range_imaging 03:42 RealBadAngel yes 03:43 RealBadAngel im using Uncharted2 tone mapping 03:43 RealBadAngel made after kodak films characteristic 03:43 est31 well it sounds not bad. 03:44 est31 its just pushing around colors 03:45 RealBadAngel basically 03:45 RealBadAngel effect is pretty nice, everything gets equally saturated 03:45 est31 idk perhaps there are some people who like it, but this time I really am on the side that bloom doesnt belong to the standard gfx settings. 03:46 RealBadAngel go outisde 03:46 RealBadAngel you will see bloom ;) 03:46 est31 and I would agree to somebody asking to not add it at all. 03:46 RealBadAngel that effect is about how your eyes are working 03:46 est31 well yeah 03:47 est31 but a screen is different 03:47 RealBadAngel such things makes the scene more natural 03:47 sofar I've never liked bloom in gameplay 03:47 sofar hdr I get, and it can help 03:47 sofar but bloom is basically washing out details in well-lit areas 03:47 RealBadAngel we are not talking bout Tron like bloom 03:47 RealBadAngel just a slight one 03:48 RealBadAngel so theres HDR to not wash it out completely 03:50 RealBadAngel we will see how it will behave with correct lighting 03:51 RealBadAngel atm im stuck with it 03:51 RealBadAngel our world is not even real irrllicht scene node 03:52 RealBadAngel thats something that pretends to be a scene node 03:55 RealBadAngel i think i will need to get light level at node (calculated only by sunlight, no light sources at all) 03:55 RealBadAngel and based on that level allow or disallow point lighting by sun 03:56 RealBadAngel no idea yet how to separate those two, artificial lighting and sun from our calculations 03:57 sofar make the sun a real light source 03:57 RealBadAngel i did 03:57 RealBadAngel then everything is lit 03:57 sofar remove the fake vertical light 03:57 RealBadAngel including caves 03:58 sofar you can't obstruct light sources? 03:58 RealBadAngel yeah 03:58 RealBadAngel or at least idk how 03:59 RealBadAngel on the surface it looks nice and correct 04:13 RealBadAngel i think i may have an idea how to handle that mess 04:14 RealBadAngel btw, BAW is not using real hardware light 04:14 RealBadAngel theyre using something similar to what we have 04:14 RealBadAngel http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=48105&start=330 see first post 04:20 RealBadAngel est31, what about using our lightbanks? one to hold sunlight only, second only the torches etc? 04:21 est31 idk 04:22 est31 I'll push a fix for c++11 compatibility later on 04:22 est31 in 20 mins 04:22 est31 it seems to be badly broken 04:22 RealBadAngel talking bout pushing, you can merge texture tear fix 04:22 RealBadAngel it fixes the issue for rendering to texture and some ATI cards 04:23 est31 I'd like to hear more users talking about it 04:23 sofar nvidia here, sorry 04:23 est31 or does it have two +1 ? 04:23 sofar can test on intel, too 04:23 RealBadAngel that is setting a default value, one liner 04:23 est31 I have intel netbook onboard gfx card 04:24 sofar heh, painful ;) 04:24 RealBadAngel and the issue was not that common 04:24 sofar I have various, all the way from SNB to broadwell latest gen 04:24 sofar the notebooks have been thrown out already ;) 04:24 RealBadAngel i know how to reproduce it regardless the GPU used 04:24 sofar of course, most are work machines 04:24 RealBadAngel but minetest doesnt have rendering to texure yet 04:26 RealBadAngel est31, anyway, you can check that what i added that this value should be set by default, somehow it isnt in certain cases 04:28 RealBadAngel but anyway, if one liner bugfix has to wait a few weeks, let it be so ;) 04:32 est31 perhaps I'll merge it later on 04:32 est31 both paramat and nrz have +1ed it 04:32 est31 I dont have to 04:32 est31 I just merge it :) 04:33 RealBadAngel ok 04:33 RealBadAngel ive disabled day btw 04:34 RealBadAngel so i will be able to get all the artificial lights working 04:34 RealBadAngel now need to make the second bank hold only sunlight :) 04:35 RealBadAngel then good bye smooth lighting and we enable per pixel lights, moooooving :) 04:46 est31 https://github.com/est31/minetest/commit/e50c784e2ca55735fc360ae51534288c2ea59ca5 04:46 est31 pushing that in 10 mins 04:46 sofar est31: the suspension is killing me.... 04:46 est31 lol 04:49 sofar est31: I would really appreciate you taking a look at both #3593 and #3443 04:49 ShadowBot https://github.com/minetest/minetest/issues/3593 -- New timer design. by sofar 04:49 ShadowBot https://github.com/minetest/minetest/issues/3443 -- Fix minetest.after sometimes calling timers too slowly by GunshipPenguin 04:49 sofar I know I kinda pissed on 3443 by writing something from scratch that I didn't see was even a PR... 04:53 sofar but because I didn't see it, I think I came up with a better design 04:53 sofar all the problems are caused by people trying to avoid list corruption ... while that can be avoided entirely by iterating reversely over the table... lol 05:05 est31 sorry, want to go to bed 05:05 est31 RBA your commit is pushed 05:05 est31 bye all 06:18 ShadowNinja The server should have some sort of identifier for the server list. 06:19 ShadowNinja Right now it just uses ip:port, but that will break if you change the server hosting, the port, or just get your IP reassigned. 06:20 ShadowNinja Just storing a pseudorandom 64-bit int in world.mt and sending it should do. 06:21 sofar ShadowNinja: right, that would be a decent method 06:21 ShadowNinja You could be a bit more fancy and set up some sort of pubkey-based verver varification while you're at it though. 06:22 sofar I don't like the unsorted list at all 06:22 ShadowNinja sofar: If it's sorting you don't like, that can be fixed with a bit of JS. 06:23 sofar why not sort on the client? 06:23 sofar sort by name, players 06:23 sofar filter out pvp, filter out survival, filter out empty 06:23 sofar I'd expect those to be available client-side 06:23 ShadowNinja This will be more helpful once servers are stored more persistently (seems-to-work implementation written). 06:24 ShadowNinja sofar: Yeah, so JS/Lua (as opposed to Python on the server, which does the default sorting). 06:26 ShadowNinja Currently I'm using MongoDB for the store because (a) I wanted to learn how to use another DB, and Mongo seems popular (b) mongo fits our data very well, since mongo uses JSON/BSON and we alrready use JSON. 06:46 sofar ShadowNinja: #3606 06:46 ShadowBot https://github.com/minetest/minetest/issues/3606 -- Sort public server list by player count, descending. by sofar 06:47 ShadowNinja sofar: It's sorted based on a number of factors. 06:48 ShadowNinja sofar: Based on the number this function returns: https://github.com/minetest/master-server/blob/master/server.py#L281 06:49 ShadowNinja That's just how the JSON response is sorted though, clients can rorder however they want (but they don't yet). 06:58 sofar ShadowNinja: um, sorry, it looked totally randomly sorted to me 06:58 sofar ShadowNinja: why the point system? just implement that sort client side? 07:03 sofar ShadowNinja: I instantly do not regret that PR, sorry. 09:49 red-001 #3597 09:49 ShadowBot https://github.com/minetest/minetest/issues/3597 -- Why is not /usr/share/minetest/mods recognized on Linux? 09:50 red-001 Is there a reason for this? 10:06 red-001 game#602 a minor fix that creates a new privilege 10:06 ShadowBot https://github.com/minetest/minetest_game/issues/602 -- Add access privilege that allows players to bypass protection. by red-001 13:33 Taoki Ugh... who can say that bloom is not nice?! It makes everything look so much more awesome :D Good thing it will be an option like everything else, so either side is happy. 13:33 Taoki RealBadAngel: I'm back, if you're still looking at that light source. No news I assume, and shadows are still not working? 13:33 RealBadAngel im stuck with one problem 13:34 RealBadAngel we do have lightbanks: day and night 13:34 RealBadAngel night holds only things lit by torches etc, which is good 13:34 RealBadAngel day holds sun+torches 13:34 VanessaE RealBadAngel: no moonlight? 13:35 Taoki RealBadAngel: Are shadows working now though? The main problem was the sun shining in caves. 13:35 RealBadAngel to get sunlight obstructed (or allowed) on a surface a need a third bank 13:35 RealBadAngel that will hold data for sunlight only 13:35 RealBadAngel Taoki, thats what im talking about 13:36 Taoki I suggest we try it this way first, and see the results. Dynamic shadows might be all it takes. 13:36 Taoki Ok 13:36 Taoki They should already be working... if they aren't it is a bug we need to solve. 13:36 RealBadAngel dynamic shadows wont stop the light ray if youre 10000 nodes below surface 13:37 RealBadAngel you have to know if theres sun allowed or not 13:37 Taoki RealBadAngel: 1 - They should, because the cave has a ceiling. 2 - They should a second time, because we stop the sky from rendering (the light source should stop as well then) 13:37 Taoki Just be sure that backfaces cast shadows too, that's of course essential. 13:37 RealBadAngel if cave is one meter below the groud? 13:37 Taoki Since underground rooms are basically like an inside out mesh, which needs to cast shadows unto itself. 13:38 Taoki Sure! 13:38 Taoki It has a ceiling made out of blocks. That ceiling contributes to volume shadows. 13:38 RealBadAngel if its open and you can see the lit areas from the exit? 13:38 Taoki Light shines through the opening yes. 13:38 Taoki Mind you, there is no simulated bounce lighting. But volume shadows should automatically take care of it all. 13:39 RealBadAngel highly doubt that 13:39 RealBadAngel http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=48105&start=330 see first post 13:40 Taoki I don't. I mean think about it: A room underground is like an inside out mesh. Even if the sky didn't get disabled, the surfaces of the ceiling cast shadows. What could not work? 13:40 Taoki But we need to try to be sure 13:40 RealBadAngel i tried 13:41 Taoki Wait... you got volume shadows to work? 13:41 RealBadAngel nothing is casting shadows with the clusterfuck we have 13:41 RealBadAngel no way to do so 13:41 Taoki Ok. That is the problem then. 13:41 Taoki There has to be... this is all a fruitless task then. 13:41 RealBadAngel you could attach shadow volume scene node to another node 13:41 RealBadAngel problem is that we dont have real scene node 13:42 Taoki Yes... that's what needs to be done. And hmmm... 13:42 RealBadAngel whole rendering is made by us 13:42 Taoki Thing is that for the map blocks to exist, they must be part of some kind of node. 13:42 RealBadAngel c55 wrote own implementation of scenenode 13:42 Taoki Be it a SceneNode, AnimatedSceneNode, etc. 13:42 Taoki Aha 13:42 Taoki What if we add a shadow node to that? 13:43 Taoki Also, what if we use a SceneNode instead of that own implementation? 13:43 Taoki Or, what if we add what this custom implementation is missing to have shadows? It shouldn't be something too fancy, I hope. 13:43 red-001 if you detonate tnt two blocks away form the bottom of a bed there is a 92% chance you get a glitched bed 13:44 Taoki We'll need to do this sooner or later anyway. So it's best we do it sooner to see how volume shadows aid us in covering underground areas. 13:44 RealBadAngel we cant add there nothing 13:45 RealBadAngel without rewritting it propably ;) 13:46 Taoki Some parts will need to be rewritten a bit. 13:46 RealBadAngel lol 13:47 Taoki Trying to look for the SceneNode used by nodes now 13:47 RealBadAngel im afraid of that bit 13:47 Taoki Where is that custom scene node type and what is it called? 13:47 RealBadAngel btw, whole ClientMap is ISceneNode 13:48 RealBadAngel good luck rewritting it :) 13:48 Taoki It shouldn't require rewriting all of it... just activating whatever's missing to get shadows to work. 13:48 Taoki Shadows are internal to Irrlight. It's probably something minor that makes this node type not support them. 13:49 RealBadAngel propably could be easier to start writing new game ;) 13:49 RealBadAngel idk 13:49 Taoki Not by far lol 13:49 Taoki What is the name of this scene node used by mapblocks? 13:49 RealBadAngel imho easier solution is to get the 3rd lightbank and exclude sun lighting in shaders basing on that 13:50 RealBadAngel clientmap.cpp 13:50 Taoki Is it ISceneNode? 13:50 RealBadAngel whole world is highly modified ISceneNode 13:51 RealBadAngel blocks are just meshbuffers in it 13:51 RealBadAngel bunch of meshbuffers grouped in mapblocks 13:51 Taoki http://irrlicht.sourceforge.net/forum/viewtopic.php?t=42174 13:52 Taoki We could get away with converting ISceneNode to IAnimatedMeshSceneNode 13:52 Taoki RealBadAngel: But first; Have you tried adding ->addShadowVolumeSceneNode(); to this ISceneNode? Maybe, just mabye, it works in latest Irrlicht. 13:53 RealBadAngel our scene node doesnt have this implemented 13:53 Taoki Ok 13:54 RealBadAngel and propably, adding those shadows wont stop the light from spreading everywhere 13:54 Taoki It really should, we need to see. In any case we will want shadows in some form, so yeah. 13:54 RealBadAngel you propably will get shadows on nodes caused by sunlight 13:54 RealBadAngel in caves even i mean 13:55 Taoki Not if backfaces cast shadows too, because caves have a ceiling :) 13:55 RealBadAngel i havent tried but i bet that entities in freeminer do cast shadows in closed areas and in caves 13:56 Taoki The only risk is, if the cave is too tall and surpasses your draw distance, the ceiling might load slower. But we stop rendering the sky by then anyway, so it compensates for that. 13:56 Taoki We just need backfaces to cast shadows is all. 13:57 RealBadAngel i am completely not convinced with that 13:57 RealBadAngel shadows != lack of light source 13:57 Player_2 sorry for budding in, but that method sounds like a performance nightmare Taoki 13:57 red-001 taoki would that mess with backface culling? 13:58 Taoki We'll have to see really. This is just a prediction. 13:58 Taoki http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_shadow_volume_scene_node.html 13:58 RealBadAngel have you read that post from BAW creators? 13:59 Taoki Will look again 14:00 RealBadAngel "First of all, hardware light just goes through everything and shadows are not automatic" 14:00 RealBadAngel look, we already do calculate where sunlight should be 14:01 RealBadAngel if i get that info per vertex (or face) i can use then real lighting calculations (phong or whatever) 14:01 RealBadAngel and more funny i dont need HW light for that at all 14:02 RealBadAngel i just need a vector 14:02 Taoki RealBadAngel: Can you please try IShadowVolumeSceneNode as well? From what I'm seeing, it should be the ISceneNode shadow component... it might work with our custom implementation. 14:02 Taoki Just to be safe 14:02 RealBadAngel but i need that without torches mixed into it 14:03 Taoki I'm curious if we can stop sunlight from shining in caves with volume shadows... we can get to the next part later. Torches will be a different challenge. 14:03 Taoki This is hopefully not a very fruitless test. 14:04 Taoki We can next look into how it can be combined with the existing lighting calculations! 14:04 Taoki In my opinion, it will be frigging awesome if we get volume or stencil shadows to work. I'm really hoping we somehow can, even if we need to grab the ISceneNode we use by the throat a bit :P 14:05 Taoki Notice: Volumetric shadows might allow for something else later on: God rays! :D 14:07 Taoki http://irrlicht.ru/api/classirr_1_1scene_1_1_i_shadow_volume_scene_node.html Another description of that function. Should be attackable to our ISceneNode from what I can tell... even if we mess with it a bit in Minetetst. 14:07 RealBadAngel shadow volume scene node requires shadow mesh 14:07 RealBadAngel you wanna render twice as much meshes? 14:07 Taoki The mapblock is a mesh, in one form or another. Must be some way to extract it. 14:08 Taoki No... we should be able to reference the current one though? 14:08 Taoki We attach the volumeshadowscenenode to the iscenenode... so it should be able to read it from there. 14:09 RealBadAngel even if i cannot agree to covering incoming light with shadows everywhere, its plain stupid 14:09 Taoki IShadowVolumeSceneNode::setShadowMesh(our_iscenenode->insert_the_mesh_of_the_mapblock_here) 14:10 RealBadAngel it doesnt work that way even in real world 14:10 RealBadAngel ceiling is the ceiling, light CANNOT go through 14:10 Taoki I know. Volume shadows should achieve exactly that. 14:10 Taoki That's the point. 14:10 Taoki Light doesn't shine in caves IRL because their ceiling blocks the light, and the entire ground. 14:10 RealBadAngel ugh 14:11 Taoki I just can't think of a better way, which does use HW lighting which is better. 14:11 Taoki If we want the best of the best, lighting needs to be handled by the GPU and Irrlight. 14:12 Taoki But I don't know of any other way in which we can mask sunlight in caves, without using render passes which means shaders are required. 14:12 Taoki So volume shadows are our best bet... but I don't see why they wouldn't work out. 14:13 RealBadAngel error: ‘class ClientMap’ has no member named ‘addShadowVolumeSceneNode’ 14:13 Taoki If that would help, I can make a test in Blender Internal and show you a render, to explain what I mean and why I think this works. 14:14 Taoki Ah 14:14 RealBadAngel told ya 14:14 Taoki Why does it say ClientMap and not ISceneNode however? 14:14 Taoki We're trying to add this to the ISceneNode if I'm not mistaken. 14:14 Taoki So it should be ISceneNode->addShadowVolumeSceneNode(); 14:14 Taoki Not ClientMap->addShadowVolumeSceneNode(); 14:14 RealBadAngel class ClientMap : public Map, public scene::ISceneNode 14:15 RealBadAngel error: base operand of ‘->’ has non-pointer type ‘ClientMap’ 14:15 Taoki scene::ISceneNode* parent 14:16 Taoki Try parent->addShadowVolumeSceneNode(); 14:16 RealBadAngel it simply not implemented there 14:16 RealBadAngel you can port it back from irrlicht for ClientMap 14:17 Taoki Ah... ClientMap is our custom function? 14:19 VanessaE RealBadAngel, Taoki: you guys DO realize that the engine needs to also be rewritten to do ONE mapblock per scene node... :) 14:19 Taoki VanessaE: Doesn't it already? 14:19 RealBadAngel thats what im trying to say 14:19 VanessaE Taoki: nope. the whole loaded map is one scene node. 14:19 Taoki Wait... isn't the SceneNode the world, and in it we add the mapblocks? Either as one mesh or multiple meshes each? 14:19 RealBadAngel im not THAT brave to rewrite it 14:20 Taoki Ok... that shouldn't stop us though. It's actually better, right? 14:20 RealBadAngel each mapblock is single mesh 14:20 Taoki We do need the entire world geometry as one mesh. 14:20 Taoki Ok 14:20 VanessaE it's rather worse because it makes occlusion culling less efficient 14:21 RealBadAngel i just need damn third light bank to get lighting working, thats all 14:22 Taoki I was hoping for more to happen in the transition, I guess 14:22 RealBadAngel this way with shaders we will get real lighting, specular, shininess, whatever 14:22 Taoki Again: If we got real lights with the internal shadow volume calculations to work, we could do so much. 14:22 Taoki It's really sad if we must miss this opportunity :( 14:23 RealBadAngel you wont get real lighting as IRL when you can have here shitload of lightsources 14:23 Fixer RealBadAngel, i can imagine everything will lag batshit-crazy 14:24 Taoki I hoped that distant ones can not be refreshed when not needed, to avoid bringing down performance. 14:24 Taoki Fixer: If they don't all cast shadows, should be okay. I'm not expecting all light sources to cast shadows obviously. 14:24 RealBadAngel i can make global illuminance working at almost no cost 14:24 RealBadAngel but i need that 3rd bank 14:25 Taoki RealBadAngel: You still plan to do it via hardware lighting, yes? Just making sure I understand everything right, with so much being discussed. 14:25 RealBadAngel kind of 14:25 RealBadAngel i do have sun position already 14:25 Taoki If it's by using an Irrlicht light source then that is an yes. 14:25 RealBadAngel (position of the light source) 14:26 RealBadAngel atm im using it for HW lights 14:26 Taoki If we can mask sunlight in caves differently, we can leave volume shadows for later... when we're brave enough to rewrite what needs to be rewritten for them to work. 14:26 RealBadAngel problem is that i cannot stop it from spreading 14:26 Taoki I know 14:26 RealBadAngel solution: with vertex lighting i do pass light levels 14:26 RealBadAngel as we do by now 14:27 RealBadAngel if i get light level caused by sunlight - i do enable light calculations from sun 14:27 Taoki RealBadAngel: If we dump my idea of masking with volume shadows then, we must go back to the other approach we talked about last night: We need a way to mask individual light sources per vertex. And I don't know if Irrlicht can be tricked to do that or how. 14:27 Taoki We have vertex colors, but they can't be customized per light source. 14:27 Taoki If they could, we'd simply use the current light calculation. 14:28 RealBadAngel r- holds day light level for face, g - night one, b - light source level 14:28 red-001 sorry if this is offtopic but can minetest use some of the improvements to irrlicht supertuxcart made? 14:28 VanessaE Is there any chance that this new lighting method will allow for colored/RGB lights? 14:28 RealBadAngel problem is that when calculating light on the face, sun is inserted as a regular lightsource there 14:28 Taoki VanessaE: That's certainly an aim! 14:28 VanessaE good deal 14:29 RealBadAngel so i can rely on nightbank to make world lit only by artificial lights 14:29 VanessaE RealBadAngel: and moonlight! 14:29 Taoki I was thinking of another trick we could use, but I don't know... 14:30 RealBadAngel but i cant rely on day one because there are artificial and sun lightsources mixed together 14:30 RealBadAngel VanessaE, theres no moonlight 14:30 RealBadAngel its a gamma trick 14:30 Taoki Basically: What if we used the current vertex colors in reverse, to simply set areas not lit to black? If a vertex color is 0 0 0, it shouldn't be affected by lighting. BUT: That means all lights shine on bright vertex colors, and none on black vertex colors. 14:30 VanessaE RealBadAngel: then there needs to be :P 14:31 everamzah moon and sun the same, just moon lesser so 14:31 Taoki This means that if we put a torch inside a cave, the area it brightens will be lit by sunlight... even if it's the correct area. And that's bad. 14:31 RealBadAngel ofc there should be one 14:31 VanessaE everamzah: well lighting color aside. moonlight is blueish. 14:31 RealBadAngel if i get sun working, i automatically have moon 14:31 RealBadAngel just change color of light 14:32 everamzah oh good 14:32 Taoki VanessaE: Sun and moon are already slightly yellow and blue. This would be a per-lightsource thing once we get there... but it's one of the simple parts. 14:32 VanessaE Taoki: just making sure you guys are keeping it in mind. 14:32 RealBadAngel they are not! 14:32 Taoki RealBadAngel: Color and angle :) 14:32 RealBadAngel yellow and blue are tricks 14:32 RealBadAngel only gamma corrections 14:33 Taoki Currently yes. Once light sources are there, we make them the color of the actual lightsource like they should be. 14:33 Taoki Not of the mask vertex colors like they are now. 14:34 RealBadAngel vertex colors do store not the colors but light levels 14:34 Taoki Ah... yes. I remember now, sun and moon colors are set somewhere else. 14:34 RealBadAngel and theyre mixed with black magic to tint things yellow or blue 14:35 Taoki Yeah. That way will hopefully go once light sources can do it properly. 14:35 Taoki The concern is how to do the masking. 14:36 Taoki Oh... I got an idea about something else also! 14:37 RealBadAngel one thing i know, that lighting propably will never work without shaders 14:37 Taoki Regarding torches: What if we could add a third light source to the world for now, which is an ambient light? Lightlevels < 15 would be the mask for that. This way we can temporarily assign torches to a single light source, but a real HW light like all others... it must however be non-directional, or (even better) point from up to down. 14:38 Taoki At least as a temporary solution, till we find a way to give each torch its own light source. Yes, yes... in a way that doesn't harm FPS, if there is one :) 14:38 Taoki This temporary solution would let us ditch any sort of vertex color colorization. 14:38 RealBadAngel if it would work that way there wont be 8 light sources limit 14:38 Taoki This too. 14:38 VanessaE that's what deferred lighting is supposed to solve. 14:39 RealBadAngel you sounds like you discover a way to magically have 1kk of light sources at no cost ;) 14:39 Taoki Currently, R is sunlight, G is moonlight, B is light sources. We could simply create 3 (or 2) light sources in the world, and mask each one by each channel. 14:39 RealBadAngel infinite number of light sources... lets try to guess what that could mean 14:39 Taoki Nah, I think this was your initial idea too. 14:40 RealBadAngel infinite time of calculating them all? :) 14:40 Taoki Well not sure what your idea was for torches. Did you want them on the old system? My suggestion was just to have a single hardware light for them. 14:40 RealBadAngel got the point? :) 14:40 Taoki Yeah 14:41 Taoki BTW, one ugly trick that could work: The light source for torches could be attached to the camera. Although... that would look funny, so maybe not. 14:41 RealBadAngel so, try to calculate a bit less, lets say 1k lightsources per each frame 14:41 Taoki We'd have 2 or 3 HW light sources with this approach. 14:42 Taoki If we don't need sun and moon at the same time, just 2: One for sun + moon, one for light sources. 14:42 Taoki The problem is: Each needs to have a separate mask, working similarly to vertex colors. How do we do that? I'm not aware of a way that Irrlicht supports this. 14:43 RealBadAngel solution is a mix of what we have and directional light from sun/moon 14:43 RealBadAngel if theres no sun/moon aviable we do things old fashioned way 14:43 Taoki RealBadAngel: Rather use what we have for the mask. 14:44 RealBadAngel we cant 14:44 RealBadAngel we dont know what the sun, what the artificial light is 14:44 Taoki ok. Don't see how we can mask the sun and moon then. 14:44 Taoki Except by setting vertex colors in reverse from how we do now. 14:44 Taoki But that doesn't create a per-source mask. 14:45 RealBadAngel i think i need to code that 3rd lightbank 14:45 RealBadAngel dont know how yet ;) 14:45 Taoki If we can't restrict given light sources to given vertex paints, there's no way at all. 14:46 Taoki Except doing it via shaders. 14:46 Taoki To be fair, I think we might need to accept that shaders will be needed for HW lighting... otherwise old way. 14:46 RealBadAngel we are getting such bank in one case, if we dont put there any torches 14:47 RealBadAngel and that works the sun from spreading to places we dont want 14:47 Taoki Yes, because the vertex colors are set by the sun / moon only. 14:47 Taoki We don't need to separate anything. 14:47 RealBadAngel that system is broken for us with a single torch placed 14:48 Taoki Indeed... because then we're representing multiple light sources. 14:48 Taoki And need a way to separate them 14:49 Taoki RealBadAngel: If we use shaders... can we generate multiple passes of vertex colors, and get images for any individual mask we want? 14:49 RealBadAngel what do you mean by multiple? 14:49 RealBadAngel rgb of the light? 14:50 Taoki Like for instance: Can we generate a render for the geometry as lit only by sunlight, then a render of the geometry as only lit by torches? A black & white map that is, which we can then mix how we want. 14:50 Taoki And a render of the unlit textured geometry. 14:50 RealBadAngel yes 14:50 Taoki Ok. 14:50 Taoki At this point I see that as the only approach. 14:51 Taoki It will require shaders to work... but it's better than nothing. 14:51 RealBadAngel but you still dont have that 3rd lightbank... 14:51 RealBadAngel ;) 14:51 Taoki So: HW lighting will be a setting. This setting will itself require shaders to have any effect. If both shaders and this setting are enabled, we get HW lighting... if not the current lighting. 14:51 RealBadAngel that doesnt have to be any setting for it 14:52 Taoki Ok 14:52 RealBadAngel shaders will use per pixel lighting at the same performance like now 14:52 Taoki We probably wouldn't need other lightbanks and sch. 14:52 Taoki Yep 14:52 Taoki As far as the C 14:52 Taoki erm, sorry... 14:52 RealBadAngel i do light calculation already 14:53 RealBadAngel for bumpmapping 14:53 Taoki As far as the C++ code is converned, we need to create multiple render passes: One of the current lightmap / lightlevels, one of the geometry lit by the sun / moon lightsource, one of the geometry lit by the torches lightsource, and one of the untextured geometry. 14:53 Taoki If we have these, we multiply each by each as necessary. 14:54 Taoki We need vertex colors into their own light pass however. 14:54 RealBadAngel but what for in fact? 14:54 Taoki So we can restrict the sun light to the light level of the sun. 14:54 Taoki How to put it... 14:54 RealBadAngel when we will have kinda bool passed to the shader (use sun or not) then single pass will do it all 14:55 RealBadAngel actually you cant 14:55 RealBadAngel imagine tunnel and a hole for sunlight at the end 14:55 RealBadAngel nodes deeper the tunnell will get lower light levels 14:56 RealBadAngel but stilll caused by sunlight 14:56 Taoki If currently in vertex colors: R = sun, G = moon, B = lightsources. Then we use 3 renders for starters: 1 = the geometry as colorized by these vertex colors, 2 = the geometry as lit by the sun light source, 3 = the unlit textured geometry. We multiply 2 by the R channel of 1, them multiply 3 by that result. 14:57 RealBadAngel r is daytime light level for the node - sun and torches are accounted for 14:57 Taoki Ahhh 14:57 RealBadAngel its not sun only 14:57 Taoki That sucks then, yeah 14:58 RealBadAngel thats what im talking about 14:58 RealBadAngel i need ONLY sun there 14:58 Taoki In that case, when HW lighting is enabled, we change the meaning of these colors: R is sun / moon only, G is just moon (if R is just sun), B is just light sources. 14:59 Taoki But we need to change the calculation in the code then. 14:59 RealBadAngel yes 15:00 Taoki Why does R account for torches anyway? B already does that... 15:00 Taoki Ah... wait! There is another way. 15:01 Taoki What if we simply subtract B from R? If B only has torches, and A has sunlight + torches, A - B should be sunlight without torches. 15:02 Taoki RealBadAngel: Wouldn't that work? 15:02 RealBadAngel b is light source value 15:02 RealBadAngel if the node is one 15:02 RealBadAngel in calculations both torches and sun nodes are inserted there 15:03 Taoki Isn't B also the level by which a surface is ligh by a non-sun and non-moon light source? 15:04 RealBadAngel sunlight spreading code just insterts lightsources with max level at the position 15:04 RealBadAngel later on code doesnt make a difference it is torch or the sun 15:05 Taoki Weird. What do these RGB channels even differenciate between then? 15:05 RealBadAngel and spreads it further 15:05 Taoki Also, how does the current code know to tint sunlit areas yellow and moonlit areas blue? 15:05 RealBadAngel by time of the day 15:05 RealBadAngel see finalColorBlend 15:05 Taoki Sure, but it must know which parts are lit by the sun and which by other sources. 15:05 RealBadAngel in both cpp and shaders 15:07 Taoki Looking now. It does incicate that R and G are sun and moon only, otherwise that code would also colorize torches in caves. 15:08 Taoki I mean it must know which areas are lit by the sky and which just by torches somehow. 15:09 RealBadAngel hm, maybe substracting it would really help somehow 15:12 Taoki RealBadAngel: It's just logical: If that function couldn't distinguish between areas lit by sun / moon and torches in caves, the light caused by indoor torches would also be tinded based on dytime, and we'd see torches turn yellow and blue underground which would suck. But we don't... so somehow it separates them already. Ideally we can use that separation too. 15:12 RealBadAngel idk how 15:16 Taoki Maybe try rendering the R and G and B channels, in a spot where you can clearly see where there are torches and where there is sun... then looking at each we can tell exactly what each one means. 15:17 Taoki Note: Before finalColorBlend! That function will need to be disabled with HW lights, as it would no longer be needed. 15:18 RealBadAngel shaders are using own implementation of it 15:18 RealBadAngel so u can even play with it editing nodes shader 15:18 RealBadAngel vertex one 15:18 Taoki Ok. It won't be needed after this though. Since it was used to tint outdor colors based on daytime, now we can do that from the light source directly. 15:19 RealBadAngel im trying now to eliminate artificial lighting 15:19 RealBadAngel you can try too 15:20 Taoki Yep... finalcolorblend was for that IIRC, so unneeded. 15:20 Taoki We need the R G B channels it used to separate light sources from the sun. 15:22 RealBadAngel im doing setting now all the colors with DAY - NIGHT 15:22 RealBadAngel when i put there a torch, i get blackened areas 15:23 RealBadAngel http://pastebin.com/aMWqhwsY 15:23 Taoki By the way... I just found a theoretical way to make torches have directional lighting and later on shadows, in an acceptable manner! 15:23 Taoki Yep, that looks good and like the right way :) 15:23 RealBadAngel point is to get such situation in a cave, that putting a torch wont change the light 15:24 RealBadAngel in completely blacked out cave that works 15:24 RealBadAngel but fails at the entrance to the tunnel 15:24 Taoki Anyway: We would create 6 sunlight-type sources for light sources, each one pointing: Up, down, left, right, forth, back. In other words, we have 6 global lights pointing -x +x -y +y -z +z. All are masked by the sources light level map. 15:25 Taoki Since Minetest is mostly blocky, this should look pretty much okay! 15:25 Taoki And guarantee that shadows are cast properly in any direction. 15:26 Taoki Not sure how well 6 light sources will do... certainly better than dozens of them though. And we still don't reach the limit of 8, meaning we have 2 free whereas we only need 1 for sun + moon. 15:26 RealBadAngel ahem, single torch will emit light then everything around the world 15:26 RealBadAngel *at 15:27 RealBadAngel but maybe with masks? 15:27 Taoki Ah, no... nevermind. Shadows would fail to work underground, precisely because of the backface culling I mentioned. 15:28 Taoki Yeah 15:29 Taoki That's a good idea too: Pick a specific torch to do the emitting for all. But then, if the player moves and torches come in and out of the view, or torches are added or removed... we'll see the center of the light snapping around the place. 15:31 Taoki Hmmm... we could perhaps find the average location of all visible torches each frame, and put the lightsources light there. Then if torches are added or removed, or the player moves, we *smoothly* move the light source to the new average. 15:31 Taoki We must be careful so that this average isn't inside of a wall however, otherwise there will be no light nor shadows. 15:32 paramat please can anyone review/approve #3590 ? code is fine just needs another +1 15:32 ShadowBot https://github.com/minetest/minetest/issues/3590 -- Add V5 caves to Valleys mapgen. by duane-r 15:33 Taoki I'm not a core dev, sorry. Also not good enough with the mapgen to review that. 15:33 est31 I'll push this commit in 10 mins: 15:33 paramat an option to add our large pseudorandom caverns (lava, water or empty) to mgvalleys 15:33 est31 https://github.com/est31/minetest/commit/ef779b0ab6d7460fe074d8b2eda05864c822d905 15:33 est31 and merge sofar's culling pr 15:34 paramat no problem Taoki i'm asking core devs 15:34 Taoki ok 15:35 paramat est +1 on your commit 15:36 est31 thanks pushed 15:36 paramat (on trust) 15:36 Taoki RealBadAngel: What do you think about that idea? Can we loop through all light sources surrounding the player, generate the average location between them, and make the unique hardware light destined for light sorces follow that position smoothly? Then if light sources are added or removed, or the player moves, this position changes. Sounds like the best way to me. 15:38 paramat yeah i was going to merge 3600 but you can if you want 15:38 H-H-H hmmmm forum.minetest.org is throwing sql errors @ me 15:38 est31 merged it already 15:38 est31 with the caves PR, idk, I cant really +1 it as I dont know alot about mapgen 15:39 paramat ok i should talk to hmmmmm 15:40 Taoki Sorry, connection dropped for a moment... not sure if my last message worked? 15:40 RealBadAngel Taoki, seems for me that finalColorBlend doesnt know what comes from artificial light what from the sun 15:40 paramat !tell hmmmm please could you look at https://github.com/minetest/minetest/pull/3590 ? code is fine just needs +1 15:40 ShadowBot paramat: O.K. 15:40 RealBadAngel everythingh below light max is treated eually 15:41 Taoki Aha... so it simply colorizes lightlevel 15. 15:42 Taoki I see then. Means it didn't colorize sunlight partly shining into caves either, which sucks. 15:43 Taoki In case my connection dropping blocked IRC earlier: 15:43 Taoki [17:33:58] RealBadAngel: What do you think about that idea? Can we loop through all light sources surrounding the player, generate the average location between them, and make the unique hardware light destined for light sorces follow that position smoothly? Then if light sources are added or removed, or the player moves, this position changes. Sounds like the best way to me. 15:44 RealBadAngel idk yet, first of all i have to get rid of those torches in vertex colors 15:45 RealBadAngel if thats not done, i can move further 15:45 RealBadAngel *cant 15:45 Taoki Anyway need to go now... be back in 2 hours or less. Good luck... I'm sure this will look awesome pretty soon :D 16:37 ShadowNinja sofar: The point system is designed to put better servers at the top, while spreading players out over a few servers so there's less lag, since many players just choose one of the first servers. 16:45 paramat RealBadAngel please could you work on #3530 ? don't you think this should be your top priority? even if there was no FPS drop the extra amount of data per vertex should not be forced on those not using shaders 16:45 ShadowBot https://github.com/minetest/minetest/issues/3530 -- 21-25% FPS drop with shaders disabled due to vertex tangents commit 16:47 RealBadAngel paramat, im working on it, its a part of most complex change 16:47 RealBadAngel *more 16:47 Fixer paramat, minetest.transforming_liquid_add(pos) is not working for me either, both top and bottom node 16:48 RealBadAngel paramat, without shaders mt will get old rendering, with: directional lights (sun/moon), postprocessing etc 16:49 RealBadAngel i am now splitting thigs 16:49 Fixer paramat, tried on that code http://pastebin.com/raw/dJ8n2qaw 17:01 Fixer paramat, that mossy cobble code is nice, now areas that witnessed bugged liquids turned into moss land 17:06 paramat RealBadAngel , please could you work on the fix as a priority instead of delaying it by mixing it with a huge shader project? 17:07 paramat your proposed effects might not even be accepted 17:08 paramat Fixer ok 17:11 paramat i'm not saying drop all the fun stuff, but the fix should be a separated thing done as soon as possible 17:12 paramat there are players on the forum asking for vertextangents to be immediately reverted. if it's not fixed soon it will be 17:16 paramat you are not a core dev but you are acting like one, saying 'MT 'will' get this and that shader, we would like 'some' of your work where suitable 17:18 paramat you deserve a fork or branch of your own to do exactly what you want, because you have a strong vision for radical changes that will not be accepted here 17:19 rubenwardy Good gfx is radical as in a big change, but not radical as in unpopular 17:20 rubenwardy Saying that, I don't care much for normal mapping at 16px 17:24 paramat sorry but i feel i have to bug you otherwise i suspect you will delay and avoid, or present a fix only as part of a huge shader project. i get a proller vibe .. 17:26 VanessaE now now be fair, paramat.... proller's stuff was not easily disabled :) 17:27 paramat neither is vertextangents :} 17:28 VanessaE touché 17:38 Taoki RealBadAngel: Back. Any news? 17:46 VanessaE Taoki: yeah, you missed paramat's kilbith-inspired KISS rant ;) 17:47 Taoki Was logged in and read the baclkog, so no :) 17:47 VanessaE (inb4 he joins the channel just to bitch me out :D ) 17:57 RealBadAngel paramat, as not being core dev i dont have any of your priorities 17:57 RealBadAngel neither you cant ask me for anything 17:58 RealBadAngel and please do note ive fixed two issues lately, not caused by me, which were here since .10 or even earlier 17:58 RealBadAngel both took me a few long nights 17:58 paramat i appreciate those 17:59 RealBadAngel and when im saying that mt will get something i may not necesarily mean "your" mt 18:00 RealBadAngel you will get that code when it will be ready 18:00 paramat i'm asking that the vertextengents fix is, please, separated from anything else, in order to be done sooner and not mixed with another feature 18:03 Taoki RealBadAngel used to be a core dev. Then he took a celeron to the knee :D 18:03 Taoki Sorry, I had to. 18:03 paramat heh 18:03 VanessaE haha 18:05 RealBadAngel anyway, looks like i got lighting working quite nice 18:05 paramat i know i can't expect anything from you, but it would be 'nice' of you to see fixing a huge breakage of MT as a priority 18:05 Taoki RealBadAngel: Screenshots please, really curious :) 18:05 RealBadAngel Taoki, adding now properties for the materials for it to actually look nice 18:06 RealBadAngel ambient light, shininess and all that stuff 18:06 Taoki Awesome 18:07 RealBadAngel paramat, "nice" would be if you wouldnt trash my work just because of your spirit taste :P 18:07 RealBadAngel and lack of skills... 18:08 paramat well normalmaps were removed on agreement with other devs, and had some support 18:08 Taoki paramat: You can expect awesome quality lighting in a few days for one thing. 18:08 RealBadAngel but, no point to discuss about it, ive promised that code and will make PR with it soon 18:08 paramat thanks 18:11 RealBadAngel Taoki, atm ive disabled artificial lights at all, so i do have world affected ONLY by sunlight 18:11 Taoki Awesome 18:11 RealBadAngel thx to that, based on the light level passed i know if the face should be lit with sun 18:12 RealBadAngel if not, i will use ambient colour 18:12 Taoki RealBadAngel: Also, I had one more idea earlier after I left: If R can be used for both sun and moon, G can be used for torches... perhaps we could move ambient occlusion to B? That way we can modify it more easily in shaders, allow between brightening and darkening, etc. 18:12 RealBadAngel i need lightsources here too 18:12 Taoki Hmm... there should probably be a mix between sun lighting and ambient color. 18:13 Taoki Ah 18:13 kaadmy RealBadAngel: Screenshots please, really curious :) 18:13 RealBadAngel i do brighten them to get even nicer bloom 18:13 RealBadAngel and i can do that now even with black textured lightsources 18:14 kaadmy for bloom, could you figure out what is a light(perhaps something like stencilling) and increase bloom for thise? 18:14 kaadmy or is that what you already do? 18:14 Taoki RealBadAngel: Also, one thing to keep in mind: With hardware lighting, shading matters. So it's best to rely as little as possible on detecting whether a face is lit by the sun, and letting things happen internallt. For blocks this is of course less important, since we always know the direction of the 6 faces. 18:14 kaadmy for blocks you could even hardcode the shading and it would work most of the time 18:14 RealBadAngel shading? you mean our fake faces shading? 18:14 Taoki There are meshnodes as well though... but I assume these are treated as fully lit from lightlevel perspective. 18:15 RealBadAngel that will be absolutely disabled when surfaces got light from sun 18:15 Taoki RealBadAngel: Was mostly thinking of actual 3D meshes, which can have round parts or any orientation. For nodes we used fake shading until now... but now there will be directional lights. 18:16 Taoki No... the directional shading. That can't be disabled and shouldn't since it's why we want HW lights altogether :P 18:16 Taoki But for nodes, they will of course be mixed with the current light maps. 18:16 RealBadAngel we wont use HW lights 18:16 Taoki ... 18:16 Taoki I thought that's what you were working on! 18:16 RealBadAngel we will use per pixel phong shading 18:17 Taoki I see 18:17 RealBadAngel i just need light vector 18:17 RealBadAngel not an Xray from irrlicht HW lights 18:17 Taoki So no Irrlicht light sources at all? 18:17 RealBadAngel we will use them to cast shadows 18:17 RealBadAngel but nothing more 18:18 RealBadAngel surfaces gonna be lit by shaders completely 18:18 Taoki I... guess that might be better. 18:19 Taoki But for example: Will round meshes receive directional lighting properly? Like if you create a sphere, will the top be lit by the sun and the bottom dark? IIRC only HW lights can do that. 18:20 Taoki Like this http://2.bp.blogspot.com/-8ASMcfRiMso/UExFFRsKTeI/AAAAAAAAARI/eiQ_9X1DJ2Y/s200/Blinn-Phong+Per-Vertex.png 18:20 RealBadAngel if i know pixel position in the world, light source postion too 18:20 RealBadAngel so vector will be always correct 18:20 Taoki Ok. Normal maps indicate that we already know pixel position, so that sounds good. 18:20 Fixer RealBadAngel, question, when you finish global ilumination, how will caves behave? there is code that darkens/lights up the background, how it will work with it? 18:20 RealBadAngel this is gonna be per pixel, not per face lighting 18:21 RealBadAngel Fixer, artificial lights will work as before 18:21 Taoki This goes a bit beyond past what I know, but it sounds right and you certainly know what you're doing. per-pixel is probably even better overall, so sure :) 18:22 Fixer RealBadAngel, i mean if there will be global ilum, then deep in caves will be completely dark and darken background/fog code will not be needed anymore? 18:22 Taoki RealBadAngel: I know I talk a lot, but now I have to wonder: Maybe somehow, shadows might be doable through GLSL too? There is a vertex shader which holds geometry information, so it shouldn't be impossible. Gonna google a bit about this myself in the meantime. 18:22 RealBadAngel that will definitely look way better compared to smooth lighting. propably the same way as smooth was better in comparision to per face one 18:23 RealBadAngel Taoki, minecraft shaders do that, so we also can 18:23 Taoki per-pixel is certainly more accurat ethan per-face. Maybe this is better after all :) 18:23 Taoki Awesome! 18:24 Taoki RealBadAngel: Neat... OpenGL has an official tutorial on doing shadows: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/ 18:24 Taoki The code seems to be pretty small too :D 18:25 RealBadAngel Fixer, we will see how it will behave and if that fog will be still needed 18:25 paramat Fixer adjusting brightness of skybox will still be needed 18:25 RealBadAngel atm i want the sun perfectly workin, later on i will reenable artificial lighting and go for caves 18:27 Fixer finally good commit merges, so eager to grab new sfans or krocks build :} 18:27 paramat i'm interested in this lighiting work, it's an effect i actually approve of :} 18:28 Taoki RealBadAngel: Well, erm... this also sounds like a good time to support specular maps. Will that be the approach you'll be going with? Just like we now have a texture.png and a texture_normal.png, we would typically also add a texture_specular.png. 18:28 RealBadAngel shhh, dont tell that to paramat, hes gonna got heart attack at least ;) 18:29 Taoki hehe 18:29 paramat yeah don't 18:29 Fixer paramat is a least of your problems 18:29 kaadmy gah he heard >:} 18:29 RealBadAngel but yes, metal things will look metalic for example 18:29 Taoki https://en.wikibooks.org/wiki/GLSL_Programming/Unity/Soft_Shadows_of_Spheres 18:29 Taoki http://fabiensanglard.net/shadowmappingPCF/ 18:29 Taoki More on (soft) shadows via GLSL. And nice :) 18:29 kaadmy SHINEE GLASS 18:29 Fixer low fpssss 18:30 Fixer i think my gpu will handle it, but stutters get in the way 18:30 Fixer played valleys a lot and i can have 80-300 fps easily 18:31 Fixer just needs smoothness (avoid spikes) 18:31 Taoki Heh... it kinda sucks that we don't have a material definition system at this stage. Though with the way textures are specified in Lua, that might be harder to do now. 18:31 Taoki Well it could be done through a Lua function. Don't wanna kill you though... so maybe something to look at later and some other time :P 18:33 Taoki Something like minetest.define_material("name_of_texture_to_create", {diffuse = "something.png", specular = "something_glossy.png", normal = "something_norm.png"}). And maybe more could be supported in time... like reflective cubemaps. 18:34 kaadmy ^ that would be possible currently 18:34 kaadmy hacky though, but you could use the .png texture path for the material name 18:34 * Taoki is kinda thinking of the way idTech does this, and other game engines based on Quake like Darkplaces / Xonotic or Daemon / Unvanquished, etc. But they are much more advanced use cases... like allowing customizable blend modes between textures. 18:35 kaadmy yup 18:35 kaadmy darkplaces/q3a use a shader system 18:35 kaadmy but that supports more that visual effects; you can make surfaces act different too 18:35 Taoki They will be a lot of work to support though. Even more so than the new lighting :P That is if we allow blending modes and other things. 18:36 kaadmy liquid etc 18:36 Taoki The reason I'm thinking about them is, I'm hoping more features will at some point be added. One I really, really want to live to see in Minetest, is cubemap reflections AND refractions for glass. 18:36 Taoki Stained glass, refraction wise. 18:36 kaadmy ^ 18:37 Taoki http://forum.unity3d.com/attachments/refraction-shot-jpg.22571/ This. Think how nice it would be if Minetest houses had windows that do this :D 18:37 Taoki http://wdl.tmimgcdn.com/img_articles/8603/blurry_refraction_planescene_320.jpg And this ;) 18:40 paramat the problem with bumpmaps and special reflections etc. is that our textures are already designed to have all this 'baked in' as pixel art, the combination looks bad because of the clash of trying to do something 2 different ways. so you'll really need alternative textures with dedicated normalmaps etc. 18:44 VanessaE why not just auto-load? if a filename is foo.png, look for foo_diffuse.png. if the latter is found, use it instead of foo.png, and look for and load foo_specular.png and foo_normal.png. Else just load and use foo.png and ignore the others. 18:44 VanessaE i.e. let the very presence of a texture file be what decides if a material has those properties. 18:46 Taoki Sorry about that... got mysteriously disconnected after my last message :P 18:46 VanessaE [01-23 13:45] why not just auto-load? if a filename is foo.png, look for foo_diffuse.png. if the latter is found, use it instead of foo.png, and look for and load foo_specular.png and foo_normal.png. Else just load and use foo.png and ignore the others. 18:46 VanessaE [01-23 13:46] i.e. let the very presence of a texture file be what decides if a material has those properties. 18:47 Taoki VanessaE: That works for a basic system. A full material system allows for more to be done however. 18:47 VanessaE well sure but do we need a "full" system at this point? 18:47 Taoki You can define multiple textures, blend them in various modes, use different scaling on both, different mapping (eg: cubemaps), etc. 18:48 Taoki Well not urgently. But it is one of those things that would be nice to have someday :) 18:49 Taoki Anyway, I was gathering up more inspiration images on how we could do frosted glass (as I ofered this as an example). One of the reasons why materials are awesome. 18:49 Taoki http://www.joycg.com/jeditor/_html/loading.php?idx=37059 18:49 Taoki http://blog.maxwellrender.com/wp-content/uploads/2015/06/tests.png 18:49 Taoki http://blog.maxwellrender.com/wp-content/uploads/2015/06/a.png 18:49 Taoki Not even terasology has this. We'd sorta be among the first to do something that awesome in a MC-type engine :) 18:52 RealBadAngel http://i.imgur.com/0O4Cesf.png 18:53 RealBadAngel need to work on light levels on not so exposed faces 18:53 RealBadAngel but as you can see, no faces shading is needed 18:53 Taoki Looks promising and right :) 18:53 Taoki Yep 18:53 VanessaE RealBadAngel: it's getting there. good deal. 18:54 Taoki RealBadAngel: Is the direction determined per-pixel however? As in, you're not using the orientation of block faces manually, right? 18:55 RealBadAngel i to calculate light vector per each pixel 18:55 RealBadAngel orientation of faces describes all tangent space vectors\ 18:55 Taoki Awesome then :) If you have any mods that use a round mesh (entity or meshnode) maybe you can drop a screenshot of that too, to be safe on how it looks. It would be quite a sight to see compared to the old lighting. 18:56 RealBadAngel even if its mesh, normal to the surface is here per each face (or in fact triangle) 18:56 Taoki ok :) 18:57 Taoki Just a reminder: Don't forget the ambient occlusion system in the old lighting. I am noticing it's missing in that screenshot... no shadows in between cubes. 18:57 RealBadAngel even our cube doesnt consist of 6 planes 18:57 Taoki Ideally it can be done in shaders too though. 18:57 RealBadAngel its 12 triangles 18:57 Taoki Right 18:58 RealBadAngel theres lots code i need to implement still 18:58 RealBadAngel i just started to lit the world ;) 18:59 VanessaE Taoki: he's screamed "let there be light!", now he needs to "separate the light from the darkness" :P 18:59 Taoki xD 18:59 Taoki Yes, quite so :) 19:00 RealBadAngel actually i was screaming Fiat Lux! ;) 19:01 Taoki RealBadAngel: Will you try slapping one of those GLSL shadow codes on it too? The ones I found seem to be remarkably short... quite an opportunity. 19:06 * Taoki is reading up on the differences between shadow mapping and shadow volumes, to figure which would be better. They're different approaches with different advantages and disadvantages. 19:13 Taoki Okay. Apparently what we want are shadow volumes, they are the newest and best approach. Especially since Minetest is mostly blocky and does not use high-poly meshes, I assumeit should also be a lot faster in our particular case! 19:14 Taoki We need to generate the stencil buffer GLSL side. Looking up on some tutorials for how to do that now, but so far it seems pretty doable. 19:16 Taoki BRB 19:20 Taoki S**t... the stencil buffer can even be used to do cheap realtime reflections and more, or at least that's what some say. 19:29 Taoki Still looking exactly into how stencil buffers work, it's harder than I thought to find a good explanation. I only learned that by default, they're used as a mask similar to occlusion queries. Till then, I found a few simple ones with some example code on how to enable them natively in GLSL (poke RealBadAngel since you might want to see them) 19:29 Taoki https://www.opengl.org/wiki/Stencil_Test 19:29 Taoki https://en.wikipedia.org/wiki/Stencil_buffer 19:31 RealBadAngel ok 19:37 kaadmy ^ i was thinking using stencilling could fix the bloom-on-sand problem 19:40 Taoki Alright... I actually have an idea on how to do the shadows, which might be even better. But I'm not sure what the term for it is or if it's even a thing. 19:42 Taoki You calculate lighting per pixel, right? So how costly would it be to calculate if an obstable is present between the pixel and the light source it is lit by? Ray tracing per pixel would probably kill the FPS... but maybe we can compare to the depth buffer and a stencil map to do it at almost no cost! 19:42 frustrat1d https://en.wikipedia.org/wiki/Shadow_mapping#Depth_map_test 19:43 frustrat1d it's the type of shadows that most games use; usually much cheaper on modern hardware then volume shadows 19:44 Taoki Aha. Yes, something like that. 19:44 Taoki Volume shadows seem to rely on creating a fake mesh from the perspective of the light. That is indeed a lot more expensive than doing some quick trickery in the depth buffer. So it's most preferred. 19:44 frustrat1d volume shadows are slow and buggy by comparison. unless you're doing volumetric lighting ("god rays"), volume shadows are massive overkill 19:45 frustrat1d and even then, you had better be generating the shadow volumes with shaders 19:45 Taoki God rays are something I was hoping for at some point. But they should be doable via the depth map too, shouldn't they? 19:46 frustrat1d most implementations i've seen do god rays with a deferrred shading pass 19:46 Taoki Yep 19:46 frustrat1d i don't know the specifics though 19:47 Taoki Well, there is one big problem with shadow mapping: You need to create a second render, from the perspective of the light itself. 19:47 Taoki That's costly :< 19:48 frustrat1d not really 19:48 frustrat1d you can render to multiple targets simultaneously in modern gpus 19:48 Taoki We do have to render the view two times. My hope was shadows could somehow be done without that. If it's not that bad though... I dunno. 19:49 frustrat1d you send much simpler geometry if you're not using MRT's 19:49 Taoki Yes... from the light's perspective we only need to render a Z-buffer. 19:49 frustrat1d you use the simplest shaders, in fact there's usually no pixel shader at all 19:49 frustrat1d all you need is the z 19:49 Taoki The advantage: We can use the distance of this Z-buffer to determine the softness of the shadow! 19:50 frustrat1d also, small buffer sizes ;) 19:50 Taoki There is another catch here however: Sunlight is an infinite distance light. So which position do we render from? :) 19:51 frustrat1d you render in ortho projection 19:51 Taoki Aha! I think I know about that... it's 3D but without the depth skewing. 19:51 frustrat1d from at just outside the view frustum optimally 19:52 frustrat1d if you're going to be doing tricky stuff witht he depth buffer you need to read up on depth precision issues 19:52 frustrat1d even with 32 bit float depth buffers you can get precision artifacts if you're not careful 19:53 Taoki No shadowing technique is perfect, but one that's good enough should do the trick. 19:54 * Taoki is mostly trying to be the apprentice for RBA now, looking for the needed bits of code that he can test. 19:54 frustrat1d depth shadowing is really the only practical algorithm these days unless you're doing some cuting edge per-pixel global illumination stuff 19:55 frustrat1d and you had better have a couple titan's in SLI to render more than a demo with GI 19:55 Taoki Right :P 19:55 frustrat1d that's cool Taoki. 19:56 Taoki I imagined that volume shadows would sort of work because we have blocks, so it's few pixels to calculate. 19:56 Taoki That said, I play TheDarkMod a lot (idTech 4), and can confirm they are pretty darn slow :) 19:57 frustrat1d calculating the geometry is expensive, even with compute shaders 19:57 frustrat1d then you have to draw A LOT of pixels for the volume; there's effectively no backface culling on that pass 19:57 Taoki https://www.opengl.org/discussion_boards/showthread.php/183573-Directional-light-and-shadow-mapping-view-projection-matrices 19:58 frustrat1d yup, that's it 19:59 frustrat1d in general, you want to set your frustum's depth range to be as tight as possible around yoru geometry 19:59 Taoki So if we render in ortographic perspective, the position of the camera doesn't matter, right? It can be at the same center as the normal camera's position. 20:01 frustrat1d in perspective projection, the view frustum is shaped like a frustum 20:02 frustrat1d that is, a square pryamid with the top chopped off 20:02 frustrat1d in ortho projection, the frustum is shaped like a rectangular prism (stretched cube) 20:02 frustrat1d which is still technically considered a "frustum" shape iirc 20:03 Taoki Ah... I see now. The close plane and the far plane basically have the same shape and side. 20:03 Taoki **size 20:03 frustrat1d the "z" axis of this frustuim needs to be parallel to the directional light's normal vector 20:04 Taoki But it still needs a position... 20:04 frustrat1d the size of the frustum needs to fit your "player" view frustum in side it, at least for areas being shadowed 20:05 Taoki Makes sense. 20:05 frustrat1d usually shadows are not calculated for distant objects 20:05 Taoki We'll probably want the distance to be adjustable by a setting. 20:05 frustrat1d at least on my machine, minetest can't really draw "distant" objects at decent framerates anyway 20:06 Calinou I can use view range 256 just fine :P 20:06 * frustrat1d wishes his rig was as powerful as Calinou's 20:06 Calinou (there's little need to go above that distance) 20:17 Taoki frustrat1d: I was thinking about a different way, but have no idea how viable it is: If light is calculated per pixel... couldn't we check if each pixel hits a certain object on the normal depth map? If we know the camera's direction and the light's direction, we could try to trace the point in a 3D direction on the 2D image. 20:17 Taoki Main problem is if something behind the player is casting a shadow... so I guess not :( 20:18 frustrat1d that's what shadow depth maps do 20:18 frustrat1d they see if the pixel location in the player's view is the same world location (roughly) as the pixel in the camera's view 20:18 Taoki Yeah, but in their case you need to render from this other perspective, and even worse use a complex algorithm to match each point in both views (I can't get that one yet) 20:18 frustrat1d *light's 20:19 frustrat1d anything the player can see but the camera can't is in a shadow 20:19 frustrat1d *the light 20:19 frustrat1d the math is pretty simple 20:19 frustrat1d i think it's just a dot product or two 20:20 frustrat1d the number of render passes don't make a game slow, it's what you do in the pass 20:20 Taoki What if the camera has a different FOV from the light's perspective for example? 20:20 Taoki True 20:21 frustrat1d fov doesn't matter as long as you make sure that the player's frustum and the light's frustum overlap sufficiently 20:21 frustrat1d this is why in some games the shadows are only rendered so far away 20:21 Taoki Ok. Still trying to get my head around how you transpose the two in 2D 20:23 frustrat1d http://antongerdelan.net/opengl/raycasting.html 20:23 frustrat1d this explains the various spaces in opengl 20:24 frustrat1d it's for ray casting and uses a more complicated set of math than shadow maps do, but should help clarify how things work 20:42 Taoki RealBadAngel: Do you think you can give a try to this now? In essence: Create a second camera, make it ortographic, give it the same angle as the sun / moon light, position it somewhere (in relationship to the player's view) so it encompasses everything the normal camera sees. It must only rendered the z-buffer from the untextured geometry, to be as cheap as possible. 20:44 frustrat1d Taoki: you should try too. that's how you'll really learn it. 20:44 frustrat1d i read about opengl for years but none of it really sunk in until i actually started building a game 20:45 Taoki I don't have a test case ready, or the perparations to do deferred rendering. RBA got most of it running I hear, so he might have to do the testing. 20:45 Taoki Kinda digging around for the info so far 20:45 * Taoki nods, that is true with many things 22:14 red-001 meshnodes! 22:15 red-001 for doors