Minetest logo

IRC log for #minetest-dev, 2016-01-23

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:24 Fixer joined #minetest-dev
01:04 est31 joined #minetest-dev
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:21 ssieb joined #minetest-dev
03:32 est31 joined #minetest-dev
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:17 est31 joined #minetest-dev
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:40 DFeniks joined #minetest-dev
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 OldCoder joined #minetest-dev
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
05:07 hmmmm joined #minetest-dev
05:11 Icedream joined #minetest-dev
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:36 blaze joined #minetest-dev
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.
07:41 Hunterz joined #minetest-dev
08:01 Calinou joined #minetest-dev
08:37 Elinvention joined #minetest-dev
08:45 Krock joined #minetest-dev
09:22 DFeniks joined #minetest-dev
09:36 red-001 joined #minetest-dev
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?
09:56 jin_xi joined #minetest-dev
09:58 VargaD joined #minetest-dev
10:02 troller joined #minetest-dev
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
10:16 mangeurdenuage left #minetest-dev
10:52 OldCoder joined #minetest-dev
11:34 Megaf joined #minetest-dev
11:35 Darcidride joined #minetest-dev
11:44 Fixer joined #minetest-dev
11:46 CraigyDavi joined #minetest-dev
11:47 Calinou joined #minetest-dev
11:49 Obani joined #minetest-dev
12:12 blaze joined #minetest-dev
12:21 Darcidride joined #minetest-dev
12:40 dfelinto joined #minetest-dev
12:48 nrzkt joined #minetest-dev
12:50 Megaf joined #minetest-dev
12:54 Amaz joined #minetest-dev
13:23 mangeurdenuage joined #minetest-dev
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 <RealBadAngel> http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&amp;t=48105&amp;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 Player_2 joined #minetest-dev
13:40 ElectronLibre joined #minetest-dev
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 mangeurdenuage left #minetest-dev
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 Fixer left #minetest-dev
14:04 Taoki We can next look into how it can be combined with the existing lighting calculations!
14:04 Fixer joined #minetest-dev
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 mangeurdenuage joined #minetest-dev
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 CraigyDavi joined #minetest-dev
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 ElectronLibre joined #minetest-dev
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 H-H-H joined #minetest-dev
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 jin_xi joined #minetest-dev
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:03 dfelinto joined #minetest-dev
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 kaadmy joined #minetest-dev
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 est31 joined #minetest-dev
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 paramat joined #minetest-dev
15:25 Taoki And guarantee that shadows are cast properly in any direction.
15:25 Obani joined #minetest-dev
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 iamafriend joined #minetest-dev
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:35 Gael-de-Sailly joined #minetest-dev
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] <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: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:13 Fixer_ joined #minetest-dev
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:44 rubenwardy joined #minetest-dev
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:45 hmmmm joined #minetest-dev
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 Obani joined #minetest-dev
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 <Taok.i> 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 Darcidride joined #minetest-dev
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 joined #minetest-dev
18:46 Taoki Sorry about that... got mysteriously disconnected after my last message :P
18:46 VanessaE [01-23 13:45] <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:46 VanessaE [01-23 13:46] <VanessaE> 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:09 paramat left #minetest-dev
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:17 Taoki joined #minetest-dev
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:37 mangeurdenuage joined #minetest-dev
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 Calinou joined #minetest-dev
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:10 Soni joined #minetest-dev
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:42 rubenwardy joined #minetest-dev
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
21:12 Dragonop joined #minetest-dev
21:14 red-001 joined #minetest-dev
21:18 red-001 joined #minetest-dev
21:24 DFeniks joined #minetest-dev
22:14 red-001 meshnodes!
22:15 red-001 for doors
22:23 turtleman joined #minetest-dev
22:27 Megaf joined #minetest-dev
22:57 GabeN joined #minetest-dev
23:01 blaze joined #minetest-dev
23:18 Darcidride joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext