| 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&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 |
|
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 |
