| Time |
Nick |
Message |
| 00:46 |
|
Ruslan1 joined #minetest-dev |
| 01:31 |
|
ANAND_ joined #minetest-dev |
| 02:21 |
|
Cornelia joined #minetest-dev |
| 02:45 |
|
ssieb joined #minetest-dev |
| 03:41 |
|
Cornelia joined #minetest-dev |
| 06:01 |
|
Lymkwi joined #minetest-dev |
| 07:20 |
|
ssieb joined #minetest-dev |
| 07:39 |
|
opal joined #minetest-dev |
| 07:59 |
|
YuGiOhJCJ joined #minetest-dev |
| 08:04 |
|
YuGiOhJCJ joined #minetest-dev |
| 08:44 |
|
Darcidride joined #minetest-dev |
| 09:10 |
|
Fixer joined #minetest-dev |
| 09:13 |
|
Gael-de-Sailly joined #minetest-dev |
| 09:53 |
|
Calinou joined #minetest-dev |
| 10:32 |
|
Taoki joined #minetest-dev |
| 11:16 |
|
Calinou joined #minetest-dev |
| 12:05 |
|
wowaname joined #minetest-dev |
| 12:21 |
|
YuGiOhJCJ joined #minetest-dev |
| 13:20 |
|
calcul0n joined #minetest-dev |
| 13:29 |
|
jas_ joined #minetest-dev |
| 13:30 |
|
Calinou joined #minetest-dev |
| 13:31 |
jas_ |
if anyone is interested, it appears the behavior of sneak jumping has changed between 0.4.17 and 5.0.0-dev, such that one may now sneak jump up sheer cliffs and thin air (here is a demonstration: https://www.youtube.com/watch?v=U2fzhg8aWKY ) |
| 13:42 |
|
Jordach joined #minetest-dev |
| 13:44 |
|
Fixer joined #minetest-dev |
| 13:55 |
jas_ |
turns out one doesn't need to be near a node, just 'air' will do: https://www.youtube.com/watch?v=72Dryx8YeWY |
| 14:14 |
Shara |
Using which exact settings? |
| 14:14 |
Shara |
It does not seem to happen for me using new or old move |
| 14:23 |
jas_ |
i'm not sure, i'll have to look -- thank you for testing. |
| 14:24 |
jas_ |
it's possible that the speed of crouch or jump height is non-default |
| 14:24 |
jas_ |
can you try https://github.com/jastevenson303/sneak_jump mod? |
| 14:25 |
jas_ |
it doesn't happen in stable, and i test it every so often to check for changes |
| 14:25 |
jas_ |
so it is new |
| 14:25 |
jas_ |
(i think) |
| 14:25 |
jas_ |
i will look and report back -- thank u again |
| 14:25 |
|
tenplus1 joined #minetest-dev |
| 14:27 |
tenplus1 |
hi folks, is there any reason why Minetest 0.4.17 uses 6% of my CPU just sitting on the main menu (clouds disabled) ???? |
| 14:35 |
|
calcul0n joined #minetest-dev |
| 14:39 |
|
tenplus1 left #minetest-dev |
| 14:47 |
|
jas_ joined #minetest-dev |
| 15:25 |
rubenwardy |
merging web#143 in 5 |
| 15:25 |
ShadowBot |
https://github.com/minetest/minetest.github.io/issues/143 -- Update gallery images by Treer |
| 15:33 |
|
Fixer joined #minetest-dev |
| 15:40 |
|
Fixer joined #minetest-dev |
| 15:57 |
|
Calinou joined #minetest-dev |
| 16:07 |
|
Krock joined #minetest-dev |
| 16:21 |
|
YuGiOhJCJ joined #minetest-dev |
| 16:25 |
|
Fixer joined #minetest-dev |
| 16:29 |
|
Fixer joined #minetest-dev |
| 16:38 |
Krock |
Android startup crash fix incoming |
| 16:47 |
Krock |
#7753 |
| 16:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/7753 -- Fix temporary path crash in TestAuthDatabase by SmallJoker |
| 16:53 |
|
paramat joined #minetest-dev |
| 16:53 |
paramat |
Krock is my hero ^_^ |
| 17:09 |
|
calcul0n joined #minetest-dev |
| 17:12 |
|
Calinou joined #minetest-dev |
| 17:56 |
|
calcul0n joined #minetest-dev |
| 18:08 |
|
Krock joined #minetest-dev |
| 18:20 |
|
Cornelia joined #minetest-dev |
| 18:23 |
|
Fixer joined #minetest-dev |
| 18:30 |
|
Fixer joined #minetest-dev |
| 18:32 |
paramat |
rubenwardy was web#143 merged? |
| 18:32 |
ShadowBot |
https://github.com/minetest/minetest.github.io/issues/143 -- Update gallery images by Treer |
| 18:33 |
paramat |
+1 |
| 18:51 |
|
Fixer joined #minetest-dev |
| 18:51 |
|
mrchiantos joined #minetest-dev |
| 18:54 |
|
Calinou joined #minetest-dev |
| 18:56 |
|
Calinou joined #minetest-dev |
| 19:17 |
|
indiana joined #minetest-dev |
| 20:02 |
|
Gael-de-Sailly joined #minetest-dev |
| 20:24 |
|
hecks joined #minetest-dev |
| 20:26 |
paramat |
#7750 +1 good PR please review |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/7750 -- Fix stretched stars, render stars before sun and moon by random-geek |
| 20:34 |
|
indiana joined #minetest-dev |
| 20:39 |
hecks |
Does minetest have some kind of minimal hardware spec for graphics PRs? |
| 20:42 |
hecks |
I'm in the mood to work on the renderer but I need to know what's allowed and what's not |
| 20:47 |
sfan5 |
it shouldn't break android support (which is gles 1.0) |
| 20:47 |
|
Ruslan1 joined #minetest-dev |
| 20:48 |
hecks |
would it be reasonable to bump this up to 2.0 (that is, require shaders) if the benefits were very well worth it? |
| 20:49 |
sfan5 |
shaders don't work on android yet, but there's a pr |
| 20:49 |
sfan5 |
IMO yes |
| 20:49 |
hecks |
my line of thinking is, if a phone is good enough to render the amount of geometry MT pushes anyway, it probably supports shaders |
| 20:50 |
hecks |
the other question I've got is vram, nice things like atlasing could potentially increase the vram requirement |
| 20:52 |
hecks |
worst case one *could* keep the old code as fallback but that's a burden in itself |
| 20:52 |
sfan5 |
oh no dont add texture atlases, we had those before and they were removed |
| 20:52 |
sfan5 |
the reason why android currently uses gles 1.0 is because nobody wanted to make gles 2 work |
| 20:52 |
hecks |
what were the issues with atlases, then? |
| 20:57 |
sfan5 |
http://irc.minetest.net/minetest-dev/2013-02-28#i_2902151 http://irc.minetest.net/minetest-dev/2013-04-01#i_2974754 http://irc.minetest.net/minetest-dev/2013-12-10#i_3481417 |
| 20:57 |
sfan5 |
the gist of is roughly: it broke things, didn't work correctly and hindered some new features |
| 21:00 |
hecks |
okay I get it |
| 21:00 |
hecks |
and now that I think of it, texture pack mods completely rule out atlasing |
| 21:01 |
hecks |
cause you can replace any one node with a 4096x4096 tile and the packer wouldn't know what to do with that |
| 21:01 |
hecks |
CM::updateDrawList() count in profiler is the dreaded drawcall counter here, right? |
| 21:02 |
sfan5 |
i think so, yes |
| 21:02 |
sfan5 |
but you should measure it yourself instead of believeing me |
| 21:03 |
hecks |
well I don't see anything else that looks like one |
| 21:03 |
rubenwardy |
Texture atlases would be good |
| 21:03 |
rubenwardy |
Our implementation was broken, a new one might actually work |
| 21:03 |
hecks |
okay but what about the size problem I just mentioned? |
| 21:03 |
rubenwardy |
No idea |
| 21:04 |
hecks |
HD packs, while I think they're stupid, kinda wreck this idea |
| 21:04 |
rubenwardy |
It could be disabled for thar |
| 21:04 |
sfan5 |
not only hd packs, normal mods might use 32x mixed with 16x |
| 21:04 |
sfan5 |
surely you can make a packer that can place varying texture sizes |
| 21:05 |
hecks |
rather than disabled I'd put a limit on it and provide some options |
| 21:05 |
hecks |
surely you can, but there's diminishing returns from making "atlases" of less than 10 textures |
| 21:05 |
hecks |
also atlasing the way I'm thinking would require pixel shader... hence my questions about gl earlier |
| 21:06 |
hecks |
in any case I don't think drawcalls (state changes) are the bottleneck here so in that case atlasing is the least concern |
| 21:07 |
hecks |
sure, a great implementation would cut some worlds' rendering to one dispatch, if vertex count allows... but that's overkill |
| 21:09 |
hecks |
the rest of the improvements I'm thinking of do not require shaders or extra memory |
| 21:09 |
hecks |
and that is; better meshing and mapblock LODs |
| 21:10 |
hecks |
LODs might require some thinking about how they're sent, though |
| 21:21 |
sfan5 |
merging #7750 in 10 mins |
| 21:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/7750 -- Fix stretched stars, render stars before sun and moon by random-geek |
| 21:34 |
|
paramat joined #minetest-dev |
| 21:41 |
paramat |
ooh LOD. have you seen the farmap PR? |
| 21:42 |
paramat |
#3502 |
| 21:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/3502 -- Far map and improved map transfer and rendering (WIP) by celeron55 |
| 21:43 |
paramat |
video https://www.youtube.com/watch?v=gQ8fo5VBKEM |
| 21:52 |
|
Ruslan1 joined #minetest-dev |
| 21:53 |
paramat |
hecks , about requiring pixel shader, many desktop MT users turn the basic shaders (the master checkbox in settings) off because it significantly hits FPS |
| 21:53 |
|
Ruslan1 joined #minetest-dev |
| 21:54 |
hecks |
well it's okay |
| 21:55 |
hecks |
and farmap is a step in the right direction |
| 21:56 |
hecks |
Now consider the following: https://pastebin.com/ZAy1TKWz |
| 21:59 |
sfan5 |
> - Let modders specify if a node is used for terrain, or if it's manmade, and if it should be a light source |
| 21:59 |
sfan5 |
this is already a thing |
| 21:59 |
hecks |
sure, but specifically for LODs |
| 22:00 |
hecks |
read the line right under it |
| 22:00 |
sfan5 |
> - Also let node-modifying code specify if a change is important |
| 22:00 |
sfan5 |
but why do we need this? |
| 22:00 |
hecks |
to avoid unnecessary LOD updates |
| 22:01 |
hecks |
if I build a mesecons machine for sieving seeds and ethereal bones, which does a node dig and place every step |
| 22:01 |
hecks |
the LOD, seen from a kilometer, should probably ignore it |
| 22:02 |
hecks |
or, at least, defer the LOD update of said block until the server has absolutely bugger all to do |
| 22:02 |
sfan5 |
sure |
| 22:02 |
hecks |
so what do you think of this proposal? |
| 22:02 |
sfan5 |
that does not require modders to specify importance though, you can just do it based on distance |
| 22:02 |
sfan5 |
sounds useful to me |
| 22:02 |
paramat |
this looks very interesting. the only suggestion i'm not keen on is optionally specifying if a node is for terrain or manmade or light source. however that can be guessed from 'is_ground_content' and 'light_source' nodedefs |
| 22:03 |
hecks |
more like optionally overriding it |
| 22:03 |
hecks |
case in point; my dynlight hack |
| 22:03 |
hecks |
that should not trigger LOD updates |
| 22:04 |
paramat |
and i'm not keen on treating manmade structures different from terrain and using sprites for them. there is no clear distinction anyway |
| 22:04 |
hecks |
at the same time, someone, ten years from now, may make themselves a huge VAO building megastructures with its lua AI |
| 22:05 |
hecks |
and it would be nice to specify that this *should* update LODs |
| 22:05 |
hecks |
as for manmade structure and deco tagging; this is for imposters |
| 22:05 |
hecks |
imposters would be rendered as flat quads rather than voxels, at a super, super far distance |
| 22:06 |
hecks |
either as mapblock-sized cross sections containing a snapshot of player buildings on them |
| 22:06 |
hecks |
or as individual billboards depicting decos, especially in far off "virgin" mapblocks |
| 22:07 |
hecks |
another reason for using imposters is that very far, low res blocks would not be able to render some features correctly, like trees |
| 22:07 |
hecks |
or certain player structures |
| 22:08 |
Jordach |
farmap is an excellent idea on paper, horrendous to maintain and use in practice |
| 22:08 |
hecks |
imposters would help with that |
| 22:08 |
hecks |
talking about c55's farmap or the proposal? |
| 22:08 |
Jordach |
why not both |
| 22:08 |
paramat |
well, for my first point i should say 'unsure about' not 'not keen on' |
| 22:09 |
hecks |
well I say it's a vital feature |
| 22:09 |
Jordach |
farmap relied on knowing the server seed |
| 22:09 |
hecks |
there's nothing wrong with that; but my proposal puts the burden of LODs on the server |
| 22:10 |
hecks |
which, as I mentioned, is about 15% extra work and no more (because math) |
| 22:10 |
Jordach |
then you've got the serialisation of meshes to deal with, whats the format, what's the vertice/tri colours, whats the data stored as |
| 22:10 |
hecks |
you do not send meshes; vertex colors are sampled client side from a palette that the server gives you |
| 22:10 |
hecks |
with CID as the index |
| 22:11 |
Jordach |
then you have to store those meshes in server memory on machines that may have as little as 1GB |
| 22:11 |
paramat |
yes sprites for decos seems potentially good |
| 22:11 |
hecks |
you don't store any meshes |
| 22:11 |
hecks |
you store mapblock "mipmaps", which as I've said, require only 15% extra space |
| 22:11 |
hecks |
just like 2D tex mipmaps will never exceed 33% of the original texture's size, it's a math rule that I forgot the name of |
| 22:12 |
hecks |
all of this is not trivial but also not hard |
| 22:12 |
hecks |
and I bet you my character model's panties that the result will be worth it |
| 22:12 |
paramat |
lol |
| 22:12 |
|
ANAND joined #minetest-dev |
| 22:13 |
Jordach |
i doubt it |
| 22:13 |
Jordach |
LOD on the fly with 10s to 50s of clients will do all but bring the server to it's knees |
| 22:13 |
hecks |
one look at this picture will tell you how serious I am https://a.uguu.se/apfGJjAy78Se_pants.png |
| 22:13 |
Jordach |
and considering we're already dealing with almost automated *clients* wasting disk space |
| 22:13 |
hecks |
except most of those clients will see many of the same mapblocks |
| 22:14 |
Jordach |
which means you still need to store them either as local storage or in RAM |
| 22:14 |
hecks |
and with LODs, the "real" draw distance can be even more limited |
| 22:14 |
hecks |
yes, store them... 15% and no more |
| 22:15 |
Jordach |
15% of texture memory for clients |
| 22:15 |
hecks |
not texture memory |
| 22:15 |
Jordach |
a mega ton of vertice data |
| 22:15 |
hecks |
a tiny bit of texture memory for some sprites |
| 22:15 |
paramat |
i've always wanted LOD because i tend to write mods that create megastructures, or mapgens with huge scales |
| 22:15 |
Jordach |
depending on verbosity |
| 22:15 |
hecks |
no more vertex data than a typical 200 distance scene right now |
| 22:15 |
hecks |
since further mapblocks will be lower res |
| 22:16 |
paramat |
anyway, certainly worth chatting to celeron55 about this sometime |
| 22:16 |
hecks |
I would not be suggesting this if I weren't willing to do the grunt work |
| 22:16 |
hecks |
but with such a big feature, a pre-approval and some assistance would help |
| 22:19 |
paramat |
you might get c55 interested in helping out. when he gets inspired he codes like a monster |
| 22:19 |
hecks |
make that two monsters |
| 22:21 |
hecks |
but tell him to consider quickly, cause I might not have much time to do this |
| 22:21 |
hecks |
if I do, it'll be a marathon |
| 22:23 |
paramat |
i'll link him to this discussion |
| 22:24 |
hecks |
I'm just very, very tired of this: https://a.uguu.se/MjC4x7iZOGwh_aaaaaaaaaaa.png |
| 22:58 |
|
BakerPrime joined #minetest-dev |
