| Time |
Nick |
Message |
| 00:00 |
Taoki |
VanessaE: http://i46.tinypic.com/xdxtmc.png Just a local test override... there are no mods using this animation by default yet, but carts will probably be first |
| 00:08 |
Taoki |
Also, I think I'm going to fix the death animation too right now |
| 00:11 |
VanessaE |
looks good. I'll get after Tonyka to get 3dforniture updated accordingly. |
| 00:11 |
VanessaE |
you think you can make it stop looping? |
| 00:13 |
Taoki |
I'm making the death animation one frame. It's a rare animation, and there's no need to see it in process |
| 00:13 |
Taoki |
Therefore I won't make it loop any more, just a still frame |
| 00:14 |
VanessaE |
ok |
| 00:14 |
VanessaE |
though the animation does look pretty good.. |
| 00:47 |
|
doserj joined #minetest-dev |
| 00:57 |
Taoki |
http://minetest.net/forum/viewtopic.php?pid=53712#p53712 |
| 00:57 |
Taoki |
I need to go now so please see this branch tomorrow |
| 01:02 |
VanessaE |
ciao |
| 01:14 |
|
doserj joined #minetest-dev |
| 05:48 |
|
programmer joined #minetest-dev |
| 05:49 |
|
PsionicProgramme joined #minetest-dev |
| 05:53 |
PsionicProgramme |
greetings. experience programmer here looking into adding a mob to minetest. |
| 06:17 |
celeron55 |
merged and pushed those two |
| 06:17 |
celeron55 |
i hope they work 8) |
| 07:02 |
|
SpeedProg joined #minetest-dev |
| 07:33 |
|
jin_xi joined #minetest-dev |
| 08:08 |
|
darkrose joined #minetest-dev |
| 09:47 |
|
darkrose joined #minetest-dev |
| 09:54 |
|
rsiska joined #minetest-dev |
| 10:08 |
|
Taoki joined #minetest-dev |
| 10:11 |
Taoki |
Back. There was likely a power failure while I was asleep, so if someone contacted me about those changes feel free to do it again\ |
| 10:34 |
PsionicProgramme |
sorry for the spam, i am going to sleep soon. i was poking around the code most of today. |
| 11:18 |
celeron55 |
hmm, #minetest-delta is quite quiet these days |
| 11:20 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://minetest.net/wiki/doku.php?id=dev_index [1~ |
| 11:20 |
thexyz |
wtf is [1~ ? |
| 11:21 |
celeron55 |
wtf |
| 11:21 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://minetest.net/wiki/doku.php?id=dev_index |
| 13:10 |
Taoki |
Anyone read what I posted last night before leaving to bed? I did some important fixes for the player model, and have two branches that should be merged upstream very soon if posible |
| 13:11 |
Taoki |
Any of the people with access willing to take a look? PilzAdam is not back or I'd ask tim |
| 13:11 |
Taoki |
**him |
| 13:14 |
celeron55 |
how about if you'd take a look instead? 8) |
| 13:14 |
celeron55 |
either on github, or the channel log |
| 13:18 |
Taoki |
Ah, I didn't update the GIT yet, my bad. Will check |
| 13:18 |
Taoki |
Lots of things to handle for MineTest at once these days :P |
| 14:12 |
Taoki |
I assume mapblock_mesh.cpp is a client file, not server (for that matter it would be nice if each code file was marked as client or server) |
| 14:18 |
celeron55 |
if in doubt, you can look in src/CMakeLists.txt |
| 14:19 |
celeron55 |
it has all files separated into common, client and server (well, practically common=server) |
| 14:23 |
Taoki |
Good to know, thanks |
| 14:26 |
Taoki |
celeron55: I'm curious to know something about that lighting. In case I get dynamic light to be stable, but without fixing light showing in caves, is there a chance it could still go upstream as long as it's (obviously) disabled by default? This might encourage others to want to finish it, and it's never a shame for projects to have experimental features hidden somewhere |
| 14:27 |
Taoki |
I'm adding a test case which already uses a setting in minetest.conf which will be off by default everywhere possible. When disabled the current lighting is not touched and affected in any way. |
| 14:27 |
Taoki |
Still a lot to do but that will be the end result |
| 14:30 |
Taoki |
Slightly unrelated, but I remember how Second Life had this issue till they added dynamic shadows. You could never have indoors because the same brightness and lighting from outside would be copied. Which for the most part is still the case, but it never bothered me a lot. So as a fully optional setting it could work for a while I imagine |
| 14:35 |
|
PilzAdam joined #minetest-dev |
| 15:16 |
|
jin_xi joined #minetest-dev |
| 15:22 |
celeron55 |
PilzAdam: explain: https://github.com/celeron55/minetest/commit/ffad18e42442fed10c312adc989fc62b74e05896 |
| 15:23 |
celeron55 |
i cannot see any reason for merging that, anywhere |
| 15:23 |
celeron55 |
and i also don't see anyone approving it |
| 15:24 |
PilzAdam |
the glass block wasnt rendered as a cube but just the inventory image was taken as a sprite |
| 15:24 |
PilzAdam |
every node wich defines a inventory image looked somehow strange as a sprite |
| 15:25 |
PilzAdam |
now only items that are not nodes are sprites |
| 15:26 |
celeron55 |
ehm |
| 15:26 |
celeron55 |
the correct way of doing that is removing the inventory images? |
| 15:26 |
celeron55 |
the inventory image is supposed to override everything |
| 15:26 |
PilzAdam |
this would make the glassblock be dark in the inventory |
| 15:27 |
celeron55 |
then that should be fixed |
| 15:28 |
PilzAdam |
why should a dropped item have the inventory image instead of the images that it has in the 3D world? |
| 15:28 |
celeron55 |
what you've done is a bit like removing the steering wheel from a car because it has a broken tire |
| 15:29 |
celeron55 |
because some items have such a nodebox that you can't even see them properly |
| 15:29 |
celeron55 |
yet you want to see them properly when dropped or in inventory |
| 15:30 |
celeron55 |
on the other hand, there is no reason to do it the other way other than things being broken |
| 15:30 |
PilzAdam |
i didnt know that the inventory image of nodes should be override thinks outside of the inventory |
| 15:31 |
celeron55 |
...i guess you could've figured that out from the code you modified |
| 15:31 |
PilzAdam |
it looked illogical to me |
| 15:31 |
|
rsiska joined #minetest-dev |
| 15:31 |
celeron55 |
okay, so anyway, this is broken, i'll revert it |
| 15:31 |
PilzAdam |
i thought the dropped item should be a mini-node |
| 15:32 |
celeron55 |
it should be when there is no special item look for it |
| 15:32 |
PilzAdam |
its broken? |
| 15:32 |
celeron55 |
which is what it did previously |
| 15:32 |
PilzAdam |
in wich way is my code broken? |
| 15:33 |
celeron55 |
i have explained |
| 15:33 |
PilzAdam |
maybe i have a different understanding of "broken" |
| 15:33 |
celeron55 |
take that for example: http://minetest.net/forum/viewtopic.php?id=2855 |
| 15:33 |
celeron55 |
drop it now |
| 15:34 |
celeron55 |
you can't even see it |
| 15:34 |
celeron55 |
while it has an inventory image that would be seen just fine |
| 15:34 |
celeron55 |
which is the purpose of the inventory image |
| 15:35 |
PilzAdam |
okay, i didnt know that inventory image should be used for that |
| 15:36 |
celeron55 |
now feel free to fix it in the right way |
| 15:38 |
Taoki |
Damn... for over an hour I can't find where the sun's light over the world is being updated. So much code for the current lighting :P |
| 15:40 |
celeron55 |
hmm... why the hell does it look like that in the inventory |
| 15:40 |
celeron55 |
(if the inventory image is removed) |
| 15:40 |
PilzAdam |
it is also for nodes using nodebox |
| 15:42 |
|
Calinou joined #minetest-dev |
| 15:45 |
celeron55 |
hmm |
| 15:45 |
celeron55 |
is it for everything that has paramtype = "light"? |
| 15:45 |
PilzAdam |
i seems so |
| 15:45 |
PilzAdam |
*it |
| 15:46 |
|
doserj joined #minetest-dev |
| 15:46 |
celeron55 |
it isn't for leaves |
| 15:47 |
PilzAdam |
also stairs and slabs look correctly |
| 15:47 |
Calinou |
they're darker |
| 15:47 |
Calinou |
(they don't let light pass through -- if you add sunlight_propagates = true they look OK but they let light pass through :)) |
| 15:47 |
PilzAdam |
in inventory image? |
| 15:47 |
Calinou |
ah no, in game world |
| 15:47 |
Calinou |
in inventory they look fine |
| 15:47 |
Calinou |
regardless of sunlight_propagates |
| 15:47 |
celeron55 |
ehm |
| 15:48 |
celeron55 |
...why do stairs and slabs look correct |
| 15:48 |
celeron55 |
what *else* looks correct? |
| 15:48 |
celeron55 |
i can't see any pattern here |
| 15:49 |
PilzAdam |
this looks correct too: |
| 15:49 |
PilzAdam |
https://github.com/PilzAdam/farming/blob/master/pumpkin.lua#L281 |
| 15:50 |
celeron55 |
so what does not look correct, then? |
| 15:50 |
PilzAdam |
and it has a rather complex nodebox |
| 15:50 |
PilzAdam |
plants |
| 15:51 |
PilzAdam |
with plantlike drawtypes |
| 15:51 |
PilzAdam |
and I think some nodeboxes were incorrect, but i cant remember wich ones |
| 15:51 |
celeron55 |
i have something called a "Box" here, and it looks correct-ish too |
| 15:52 |
celeron55 |
there's some odd dark stuff in it but overally it's fine |
| 15:53 |
celeron55 |
so... i don't think nodeboxes are generally incorrect |
| 15:53 |
PilzAdam |
maybe im wrong in this point |
| 15:53 |
celeron55 |
we're left with... the glass block |
| 15:53 |
PilzAdam |
i cant remember correctly |
| 15:53 |
celeron55 |
so it definitely isn't for everything that has paramtype = "light" |
| 15:53 |
celeron55 |
so the question is, for *what* else is it? 8) |
| 15:54 |
Calinou |
inventory_image, when it uses minetest.inventorycube |
| 15:54 |
Calinou |
(if you're talking about dark blocks... i joined 10 minutes ago) |
| 15:55 |
Calinou |
nevermind, it's the inverse |
| 15:55 |
celeron55 |
i am asking for what node type with what parameters |
| 15:55 |
celeron55 |
currently it seems it is solely the glass block |
| 15:55 |
Calinou |
if you have a block with transparent texture but you don't use inventory_image = minetest.inventorycube("texture_name.png"), it will be black in inventory, will look normal (3D) when dropped. |
| 15:55 |
PilzAdam |
plantlike, signlike, raillike |
| 15:55 |
PilzAdam |
these look wrong |
| 15:55 |
PilzAdam |
also liquids |
| 15:55 |
PilzAdam |
and torchlike |
| 15:55 |
Calinou |
if you have a block with transparent texture but you use inventory_image = minetest.inventorycube("texture_name.png"), it will be normal in inventory, will not look normal (2D) when dropped. |
| 15:56 |
celeron55 |
okay... but leaves are fine |
| 15:56 |
PilzAdam |
and fences |
| 15:56 |
celeron55 |
fences are fine or not? |
| 15:56 |
PilzAdam |
fine |
| 15:56 |
Calinou |
leaves do not use sunlight_propagates, glass does |
| 15:57 |
celeron55 |
content_mapblock.cpp, mapblock_mesh_generate_special() |
| 15:57 |
PilzAdam |
dry shrub doesnt use it and its broken too |
| 15:57 |
celeron55 |
that is where something odd is happening |
| 15:59 |
PilzAdam |
liquid source is half dark, liquid flowing is flat and dark |
| 16:00 |
celeron55 |
i won't look into animated things, it's out of scope now |
| 16:01 |
celeron55 |
for me, liquid sources seem to work just fine |
| 16:02 |
celeron55 |
actually, no |
| 16:02 |
PilzAdam |
if i remove the animation and inventory_image it is half dark |
| 16:02 |
PilzAdam |
it has nothing to do with animation |
| 16:04 |
celeron55 |
liquid sources work fine for me regardless of animation |
| 16:06 |
PilzAdam |
this is what i got: http://www.zimg.eu/i/815414725 |
| 16:06 |
PilzAdam |
(source) |
| 16:07 |
celeron55 |
oh, that happens if opaque water is set to off |
| 16:20 |
celeron55 |
that day no sense was made |
| 16:22 |
|
kotolegokot joined #minetest-dev |
| 16:24 |
doserj |
anyone want to comment on https://github.com/celeron55/minetest/issues/307 ? |
| 16:27 |
celeron55 |
i ask performance measurements |
| 16:28 |
celeron55 |
that probably slows it down a lot |
| 16:28 |
doserj |
yeah, that was my concern :) |
| 16:28 |
|
hmmmm joined #minetest-dev |
| 16:30 |
celeron55 |
uncomment the TimeTaker line in there and see log after running the game for a bit |
| 16:31 |
doserj |
ok |
| 16:32 |
celeron55 |
PilzAdam: i don't see anything even close to obvious in here |
| 16:32 |
celeron55 |
Taoki: if you read our last discussion, maybe you could see something |
| 16:38 |
doserj |
most are: 17:35:01: INFO[main]: copy neighbor block data took 0ms |
| 16:38 |
celeron55 |
that is, if inventory_image is removed, certain items get rendered wrong to the item textures |
| 16:38 |
doserj |
some are 17:35:01: INFO[main]: copy neighbor block data took 1ms |
| 16:38 |
doserj |
varies between 0 and 1 ms |
| 16:39 |
celeron55 |
was that with the full version of the copy |
| 16:40 |
doserj |
that was with the g_26dir version |
| 16:41 |
doserj |
the g_6dir version has maybe slightly less instances of 1ms |
| 16:41 |
celeron55 |
PilzAdam, Taoki: the odd thing in this is that for example glass is just a cube - and it works with the special inventorycube generator, but NOT with the one that basically automatically does the same thing in a more complicated way |
| 16:42 |
celeron55 |
doserj: http://i.chzbgr.com/completestore/2010/6/20/69c60dd0-2cb0-444c-b2bb-85dae4441eca.jpg |
| 16:42 |
celeron55 |
i guess that could be made so then |
| 16:43 |
doserj |
lol |
| 16:44 |
celeron55 |
i've known that glitch almost since smooth lighting was added (well, more like since rails were added; they glitch with that too) but haven't bothered seeing what doing that fix actually causes |
| 16:51 |
celeron55 |
that adds 20 fetches from a core::map<v3s16, *>, 20 fetches from a core::map<s16, *> and 5120 copies of 64 byte chunks of data... which, i guess, doesn't consume that much time |
| 16:53 |
celeron55 |
PilzAdam: i'm afraid this thing will be left untouched for now |
| 16:56 |
doserj |
considering we only really need a fraction of them... |
| 16:56 |
celeron55 |
well, it could be optimized if somebody wasn't lazy |
| 16:57 |
celeron55 |
however, just stupidly fetching individual nodes from the borders will make that take much longer |
| 16:57 |
celeron55 |
(i've tried it) |
| 16:57 |
celeron55 |
because fetching a MapBlock is a slow operation (that is, if it is done for every node) |
| 17:01 |
celeron55 |
doserj: committed it |
| 17:02 |
doserj |
great! |
| 17:02 |
celeron55 |
congratulations for pointing it out directly enough for me not to ignore it 8) |
| 17:03 |
doserj |
heh |
| 17:05 |
doserj |
I could have pointed to http://imgur.com/5O5bR if you didn't see the problem :) |
| 17:07 |
celeron55 |
PilzAdam: if you feel there is an immediate need for fixing the thing you meant to fix in the original commit, i think a hackish check for the inventorycube texture could be added to item_entity |
| 17:07 |
PilzAdam |
its not that important |
| 17:07 |
celeron55 |
hmm... or maybe not |
| 17:07 |
celeron55 |
it's too hacky |
| 17:08 |
* PilzAdam |
doesnt like hacks |
| 17:08 |
celeron55 |
i would love to have this fixed but it's not so simple |
| 17:08 |
PilzAdam |
the original commit by me was not to fix this issue |
| 17:09 |
PilzAdam |
i just missunderstood the inventory_image / item_entity thing |
| 17:09 |
celeron55 |
it probably should be called "item_image" |
| 17:10 |
PilzAdam |
that would clarify it |
| 17:11 |
celeron55 |
oh god, i just opened mapnode.h of 0.3.2 to see how the field looks in it |
| 17:11 |
celeron55 |
ContentFeatures has changed surprisingly little since 0.3 8) |
| 17:11 |
celeron55 |
the node definition, that is |
| 17:11 |
celeron55 |
it's called inventory_texture in it |
| 17:13 |
|
VanessaE[L] joined #minetest-dev |
| 17:14 |
celeron55 |
hmm, current master has only 57k SLOC C++ |
| 17:14 |
celeron55 |
0.3.2 has 40k |
| 17:14 |
celeron55 |
that is surprisingly little increase |
| 17:15 |
VanessaE[L] |
not bad. |
| 17:25 |
celeron55 |
Taoki: are you aware of what causes the multiple players having the same color? |
| 17:26 |
celeron55 |
or, well, lighting color |
| 17:26 |
celeron55 |
it is because they share the same model |
| 17:26 |
celeron55 |
you will want to do the same thing that was done to wielditem models |
| 17:26 |
celeron55 |
that is, copy them |
| 17:26 |
celeron55 |
it's right there in content_cao.cpp |
| 17:27 |
celeron55 |
20 lines from where you'll copy-paste it 8) |
| 17:38 |
|
hummer_ joined #minetest-dev |
| 17:59 |
|
rubenwardy joined #minetest-dev |
| 18:11 |
Taoki |
celeron55: No idea at all. I implemented model visuals exactly as I seen down for sprites and the cube. Lighting should be set the same way too |
| 18:11 |
Taoki |
I noticed this problem and asked on the server two days ago, but I was told it's a known issue for all entities |
| 18:11 |
Taoki |
It likely happens for sprite players too as far as I'm aware |
| 18:12 |
celeron55 |
Taoki: no |
| 18:12 |
celeron55 |
Taoki: read what i said |
| 18:12 |
celeron55 |
Taoki: |
| 18:12 |
celeron55 |
// Copy mesh to be able to set unique vertex colors |
| 18:12 |
celeron55 |
scene::IMeshManipulator *manip = |
| 18:12 |
celeron55 |
irr->getVideoDriver()->getMeshManipulator(); |
| 18:12 |
celeron55 |
scene::IMesh *mesh = manip->createMeshUniquePrimitives(item_mesh); |
| 18:12 |
celeron55 |
|
| 18:13 |
celeron55 |
m_meshnode = smgr->addMeshSceneNode(mesh, NULL); |
| 18:13 |
celeron55 |
mesh->drop(); |
| 18:13 |
celeron55 |
you don't do that |
| 18:14 |
Taoki |
ah |
| 18:14 |
celeron55 |
createMeshUniquePrimitives copies the mesh |
| 18:14 |
Taoki |
I'll try to see if I can fix that in a minute |
| 18:15 |
celeron55 |
i guess "unique primitives" means that it will create new meshbuffers aka vertex arrays for it |
| 18:15 |
Taoki |
"cube" doen't have this either... should be changed. I'll try to do it and see if it works |
| 18:16 |
celeron55 |
it does |
| 18:16 |
celeron55 |
createCubeMesh creates the mesh from scratch |
| 18:16 |
celeron55 |
your thing is the only one |
| 18:16 |
Taoki |
Looking at the code now, yes it is. I never noticed. Should be easy to fix, I'll do it and post on GIT soon |
| 18:19 |
Taoki |
It looks like it's mostly the mesh->drop(); line missing. I remmember I did that at someone's advice, when I was asking about a problem on #irrlicht |
| 18:20 |
|
Calinou joined #minetest-dev |
| 18:21 |
celeron55 |
...are you sleeping once again? |
| 18:21 |
Taoki |
? |
| 18:21 |
Taoki |
I'm trying to follow the other examples |
| 18:21 |
celeron55 |
i can't understand how you could add model support to minetest while you don't even immediately get this one 8D |
| 18:22 |
Taoki |
The problem is I need to set m_animated_meshnode to mesh then do mesh->drop(); I was just copying mesh or something like that |
| 18:22 |
Taoki |
It's a part I missed... I'm not all knowing opr something :P |
| 18:22 |
Taoki |
*or |
| 18:23 |
celeron55 |
you have to copy the mesh, then set it to the meshnode and then call drop() so that the newly copied mesh will be deleted when the meshnode is deleted |
| 18:23 |
celeron55 |
if you don't copy it, it will delete the single global mesh and screw up everything |
| 18:23 |
celeron55 |
basic C++ memory management |
| 18:23 |
Taoki |
Yes, that's what I'm trying to do. |
| 18:24 |
celeron55 |
if you don't know what drop() does, read up on reference counting |
| 18:24 |
Taoki |
It deletes the initial mesh after copying. But it seems I was copying the mesh already, looking at the other examples. Just not dropping the original, so it was probably using that |
| 18:24 |
Taoki |
That's what I was trying to explain |
| 18:24 |
celeron55 |
it doesn't delete anything immediately |
| 18:25 |
celeron55 |
it just decreases the reference count, which is 2 after creating it, and after the meshnode has grabbed it |
| 18:25 |
celeron55 |
then when the meshnode destructs, it will drop() the mesh, and as the refcount goes to 0, the system will delete the mesh |
| 18:26 |
celeron55 |
the mesh that is a copy of the mesh that stays to be got from smgr->getMesh() |
| 18:27 |
Taoki |
Testing my change locally, then putting on git |
| 18:36 |
Taoki |
Something wrong is happening. I am properly copying the mesh just like for the cube mesh, but a third client connecting to the server crashes |
| 18:37 |
celeron55 |
cube mesh isn't copied |
| 18:38 |
Taoki |
Not sure. I'm doing the same thing as there though |
| 18:38 |
celeron55 |
you need to do the same as in wielditem |
| 18:38 |
celeron55 |
otherwise you're just failing hard |
| 18:39 |
Taoki |
Hmmm... I'll check if that works. Probaby the cube uses a different mechanism I don't understand |
| 18:40 |
celeron55 |
i've already described everything like three times... i guess you'll figure it out |
| 18:51 |
|
PilzAdam joined #minetest-dev |
| 18:51 |
Taoki |
Apparently Irrlicht sees me tring to convert something and it doesn't compile :/ |
| 18:51 |
Taoki |
http://pastebin.com/raw.php?i=fF5kNSHY |
| 18:52 |
Taoki |
It thinks I'm trying to convert IMesh to IAnimatedMesh, but there's no IMesh there, and the function should be for anything |
| 18:52 |
Taoki |
I hope this is possible for animated meshes at all |
| 18:53 |
celeron55 |
ah... |
| 18:53 |
celeron55 |
it might not be able to handle animated meshes |
| 18:53 |
Taoki |
I'll ask on #irrlicht to be sure |
| 18:55 |
celeron55 |
i don't see anything that would be able to copy an animated mesh |
| 18:56 |
Taoki |
Damn. Only thing could be typecasting IAnimatedMesh into IMesh there, but that would be silly |
| 18:56 |
celeron55 |
not likely to work |
| 18:56 |
Taoki |
Indeed |
| 18:56 |
Taoki |
I hope this doesn't mean "we're skrewed" |
| 18:57 |
celeron55 |
the animated meshes are kind of format-specific |
| 18:58 |
Taoki |
#irrlicht is slow as always. I'm trying to google but no one is mentioning any solution to this |
| 19:00 |
Taoki |
Can't find anything. Not sure what's to be done then :/ |
| 19:00 |
Taoki |
This isn't an issue I even imagined, I thought the mesh is just applied and works individually |
| 19:00 |
Taoki |
Till now that is |
| 19:01 |
celeron55 |
well, it wouldn't be if hardware lighting was used |
| 19:01 |
Taoki |
I know. I was thinking about that heh |
| 19:01 |
celeron55 |
well, i can think at least one way that could work straight away |
| 19:02 |
Taoki |
From what I noticed and know, MineTest IS using a hack for lighting. Which Icclicht probably isn't prepared for |
| 19:02 |
Taoki |
Yeah, I can too. Easy to guess :P |
| 19:02 |
celeron55 |
irrlicht can create more animated meshes from the data that was transferred over network, and it will store as many of them as to how many names they are loaded to |
| 19:03 |
celeron55 |
8D |
| 19:03 |
celeron55 |
hack++ |
| 19:04 |
hmmmm |
i would not call the lighting a hack |
| 19:04 |
Taoki |
Might work. That sadly sounds like something outside of my knowledge however |
| 19:05 |
celeron55 |
well, it's "different", and definitely different as to how the fixed pipeline is meant to be used |
| 19:05 |
Taoki |
hmmmm: It does use vertex colors to brighten / darken entities. Which from what I know aren't their purpose as fas as Irrlicht is concerned. It is something that works, but I don't think vertex colors are optimized for fake light |
| 19:06 |
celeron55 |
i wonder how minecraft does that, or if it has changed the way it does it at any point of development |
| 19:06 |
celeron55 |
i am guessing it at least originally did the same |
| 19:06 |
celeron55 |
these days it might have a shader, but who knows (well, some people do, the source is decompilable) |
| 19:06 |
Taoki |
But... damn it. Can't we just make global peace, implement hardware lighting in MineTest and end workd hunger? :P |
| 19:06 |
celeron55 |
as long as you buy me a new toughbook with recent hardware |
| 19:07 |
celeron55 |
they cost around $4000 |
| 19:07 |
hmmmm |
there are still mods that do use shaders |
| 19:07 |
hmmmm |
for minecraft |
| 19:07 |
Taoki |
A $4000 machine is needed for hardware lighting? |
| 19:07 |
hmmmm |
no, he just wants to go big if he's going new |
| 19:07 |
Taoki |
IIRC basic lighting can be done by video cards from 15 years ago |
| 19:07 |
Taoki |
ah :P |
| 19:07 |
celeron55 |
Taoki: i only use laptops that are properly made |
| 19:08 |
celeron55 |
this centrino duo era cf-51 is one |
| 19:08 |
Taoki |
Even old laptops should allow hardware lighting, otherwise nearly no 3D game would work |
| 19:08 |
celeron55 |
and doesn't cost much |
| 19:08 |
celeron55 |
of course it allows |
| 19:08 |
celeron55 |
but you already know the problems of shaderless lighting |
| 19:09 |
Taoki |
Yeah. That's the one big problem |
| 19:09 |
celeron55 |
this also does run shaders, but it makes drawing polygons 5x slower |
| 19:09 |
celeron55 |
which makes minetest unplayable |
| 19:09 |
hmmmm |
can't shaders be used only on animated meshes? |
| 19:09 |
celeron55 |
yes |
| 19:09 |
celeron55 |
it would most likely work |
| 19:09 |
hmmmm |
that should be done.. |
| 19:10 |
Taoki |
Still, it would seem we have at least 3 reasons to want hardware lighting: It's directional which in the long run will be a LOT more beautiful, it's needed to use other effects in minetest (material colors, parallax maps, etc), and now we discover it's needed for meshes to ce lit properly |
| 19:10 |
hmmmm |
the world mesh is huge and unwieldy |
| 19:10 |
Taoki |
I can't help much, already tried to use such lighting today. Though if I can do anything about it that I can understand I gladly will |
| 19:11 |
VanessaE |
what happens if the player's hardware doesn't support the lighting model you describe? Will it just revert back to the existing model? |
| 19:11 |
Taoki |
But it seems the brainstorming goes around how to make hardware sunlight not shine in caves |
| 19:11 |
hmmmm |
when someone has a disagreement on how something should be done, it's either made an option or they make a fork |
| 19:11 |
Calinou |
if there is a fallback that does not advantage players (*cough* quake 3 *cough*), it would be ok |
| 19:11 |
* Calinou |
remembers vertex lighting |
| 19:11 |
Taoki |
VanessaE: IIRC the only reason a video card wouldn't support hardare lighting is if it's older than 15 years. |
| 19:11 |
Taoki |
At least without shaders that is |
| 19:11 |
hmmmm |
not having hardware lighting isn't the problem though |
| 19:11 |
hmmmm |
it's having it run well |
| 19:12 |
VanessaE |
fair enough. |
| 19:12 |
Taoki |
hmmmm: A fork would be bad in this case. An option would be good |
| 19:12 |
hmmmm |
indeed |
| 19:12 |
Taoki |
hmmmm: The current lighting is a bit problematig for many reasons. Like I said, it keeps other awesome effects from being possible as well |
| 19:12 |
celeron55 |
there really are no problems as long as somebody does the stuff... initially in a fork |
| 19:12 |
celeron55 |
or, well |
| 19:12 |
Taoki |
Another problem: It makes map generation slower, since whenever a new area is created by the mapgen it also sort of bakes its lightmaps |
| 19:13 |
hmmmm |
i don't think updating the lighting really takes that much time |
| 19:13 |
Taoki |
Not that much, but a little bit |
| 19:13 |
hmmmm |
it's just an O(n^3) worst case time |
| 19:13 |
hmmmm |
the mapgen already accesses every node in that manner in several other places |
| 19:13 |
Taoki |
Like I said, I did look into it for more than 2 hours today. The lighting system is very large and widespread... I was falling asleep befroe I understood a bit of it. |
| 19:14 |
celeron55 |
it's not too bad in a background thread, AND baking some kind of lighting in is probably necessary for slow systems anyway |
| 19:14 |
Taoki |
A lot of code files use it in a lot of confusing ways. |
| 19:14 |
Taoki |
true |
| 19:15 |
Calinou |
<hmmmm> there are still mods that do use shaders <hmmmm> for minecraft < my computer doesn't even run them @ 60FPS sometimes :P |
| 19:15 |
Calinou |
java + shaders... |
| 19:15 |
hmmmm |
lol |
| 19:15 |
hmmmm |
shaders are written in GLSL, not java |
| 19:15 |
Taoki |
celeron55: One of my ideas was: Use the current light baking as a mask for hardware lights instead. Right now, the areas lit by MT's light system are basically bright. But instead, I'd say turn them into a mask for a light source. But I wonder if Irrlicht supports that without shaders... probably not |
| 19:15 |
Taoki |
That would fix lights shining in caves |
| 19:15 |
hmmmm |
java is slow because of the memory and slight cpu overhead, shaders are slow because your graphics card sucks |
| 19:15 |
celeron55 |
shaders are just as fast "in" java as whatever other language, because they are a language of their own :P |
| 19:16 |
celeron55 |
Taoki: something similar but not exactly like that would of course be possible with fixed pipeline trickery |
| 19:16 |
Taoki |
Other than that, there was a second option: Implement cut lighting, which would also give off dynamic shadows. But imagine that on older hardware... it's not even funny :P So no, not a reliable way, just a stupid thought |
| 19:16 |
celeron55 |
but i don't know if irrlicht is capable of doing such trickery |
| 19:17 |
celeron55 |
maybe would need to go for bare opengl |
| 19:17 |
Taoki |
Nooo, Irrlicht is good. Just might have some small issues on this side |
| 19:17 |
celeron55 |
but that isn't really an option |
| 19:17 |
Taoki |
yeah. I'm happy with Irrlicht personally, if it wasn't for that models would have probably been harder to do |
| 19:18 |
celeron55 |
that is the most considerable benefit |
| 19:18 |
hmmmm |
speaking of irrlicht |
| 19:18 |
hmmmm |
please don't update to 1.8 yet |
| 19:18 |
celeron55 |
also it provides vector math and so |
| 19:18 |
hmmmm |
or use any 1.8 features |
| 19:18 |
hmmmm |
lots of operating systems don't have 1.8 in their repositories yet |
| 19:19 |
Taoki |
fair enough |
| 19:19 |
celeron55 |
i wonder how we should decide that |
| 19:19 |
celeron55 |
for the whole existence of minetest thus far, a new enough irrlicht has been found even in debian stable |
| 19:20 |
celeron55 |
debian stable isn't going to go for 1.8 in a LONG time |
| 19:20 |
Calinou |
hmmmm: 570gtx doesn't suck |
| 19:21 |
Taoki |
If we don't need 12.8 features, just not use them then. Should be compatible with .17 I imagine |
| 19:21 |
hmmmm |
lol, you were NOT having shader problems with that |
| 19:21 |
Calinou |
using glsl shaders in a java game is bad.. the programming language of the game matters |
| 19:22 |
hmmmm |
it's likely that the shaders were just poorly coded |
| 19:22 |
hmmmm |
or maybe tries to do too much |
| 19:22 |
celeron55 |
it's funny how everybody blames java for every problem in minecraft |
| 19:22 |
hmmmm |
or maybe you have unrealistic framerate expectations |
| 19:22 |
Calinou |
java does make things slower: usually about 20% |
| 19:22 |
hmmmm |
after Jeb took over, supposedly things got faster |
| 19:22 |
Calinou |
not really :P |
| 19:22 |
Calinou |
server takes more and more bandwidth/CPU |
| 19:23 |
hmmmm |
yeah but look at how much it does |
| 19:23 |
Calinou |
yey, smoke factory! |
| 19:23 |
celeron55 |
i haven't really even touched minecraft after jeb took over |
| 19:23 |
Calinou |
i can mine and build shit in a game that eats 100% of my cpu! |
| 19:24 |
hmmmm |
i should stop talking and start coding more |
| 19:25 |
hmmmm |
my hands are so cold though |
| 19:25 |
celeron55 |
we all should |
| 19:25 |
* Calinou |
tried to code player yaw smoothing, and miserably failed |
| 19:25 |
Calinou |
i broke everything 8D |
| 19:26 |
celeron55 |
you could just make a wrapping version of SmoothTranslator (content_cao.cpp) and use it |
| 19:28 |
celeron55 |
...a wrapping scalar version |
| 19:28 |
|
rsiska joined #minetest-dev |
| 19:28 |
* Calinou |
never really learned c++ anyway |
| 19:28 |
Taoki |
Well I spoke on #irrlicht about the ahrdware lighting. Shaders are needed to use a mask on surfaces for lights, no other builtin function |
| 19:28 |
Calinou |
no idea what you're talking about :P |
| 19:28 |
Taoki |
So the question is: How slower would a very simple shader be, just enough to mask light sources? |
| 19:28 |
celeron55 |
nothing i said was related to C++ in any way 8) generic programming terms |
| 19:29 |
VanessaE |
celeron55: <offtopic> see #minetest for congestion_settings </offtopic> |
| 19:29 |
Calinou |
Taoki: simple shaders are also much slower on old hardware |
| 19:29 |
Taoki |
They did however suggest another variant: Stencil shadows. But how hard would those be to calculate I wonder :P |
| 19:29 |
Calinou |
even if they do nothing visible. |
| 19:29 |
Calinou |
stencil shadows, rofl |
| 19:29 |
celeron55 |
stencil shadows is a fixed pipeline shadow trick |
| 19:29 |
celeron55 |
i don't even understand it, but some people do 8D |
| 19:30 |
Taoki |
I'd like dynamic shadows in MineTest too, but later on. That's really too much to expect in at least 1-2 years :P |
| 19:30 |
Calinou |
john carmack does, he did awesome stencil shadows for q3a, they just go through walls and move randomly in all directions, other than that they're awesome |
| 19:30 |
celeron55 |
also, it is probably impossible to integrate with the voxel lighting, but dunno |
| 19:31 |
Taoki |
Well the voxel lighting is surely parallel to the hardware lighting, so nothing in one would work in the other it seems |
| 19:33 |
celeron55 |
i can think of many ways to integrate them |
| 19:34 |
Taoki |
Seems I got someone from #irrlicht interested in MineTest a bit... explained them the lighting situation |
| 19:35 |
celeron55 |
they'll say "forget the old hardware and voxel lighting" 8) |
| 19:36 |
Calinou |
#irrlicht must be full of bzip2 devs then, bz2 is african word for "everyone has an i7" :D |
| 19:36 |
Taoki |
I'm sorta tempted to say the same. But I wouldn't want people with old hardware to be disappointed. Though still, those with very very VERY old hardware... well we can't fully support them forever |
| 19:36 |
celeron55 |
anyway, what i'm saying is that apply a shader to the object meshes and we're good to go for a good while |
| 19:37 |
|
Sudi_ joined #minetest-dev |
| 19:37 |
Taoki |
Would be awesome if that would allow directional hardware lights to work :D |
| 19:37 |
|
Orix joined #minetest-dev |
| 19:37 |
|
Orix left #minetest-dev |
| 19:44 |
hmmmm |
erm |
| 19:44 |
hmmmm |
what is this 14:41:55: ERROR[main]: Test (hand_server.count == 1) failed: UASSERT about |
| 19:45 |
hmmmm |
when i compile using the CMAKE_BUILD_TYPE=Debug |
| 19:46 |
hmmmm |
i disabled unit testing but that stuff still ought to be fixed, unfortunately i don't know where to start with that piece of code |
| 19:58 |
celeron55 |
hmmmm: the debug build runs unit tests by default at startup; that is a network test that can fail if the port it happens to use is not available |
| 20:00 |
hmmmm |
so it's not a mistake that it's failing |
| 20:00 |
hmmmm |
hmmm |
| 20:06 |
hmmmm |
erm |
| 20:06 |
hmmmm |
that's not the case apparently |
| 20:07 |
hmmmm |
it seems to fail on line 1455 |
| 20:08 |
|
doserj joined #minetest-dev |
| 20:08 |
hmmmm |
http://pastebin.com/ecqdVfmn |
| 20:09 |
hmmmm |
Handler(server)::peerAdded() with id=2 seems to run after hand_server.last_id == 2 is assrted |
| 20:11 |
celeron55 |
uhm |
| 20:11 |
celeron55 |
dunno |
| 20:11 |
celeron55 |
just --disable-unittests and don't care for now |
| 20:11 |
celeron55 |
(unless you want to diagnose it) |
| 20:50 |
|
serengeor joined #minetest-dev |
| 21:01 |
Taoki |
celeron55: Have you thought what can / should be done about support for real lighting? Curious cuz I'm very interested in this as well for the reasons I listed, and if there's some way I can help make it happen sooner I gladly would (sadly there's still little I can do in the code and after looking today lighting is a very large and complex matter). |
| 21:02 |
Taoki |
My understanding at the current moment is: The only way to keep light from shining indoors / in caves is by using shaders (or stencil shadows which is out of the discussion). That would work, but might be quite slower on older hardware. So I wonder how slow, and on how old hardware? Would it be a compromise that can be made? |
| 21:54 |
celeron55 |
on my hardware, unplayably slow |
| 21:54 |
Taoki |
How old is it, and what are the specs? |
| 21:55 |
celeron55 |
intel gm950 |
| 21:56 |
VanessaE |
I wonder how my old Dell Insipron 9200 would handle this proposal. |
| 21:58 |
celeron55 |
https://github.com/celeron55/minetest/tree/shaders_v4 |
| 21:58 |
celeron55 |
rebased on current master |
| 21:58 |
Taoki |
I think you meant GMA950. But I googles, and it doesn't look that old at all. Problem is it's an Intel video card... and those have problems with everything 3D. I know cuz my first laptop had an Intel video card, and barely any game would run on it well |
| 21:58 |
Taoki |
**googled |
| 21:59 |
celeron55 |
actually |
| 21:59 |
celeron55 |
it's 950gm |
| 21:59 |
celeron55 |
wrong order |
| 21:59 |
Taoki |
My second and current laptop has an ATI Mobility Radeon, and it's very nice. So given that many other games have problems with Intel video cards, I'd say it's not MineTest's fault if something works bad for these. The specifications are good, but IIRC it's just Intel video boards in general |
| 21:59 |
* Taoki |
googles again |
| 22:00 |
celeron55 |
i guess it's the same thing though |
| 22:00 |
celeron55 |
950GM is the actual name of the chop, GMA950 is some marketing term |
| 22:00 |
Taoki |
yeah, shows the same page |
| 22:00 |
celeron55 |
chip* |
| 22:01 |
PsionicProgramme |
Greetings everyone. I would like to help out with a task. |
| 22:01 |
Taoki |
The specs look good for a laptop. But like I said, Intel video cards do not work for games. At least that's what I know, don't wanna misinform if I'm right. I sure was happy when I got rid of my laptop and got one with ATI :P |
| 22:01 |
Taoki |
PsionicProgramme: Hello. Help is always appreciated... what with? |
| 22:02 |
PsionicProgramme |
I am an industry veteran, so the task doesn't really matter. just something to cut my teeth on the codebase. i am very interested in adding AI/mobs at some point, but i would like to start on something small. |
| 22:03 |
Taoki |
PsionicProgramme: There already is a mob framework written in lua, you should check it out on the forums. I heard it's still a bit slow so improvements on making it less CPU intensive might be welcome |
| 22:04 |
celeron55 |
PsionicProgramme: it's really up to what you personally want |
| 22:04 |
Taoki |
celeron55: And nice to hear Kahrl's shader code works with latest master! Maybe that can help with this task. Really hope something in this area will be done... kinda excited now, maybe it will :D |
| 22:04 |
Taoki |
Let me know if I can at least help with testing this some |
| 22:04 |
celeron55 |
i could point you to some boring task but i've done that before to people asking stuff like you and it has turned out people just don't get interested to doing anything that way |
| 22:05 |
celeron55 |
if you insist, i can; but i'd rather not |
| 22:05 |
PsionicProgramme |
waht is the boring task? :D |
| 22:06 |
Taoki |
I can confirm that effect exists on me too. It's hard to work on something I'm not excited on getting done in a code. If I force myself I just feel drained and tired, and don't get much done either. BUT, if that task is something I happen to like too, I can help even if it was started by somoene else |
| 22:08 |
celeron55 |
PsionicProgramme: well, there are roughly a million things here, some of which are approved by some sane person and some not: https://github.com/celeron55/minetest/issues?sort=created&state=open |
| 22:09 |
PsionicProgramme |
I will take a look there just to get an idea of what is out there. I will ping you before I start on anything and at least discuss it with you. |
| 22:10 |
celeron55 |
for example this would be useful, altough usually not visible to anyone: https://github.com/celeron55/minetest/issues/187 |
| 22:11 |
celeron55 |
PsionicProgramme: the other people who are quite authoritative here are thexyz, darkrose, PilzAdam, maybe hmmmm, and to some extent anyone who seems sane |
| 22:12 |
celeron55 |
but what i've seen, the best results come when one plays the game and gets motivation to do something based on that experience |
| 22:13 |
celeron55 |
or hangs around in the community to see what others have in mind |
| 22:13 |
Taoki |
I recommend talking to OldCoder on #minetest too, he seems like a very experienced interested and calculated programmer |
| 22:13 |
* Taoki |
hopes OldCoder will be the 5th to get upstream access |
| 22:13 |
celeron55 |
#minetest is a good place to see what is generally going on 8) |
| 22:16 |
Taoki |
http://i49.tinypic.com/2evyuzq.png Some failure from my experimenting with lighting today. Took a screenshot cuz that sun with a dark atmosphere looks nice... almost like you're on another planet :) |
| 22:25 |
Taoki |
Anyway, this is a very n00b question. But I wonder what shaders take care of exactly, and what they do. Post-processing, or are they hooks to hack into the renderer? I imagine that for instance, light sources are defined in the code, since the function to spawn a light must take place. |
| 22:26 |
celeron55 |
on modern rendering, everything is made by shaders, except the bare polygon smashing |
| 22:27 |
celeron55 |
from fine-tuning vertices to texturing to lighting to post-processing |
| 22:27 |
Taoki |
interesting |
| 22:27 |
Taoki |
Hard to tell how they differ from actual code other than that |
| 22:27 |
celeron55 |
http://tomdalling.com/blog/modern-opengl/01-getting-started-in-xcode-and-visual-cpp/#introducing_glew_glfw_glm |
| 22:28 |
celeron55 |
(that series just started, so there is only that part) |
| 22:32 |
celeron55 |
this is kind of useful http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html |
| 22:32 |
Taoki |
Thanks, that offers more info on them. Funny thing... that says nothing will run on modern openGL without shaders, yet MineTest doesn't have them. Either it uses an old version of openGL or Irrlicht does some magic |
| 22:33 |
Taoki |
I still hope that things like textures, voxels, light sources (added by Irrlicht) stay in the code by default, and shaders only modify them. Since that would be kind of confusing and might make things like lua scripting harder |
| 22:34 |
celeron55 |
i don't know if irrlicht supplies it's own fixed pipeline mimicking shaders for newer opengl or if it always uses the legacy APIs |
| 22:35 |
celeron55 |
i am guessing the latter |
| 22:35 |
Taoki |
http://irrlicht.sourceforge.net/docu/example010.html This might be helpful |
| 22:38 |
Taoki |
Seems there that you specify shader files via Irrlicht functions... looks good |
| 22:39 |
Taoki |
http://www.irrlicht3d.org/wiki/index.php?n=Main.Shaders might also help (still bad at understanding them myself but eh :P ) |
| 22:41 |
Taoki |
Ahhh yes. We need to see if this http://irrlicht.sourceforge.net/forum//viewtopic.php?t=21057 will work on Kahrl's shader implementation. If so, awesome! |
| 22:41 |
celeron55 |
eh |
| 22:42 |
celeron55 |
those are useless |
| 22:43 |
Taoki |
Except bloom and motion blur |
| 22:45 |
Taoki |
Also blur and reflection / refraction for water... how awesome will those be :) |
| 22:45 |
Taoki |
Obviously for those with hardware good enough to handle them. I assume each shader will be made into a setting, so the fancy stuff is fully optional |
| 22:47 |
celeron55 |
when i talk about shaders, i talk about tweaking lighting, tuning contrast and saturation to fit style; shadows, ambient occlusion |
| 22:48 |
Taoki |
That too... those are the most important and prioritary things |
| 22:49 |
Taoki |
The fancy effects can come later. I am interested a lot in them a lot too, but it would be silly to worry about them at this stage. Still thinking about it otherwise though :) |
| 22:51 |
Taoki |
http://www.youtube.com/watch?v=QJ3R0yJMO6U Just to dream about something :P |
| 22:51 |
celeron55 |
also, as for lighting, that means yellowish sunlight and blueish ambient light |
| 22:51 |
Taoki |
Totally |
| 22:52 |
celeron55 |
i don't care about water trickery |
| 22:52 |
celeron55 |
not tasteful at all |
| 22:53 |
celeron55 |
also i don't understand modern games that don't use colors |
| 22:53 |
celeron55 |
they're like black and white these days |
| 22:53 |
jin_xi |
have you seen this: http://www.sea-of-memes.com/LetsCode72/LetsCode72.html |
| 22:53 |
celeron55 |
it's nonsense |
| 22:53 |
Taoki |
I think this will be one of the features that will make MineTest one of the most powerful voxel engines. Many exist at this day (MineCraft, Terasology and all) but none support advanced graphics. MineTest is C++ and Irrlicht wich will allow very modern visuals. There will prolly be no other similar engine to have this in the same way soon |
| 22:53 |
celeron55 |
jin_xi: yes, and? |
| 22:53 |
Taoki |
Especially those written in Java... they have no chance. I saw some shaders for MineCraft, but IIRC java is still too slow (not to say it's bad) |
| 22:54 |
celeron55 |
eh |
| 22:54 |
celeron55 |
shaders are their own language |
| 22:54 |
Taoki |
celeron55: The desaturated atmosphere is usually to give a darkar and more grim / realistic feel. For some games (like GTA4) that fits, but for others no. Depends on theme a lot |
| 22:54 |
celeron55 |
it doesn't fit even gta4 |
| 22:55 |
Taoki |
jin_xi: That screenshot does look pretty impressive. Unless you wonder what FPS so many voxels must be running at :3 |
| 22:55 |
celeron55 |
he says it's running at >100 or something |
| 22:55 |
celeron55 |
but that is completely unimportant, you get FPS by throwing expensive hardware at it |
| 22:56 |
Taoki |
wow, that's pretty crazy if so |
| 22:56 |
Taoki |
True. But the aim in a good code is to give as much FPS with any hardware as technically possible :) |
| 22:56 |
celeron55 |
i'd rather have seen some tasteful rendering for voxels rather than 1 billion plainly rendered ones |
| 22:57 |
jin_xi |
i just think far viewing distance is a nice problem |
| 22:57 |
Taoki |
The tasteful part depends on the textures used and the builds created in-world |
| 22:58 |
Taoki |
jin_xi: True. MineTest has issues with that. It's a sad feeling when I go on a server like RedCrab's (which has some nice buildings) and must choose between barely any drawing distance and view FPS, or seeing all those far cubes but at big performance cost. |
| 22:58 |
Taoki |
Maybe sometime this will get solved too, I hope and think so |
| 23:00 |
Taoki |
http://www.youtube.com/watch?v=QzVELl-ugf8 Title: If MineTest had marching cubes ;) |
| 23:01 |
VanessaE |
nice |
| 23:10 |
Taoki |
Really really eager to see what shaders will do in MineTest. I'm really sure that whatever that is, it's going to look amazing :D Especially with some nice draw distance later on |
| 23:11 |
Taoki |
I think Terasology is the first voxel engine to use post-processing and shaders, but here it should be even more flexible I believe |
| 23:27 |
|
rsiska joined #minetest-dev |
| 23:50 |
|
rsiska joined #minetest-dev |
| 23:50 |
VanessaE |
celeron55: we have consensus: the congestion_setting branch IS an improvement. 2x to 10x faster for some people. No change for others. No regression that I or anyone else can see. Merge that sucker :D |
