| Time |
Nick |
Message |
| 00:15 |
|
Creeper joined #minetest-dev |
| 00:59 |
|
Creeper joined #minetest-dev |
| 01:36 |
kahrl |
RealBadAngel: I can't comment too much on the shader code itself, but when making a mesh, the tangents should only be calculated if they are needed (parallax mapping is enabled) |
| 01:44 |
|
Wayward_One joined #minetest-dev |
| 01:52 |
|
zat joined #minetest-dev |
| 02:23 |
|
VanessaE joined #minetest-dev |
| 02:33 |
|
Wayward_Tab joined #minetest-dev |
| 02:42 |
hmmmm |
RealBadAngel, what kahrl said and also maybe the code can get cleaned up |
| 02:43 |
hmmmm |
there's lots of dead code, lots of repetitious code, code that doesn't do anything, variables that aren't used anywhere, etc. |
| 02:59 |
|
Wayward_Tab joined #minetest-dev |
| 02:59 |
|
Garth joined #minetest-dev |
| 03:05 |
|
RealBadAngel joined #minetest-dev |
| 03:13 |
hmmmm |
you know what |
| 03:13 |
hmmmm |
doxygen creates complacency |
| 03:14 |
hmmmm |
it encourages low quality documentation that's usually just a matter of repeating the function name in a sentence |
| 03:14 |
hmmmm |
because it looks so complete, people might mistake that class or interface or whatever as actually being documented and not bother to work on it |
| 03:15 |
hmmmm |
i keep noticing this trend in projects using doxygen. |
| 03:25 |
|
Player_2 joined #minetest-dev |
| 03:27 |
RealBadAngel |
hi hmmmm, have you saw my PR? |
| 03:30 |
hmmmm |
yes |
| 03:30 |
hmmmm |
what kahrl said, it would be nice if tangents weren't always recalculated |
| 03:30 |
hmmmm |
also some general code cleanup |
| 03:31 |
RealBadAngel |
i can make recalculating tangents depending on settings, no prob |
| 03:31 |
RealBadAngel |
but what should be cleaned? |
| 03:32 |
hmmmm |
everything... |
| 03:32 |
hmmmm |
[10:43 PM] <hmmmm> there's lots of dead code, lots of repetitious code, code that doesn't do anything, variables that aren't used anywhere, etc. |
| 03:33 |
RealBadAngel |
i cant see there any dead code at all |
| 03:33 |
RealBadAngel |
also no repetitions imho |
| 03:34 |
hmmmm |
are you kidding me... |
| 03:34 |
hmmmm |
I am looking at the most up to date version right? |
| 03:36 |
RealBadAngel |
https://github.com/minetest/minetest/pull/2755/files |
| 03:36 |
hmmmm |
where do i start.. |
| 03:36 |
RealBadAngel |
wheres dead code here? |
| 03:36 |
hmmmm |
alright, going in order: |
| 03:36 |
hmmmm |
actually you know what I'll just write comments about it in the PR |
| 03:37 |
RealBadAngel |
ok that would be better |
| 03:46 |
RealBadAngel |
ok thx, will clean that |
| 03:48 |
RealBadAngel |
but about "Why do all mesh buffers need to be tangent mesh buffers now?", mapblock mesh have to be in tangent space |
| 03:48 |
RealBadAngel |
this applies only for that particular mesh |
| 03:49 |
hmmmm |
there |
| 03:49 |
hmmmm |
I made like 50 comments |
| 03:58 |
|
paramat joined #minetest-dev |
| 04:08 |
|
Hijiri joined #minetest-dev |
| 04:31 |
paramat |
hmmmm, here's the improved biome recalculation logic https://github.com/paramat/minetest/tree/biomerecalc |
| 04:32 |
paramat |
now triggers biome recalculation at 'stone below water' underwater surfaces, so we can have grass or whatever at y=1 and touching the water's edge |
| 04:33 |
paramat |
testing i checked that biome is calculated only 0, 1 or 2 times per node column (rarely 3) so code is fast |
| 04:34 |
paramat |
will apply it to mgv5 and push later |
| 04:36 |
paramat |
i feel this biome api is fairly settled now, but let me know if you think of any necessary improvements |
| 04:40 |
paramat |
i even tried biome blend, but it inevitably makes a large dithered mess in some areas, it reminded me why i don't like blend |
| 04:51 |
|
OldCoder joined #minetest-dev |
| 04:56 |
hmmmm |
how did you implement the biome blending? |
| 04:56 |
hmmmm |
the way I would do it is by adding or subtracting a very small fractional amount to each the humidity and temperature |
| 04:57 |
hmmmm |
i.e. humidity_map[i] + (pcgrand.range(0, 4) - 2) / 4.f |
| 04:57 |
paramat |
yes like that |
| 04:59 |
paramat |
i also tried vertical blend between stacked biomes, by adding a random 0 or 1 to y, also looked bad |
| 05:01 |
hmmmm |
hrmm |
| 05:02 |
hmmmm |
maybe we should be asking the question of what a good looking biome blend would be like |
| 05:02 |
paramat |
yeah |
| 05:02 |
hmmmm |
and then we'll find an algorithm to make that effect |
| 05:02 |
hmmmm |
great job on the biome calculation btw |
| 05:03 |
hmmmm |
that was always one of the most painful parts of mapgen v7 to work on |
| 05:03 |
paramat |
um i did consider a small-scale noise added to heat and humidity to create a small-scale jagged-edge to biome borders |
| 05:03 |
paramat |
cool |
| 05:04 |
hmmmm |
hmm |
| 05:05 |
paramat |
so no dither but a 1-octave noisy edge |
| 05:05 |
hmmmm |
so adding a "detail" noise with a very low spread value |
| 05:05 |
hmmmm |
why 1 octave? |
| 05:05 |
hmmmm |
wouldn't that defeat the purpose |
| 05:05 |
paramat |
performance hehe |
| 05:05 |
hmmmm |
performance is already gone with detail noises |
| 05:05 |
paramat |
doesn't need many octaves if it's got a 8 node scale |
| 05:06 |
hmmmm |
if the spread factor is small enough, you might as well just use point-polled noise calculation |
| 05:07 |
paramat |
you mean no perlinmaps? |
| 05:07 |
hmmmm |
yeah |
| 05:07 |
hmmmm |
i don't think i use perlinmaps for dungeongen |
| 05:07 |
paramat |
yeah those would be wasted for most of the area |
| 05:07 |
hmmmm |
i'd have to argue the threshhold is around ~25 nodes |
| 05:08 |
hmmmm |
at that point it's just a gigantic waste of memory for almost no speed benefit |
| 05:08 |
paramat |
well perhaps i'll trry this to see it |
| 05:08 |
paramat |
(try) |
| 05:14 |
paramat |
BTW for your multistage mapgen idea, i suggest using non-overgenerated noise-generated caves, then you can make it 2-stage not 3-stage |
| 05:15 |
|
kaeza joined #minetest-dev |
| 05:23 |
|
kaeza joined #minetest-dev |
| 05:24 |
|
kaeza_ joined #minetest-dev |
| 05:26 |
paramat |
will push soon https://github.com/minetest/minetest/pull/2756 |
| 05:31 |
hmmmm |
if i'm going to add in all this extra infrastructure, why try to reduce the number of stages? |
| 05:32 |
|
jin_xi joined #minetest-dev |
| 05:32 |
hmmmm |
besides, let's face it, 3d noise-based caves are slllllllowwww |
| 05:32 |
hmmmm |
i would need to have that first stage for dungeons, anyway |
| 05:32 |
paramat |
thought it would make it simpler |
| 05:32 |
paramat |
yeah |
| 05:32 |
hmmmm |
yeah :) heh |
| 05:33 |
hmmmm |
well this effectively kills the "store only map changes" idea |
| 05:33 |
paramat |
ugh good |
| 05:34 |
hmmmm |
I think it's a really great idea though |
| 05:34 |
hmmmm |
it's just too problematic to work properly |
| 05:35 |
paramat |
now pushing 2756 |
| 05:35 |
hmmmm |
looks good to me. |
| 05:36 |
paramat |
ok |
| 05:39 |
paramat |
complete |
| 05:42 |
paramat |
i'll try this new biome blend idea soon |
| 05:42 |
|
paramat left #minetest-dev |
| 05:47 |
|
Hunterz joined #minetest-dev |
| 06:02 |
|
Anchakor joined #minetest-dev |
| 06:33 |
|
johnnyjoy joined #minetest-dev |
| 07:05 |
|
Darcidride joined #minetest-dev |
| 07:05 |
|
Hijiri joined #minetest-dev |
| 07:20 |
|
Darcidride joined #minetest-dev |
| 07:24 |
|
Calinou joined #minetest-dev |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:03 |
|
Hijiri joined #minetest-dev |
| 08:29 |
|
Hijiri joined #minetest-dev |
| 08:36 |
|
Hunterz joined #minetest-dev |
| 08:39 |
|
Hunterz joined #minetest-dev |
| 08:41 |
|
Hunterz joined #minetest-dev |
| 08:41 |
|
Hunterz joined #minetest-dev |
| 10:03 |
|
chchjesus joined #minetest-dev |
| 10:28 |
|
selat joined #minetest-dev |
| 11:20 |
|
Amaz joined #minetest-dev |
| 12:00 |
|
proller joined #minetest-dev |
| 12:32 |
crazyR |
could someone provide a hidden formspec type. for providing hidden fields to the on_receive function... i currently do it by "field[3000,0;9,0;hidden_field_name;;hidden_field_data_to_be_sent]" which is a little too hacky in my opinion |
| 12:36 |
|
rubenwardy joined #minetest-dev |
| 12:36 |
rubenwardy |
crazyR, http://rubenwardy.com/minetest_modding_book/chapters/formspecs.html#contexts |
| 12:37 |
rubenwardy |
there's a feature request here: https://github.com/minetest/minetest/issues/1652 |
| 12:40 |
crazyR |
thanks. why didnt i think of that solution above. so simple lol |
| 12:41 |
rubenwardy |
;) |
| 13:24 |
|
Darcidride_ joined #minetest-dev |
| 13:31 |
|
Wayward_Tab joined #minetest-dev |
| 13:31 |
|
Lunatrius` joined #minetest-dev |
| 13:41 |
|
troller joined #minetest-dev |
| 13:45 |
|
jordan4ibanez joined #minetest-dev |
| 13:45 |
|
Wayward_Tab joined #minetest-dev |
| 13:47 |
|
proller joined #minetest-dev |
| 13:48 |
|
zat joined #minetest-dev |
| 13:54 |
|
proller joined #minetest-dev |
| 14:08 |
|
Wayward_Tab joined #minetest-dev |
| 14:13 |
|
Darcidride joined #minetest-dev |
| 14:14 |
|
Darcidride joined #minetest-dev |
| 14:14 |
Megaf |
kahrl: you and darkrose has been with minetest for very long now |
| 14:14 |
Megaf |
4 years :) |
| 14:15 |
Megaf |
kahrl: your first commit to minetest. 15/09/2011 |
| 14:15 |
Megaf |
sfan5: 11/09/2011 |
| 14:15 |
Megaf |
very cool |
| 14:25 |
|
Wayward_Tab joined #minetest-dev |
| 14:40 |
|
VanessaE joined #minetest-dev |
| 14:50 |
Calinou |
mine has been in june 2012, I think |
| 14:53 |
Megaf |
24/06/2012 Calinou |
| 14:53 |
Megaf |
Message cleanups (consistency) and prevent /me when not allowed to shout |
| 14:54 |
|
troller joined #minetest-dev |
| 15:10 |
|
Calinou joined #minetest-dev |
| 15:11 |
|
Calinou joined #minetest-dev |
| 15:19 |
|
Calinou joined #minetest-dev |
| 15:46 |
|
hmmmm joined #minetest-dev |
| 15:58 |
|
est31 joined #minetest-dev |
| 16:01 |
|
proller joined #minetest-dev |
| 16:17 |
|
Krock joined #minetest-dev |
| 16:40 |
|
Hunterz joined #minetest-dev |
| 16:50 |
est31 |
anyone to review #2751 |
| 16:51 |
|
SopaXT joined #minetest-dev |
| 16:56 |
|
Hijiri joined #minetest-dev |
| 17:11 |
|
Anchakor joined #minetest-dev |
| 17:23 |
|
Player_2 joined #minetest-dev |
| 17:25 |
|
MinetestForFun_ joined #minetest-dev |
| 18:22 |
|
MinetestForFun joined #minetest-dev |
| 18:25 |
|
TheWild joined #minetest-dev |
| 18:29 |
|
RealBadAngel joined #minetest-dev |
| 18:30 |
RealBadAngel |
hmmmm, here? |
| 18:52 |
RealBadAngel |
conf.example section on shaders is a complete mess |
| 18:53 |
est31 |
bad |
| 18:53 |
est31 |
then perhaps make it better? |
| 18:56 |
RealBadAngel |
i just did that |
| 18:56 |
est31 |
nice |
| 18:57 |
RealBadAngel |
descriptions were once above once below, some of them was completely misplaced |
| 18:58 |
RealBadAngel |
i think ive cleaned all regarding #2755 |
| 18:58 |
est31 |
I'm not sure, I think the descriptions are mostly above? |
| 18:59 |
RealBadAngel |
lookin at the file? dont think so |
| 18:59 |
RealBadAngel |
seems to be random |
| 18:59 |
RealBadAngel |
lookin around ive found out most of them below |
| 19:01 |
RealBadAngel |
which imho is logical, first you should read the name of the setting then what it actually does |
| 19:02 |
est31 |
again, a political issue. |
| 19:02 |
RealBadAngel |
hehe yeah |
| 19:02 |
est31 |
I'm for descriptions being above :) |
| 19:04 |
RealBadAngel |
btw had fps being locked at 60fps lately? |
| 19:04 |
Calinou |
they are since 2012, by my request :P |
| 19:04 |
RealBadAngel |
current code is way faster than before but i cannot realease the lock with settings |
| 19:05 |
RealBadAngel |
i would like to know how much i gained |
| 19:06 |
|
cib0 joined #minetest-dev |
| 19:06 |
Calinou |
fps_max = 1000 |
| 19:06 |
Calinou |
put that in your .conf |
| 19:07 |
RealBadAngel |
tried that already |
| 19:07 |
RealBadAngel |
still locked at 60 |
| 19:08 |
Calinou |
disable vsync forcing |
| 19:08 |
Calinou |
on GNU/Linux: vblank_mode=0 bin/minetest |
| 19:08 |
Calinou |
(it's a variable) |
| 19:11 |
RealBadAngel |
also no change |
| 19:12 |
RealBadAngel |
nvm, 256x TP with all textures using bumpmapping and parallax, all other effects on. it doesnt drop below 60fps |
| 19:12 |
RealBadAngel |
i guess its good enough :) |
| 19:12 |
* VanessaE |
benchmarks the code.. |
| 19:12 |
|
Player_2 joined #minetest-dev |
| 19:12 |
est31 |
press f5 |
| 19:12 |
est31 |
then look for the drawtime |
| 19:13 |
Calinou |
talking about benchmarks: https://attractivechaos.github.io/plb/ |
| 19:13 |
RealBadAngel |
drawtime = 15 |
| 19:13 |
est31 |
15 ms then |
| 19:13 |
Calinou |
that means you have a bit more than 60 possible FPS |
| 19:14 |
Calinou |
drawtime of 16 means ~66.6667 FPS |
| 19:15 |
|
OldCoder joined #minetest-dev |
| 19:18 |
RealBadAngel |
well, disabling or enabling any of the effects seems to have no impact on shown drawtime |
| 19:19 |
|
Amaz joined #minetest-dev |
| 19:19 |
RealBadAngel |
i can see the same time for 16px and no shaders |
| 19:19 |
RealBadAngel |
which doesnt make any sense |
| 19:20 |
|
Mikeonline joined #minetest-dev |
| 19:20 |
Mikeonline |
hi |
| 19:21 |
Mikeonline |
how can i figure out what floods my server with objects at a special block coord. every seconds the server needs to delete objects by ServerEnv |
| 19:21 |
* VanessaE |
continues making some benchmarks of 2755 |
| 19:22 |
RealBadAngel |
VanessaE, ok |
| 19:30 |
|
Hijiri joined #minetest-dev |
| 19:30 |
Mikeonline |
strange. one player had a crippled 2d skin, others had 3d. how can this happen |
| 19:31 |
Mikeonline |
after reconnect of this player it was gone |
| 19:32 |
VanessaE |
Mikeonline: I've seen that bug on my creative server before too. |
| 19:35 |
VanessaE |
RealBadAngel: http://pastebin.com/8XYzaGJc |
| 19:35 |
VanessaE |
there's the results. |
| 19:37 |
VanessaE |
note that for these test, of course all-view-range mode was turned off (I only turned it on for a few seconds to take the linked screenshot) |
| 19:37 |
est31 |
If I just could reproduce the bug locally |
| 19:37 |
VanessaE |
tests* |
| 19:38 |
VanessaE |
est31: I don't think it's possible to reproduce on a local server - I think it depends on there being some moderate amount of ping + server latency |
| 19:39 |
|
Amaz joined #minetest-dev |
| 19:39 |
RealBadAngel |
VanessaE, please alter parallax iterations to 1 |
| 19:39 |
VanessaE |
alter it where? |
| 19:40 |
RealBadAngel |
conf, parallax_occlusion_iterations = 1 |
| 19:40 |
VanessaE |
ok. |
| 19:40 |
|
Wayward_One joined #minetest-dev |
| 19:40 |
RealBadAngel |
before it was just one step, now its default to 4 for better image quality |
| 19:40 |
RealBadAngel |
personally im using 10 |
| 19:41 |
VanessaE |
testing... |
| 19:41 |
RealBadAngel |
i just tried to stress test it and tried with 100 iterations |
| 19:41 |
RealBadAngel |
got 30 fps |
| 19:41 |
Calinou |
4 sounds good |
| 19:41 |
|
cib0 joined #minetest-dev |
| 19:42 |
Mikeonline |
VanessaE: but did not find it? |
| 19:42 |
RealBadAngel |
but for 512px tps one iteration should be good enough |
| 19:42 |
Mikeonline |
VanessaE: i found some entry using function on joinplayer. using minetest after. |
| 19:42 |
RealBadAngel |
with 128 or 256x 3-4 iterations are optimal |
| 19:43 |
Calinou |
how about dynamic iteration count? |
| 19:43 |
Calinou |
and you let user specify a multiplier in conf |
| 19:43 |
Calinou |
that might be tricky to implement |
| 19:43 |
VanessaE |
RealBadAngel: ok with shaders+bumps+parallax, iterations set to 1, 13 GB RAM, 60 fps, but the view range crashed to 35m (I can't see any of the landscape shown in the example screenshot) |
| 19:43 |
Mikeonline |
http://pastebin.com/31jF3WKr can i remove this on leaveplayer? |
| 19:43 |
RealBadAngel |
no way, shaders do not know size of the texture |
| 19:43 |
VanessaE |
make that 62 fps. |
| 19:44 |
est31 |
Mikeonline, where is that code? |
| 19:44 |
est31 |
inside a mod? |
| 19:45 |
RealBadAngel |
Calinou, in shaders texture coords are always in range 0 - 1, no matter the real size of it |
| 19:45 |
|
Wayward_One joined #minetest-dev |
| 19:45 |
|
MinetestForFun joined #minetest-dev |
| 19:46 |
Mikeonline |
est31: yes maybe this code could cause the trouble? just guessing. is there a way in core to figure out what triggers the ServerEnv message? |
| 19:47 |
est31 |
the issue is that too many objects are inside one block, |
| 19:47 |
est31 |
that code isnt that bad |
| 19:47 |
est31 |
its bad yes |
| 19:47 |
est31 |
it can cause problems when a player leaves the game fast enough |
| 19:47 |
VanessaE |
RealBadAngel: second test just to be sure... shaders+bump+parallax, iterations = 1: 14 GB, 39 fps, 74.7m |
| 19:47 |
est31 |
then the player will be logged out |
| 19:47 |
est31 |
and the game will crash |
| 19:48 |
Mikeonline |
but this could not effect the objects? |
| 19:48 |
RealBadAngel |
VanessaE, wonder what slows you down, 512x or too much leaves around |
| 19:49 |
VanessaE |
look at the linked screenshot |
| 19:49 |
Mikeonline |
est31: is there a way to figure out what creates the objects? is a formspec an object too? |
| 19:50 |
est31 |
no |
| 19:50 |
est31 |
in this context, an object is a server active object |
| 19:50 |
est31 |
look out for mods which create entities |
| 19:51 |
VanessaE |
RealBadAngel: http://pastebin.com/h3ZH5CiW (fit those figures into the table) |
| 19:51 |
Mikeonline |
entities as dropped objects only? |
| 19:51 |
|
neoascetic joined #minetest-dev |
| 19:51 |
neoascetic |
option( |
| 19:51 |
neoascetic |
ENABLE_SYSTEM_JSONCPP "Enable using a system-wide JSONCPP. May cause segfaults and other memory errors!" |
| 19:51 |
est31 |
for example |
| 19:51 |
neoascetic |
wow, really? |
| 19:51 |
est31 |
Mikeonline, or mobs |
| 19:51 |
est31 |
neoascetic, yes, there are buggy versions of that library outside |
| 19:51 |
Mikeonline |
est31: http://pastebin.com/jT24trWr i think there is no mob mod |
| 19:52 |
est31 |
like mine the last time I checked |
| 19:52 |
Mikeonline |
is there a way to check out which node-area is affected, fly there and see what happens? |
| 19:52 |
RealBadAngel |
VanessaE, so, with equal nr of iterations it looks like you gained 10fps |
| 19:52 |
est31 |
Mikeonline, scan the code for register_entity |
| 19:52 |
est31 |
yes one idea |
| 19:52 |
Mikeonline |
est31: all mod source? |
| 19:52 |
est31 |
yes |
| 19:53 |
est31 |
for the flying, i'm not sure whether you have to multiply the coordinates with 16 |
| 19:53 |
neoascetic |
got this in logs: NodeResolver: failed to resolve node name 'mapgen_river_water_source' |
| 19:53 |
est31 |
neoascetic, update your minetest game |
| 19:53 |
VanessaE |
RealBadAngel: yeah, there's a significant gain with iterations=1, but as you can see from the screenshot, my texture pack doesn't have anything useful in the parallax maps data such that I would be able to see the difference. I'm only really concerned with the overall performance anyway |
| 19:53 |
Mikeonline |
est31: i will check this out. afk while |
| 19:54 |
RealBadAngel |
VanessaE, with proper maps you will see that. atm it just works |
| 19:55 |
VanessaE |
RealBadAngel: yeah. not that it matters anyway, there's nothing to see in that view - too far away from anything that could show parallax effects anyway. |
| 19:55 |
|
melvin joined #minetest-dev |
| 19:55 |
RealBadAngel |
btw, theres one more test to be done |
| 19:55 |
VanessaE |
yes? |
| 19:55 |
RealBadAngel |
try old code vs new but without shaders |
| 19:55 |
VanessaE |
sure. |
| 19:55 |
VanessaE |
gimme a minute |
| 19:55 |
RealBadAngel |
superb |
| 19:59 |
|
err404 joined #minetest-dev |
| 20:00 |
neoascetic |
est31 I am using the latest master, error still exist in logs |
| 20:03 |
VanessaE |
RealBadAngel: http://pastebin.com/8jYr2tMi |
| 20:03 |
est31 |
weird shouldnt happen |
| 20:04 |
RealBadAngel |
VanessaE, so basically theres no difference without shaders, thats very good |
| 20:04 |
est31 |
neoascetic, minetest, or minetest_game? |
| 20:04 |
RealBadAngel |
and that proved that i was right, not hmmmm |
| 20:04 |
neoascetic |
minetest, without minetest_game |
| 20:04 |
est31 |
update minetest_game then |
| 20:05 |
VanessaE |
RealBadAngel: yeah - the difference seen in the chart is surely statistical noise |
| 20:06 |
neoascetic |
I don't use minetest_game at all, I build server without it. I guess, since minetest_game is just a game and NodeResolver is something engine-related, I shouldn't get this error? |
| 20:06 |
neoascetic |
Here commands I am use to build the server: https://github.com/krondor-game/minetest/blob/docker/Dockerfile#L4-L7 |
| 20:07 |
est31 |
neoascetic, games have to implement the features the engine offers them |
| 20:07 |
VanessaE |
RealBadAngel: at least the differences between the two shaders-only and between the two no-shaders tests are insignificant. |
| 20:07 |
est31 |
if they dont, the games have to get updated |
| 20:08 |
est31 |
tell the game creator to register the mapgen_river_water_source mapgen alias |
| 20:08 |
neoascetic |
I have no games installed <_< |
| 20:08 |
VanessaE |
RealBadAngel: however as you can seethe shaders+bump+para performance does show a significant decrease without that =1 setting --- what was the setting in the old parallax code? |
| 20:08 |
est31 |
so what do you play then |
| 20:08 |
neoascetic |
minimum developer preview |
| 20:08 |
est31 |
thats a game too |
| 20:09 |
VanessaE |
minimal doesn't have river water, does it? |
| 20:09 |
est31 |
no it doesnt have |
| 20:09 |
est31 |
hrmm |
| 20:09 |
est31 |
that has to be fixed |
| 20:09 |
est31 |
thanks neoascetic for pointing out the bug |
| 20:09 |
RealBadAngel |
VanessaE, there was no setting before. old code was just one step. with new ive introduced iterative parallax mapping |
| 20:09 |
neoascetic |
wait a sec, maybe my issue |
| 20:09 |
RealBadAngel |
for better quality |
| 20:10 |
VanessaE |
I'm not sure about that - part of its purpose is to be extremely minimal, only enough nodes to create useful-for-testing terrain? |
| 20:10 |
VanessaE |
RealBadAngel: oh ok. |
| 20:10 |
RealBadAngel |
with setting it to 1 youre close to old parallax code speed |
| 20:11 |
RealBadAngel |
still, theres a loop and conditions, that also affects performance |
| 20:11 |
est31 |
VanessaE, there are two ways to resolve this bug, either require all games to implement river water, and add them to minimal, or to say that river water is optional |
| 20:11 |
est31 |
and to replace the error print |
| 20:11 |
est31 |
err remove |
| 20:11 |
VanessaE |
est31: definitely "optional" imho |
| 20:11 |
VanessaE |
dreambuilder has no use for river water, for example |
| 20:13 |
|
proller joined #minetest-dev |
| 20:14 |
est31 |
how is river water enabled again? |
| 20:15 |
Calinou |
I don't like the idea of river water at all |
| 20:15 |
Calinou |
it adds an unneeded node |
| 20:18 |
est31 |
why not multiple water types? |
| 20:18 |
est31 |
we already have multiple land types |
| 20:18 |
est31 |
dirt, stone, sand |
| 20:18 |
est31 |
gravel |
| 20:18 |
est31 |
clay |
| 20:19 |
VanessaE |
RealBadAngel: also bear in mind: I pulled your PR apparently *just* before you squashed your commits |
| 20:19 |
est31 |
can you make the conf.example cleanup in another PR? |
| 20:20 |
est31 |
or commit |
| 20:20 |
est31 |
or whatever |
| 20:20 |
RealBadAngel |
VanessaE, that doesnt matter |
| 20:20 |
est31 |
discussion on that should be separate |
| 20:20 |
VanessaE |
RealBadAngel: didn't think so. just felt I should mention it. |
| 20:21 |
VanessaE |
est31: as for multiple nodes for a given terrain type, for something like water I just don't see the point - now if you were differentiating between SALT water and FRESH water, that would be different. |
| 20:21 |
VanessaE |
but "river" water may as well be like saying "water with some silt mixed in" |
| 20:21 |
VanessaE |
(which it clearly isn't) |
| 20:21 |
est31 |
basically its that differentiation |
| 20:22 |
VanessaE |
if it's a differentiation between fresh and salt, then the nodes should be so-named, with aliases to the old "water_source" and "water_flowing" names. |
| 20:22 |
VanessaE |
otherwise it is confusing. |
| 20:22 |
est31 |
sounds reasonable |
| 20:23 |
VanessaE |
probably a "salinity" setting should be added to the node defs |
| 20:23 |
Mikeonline |
est31: worldedit uses entity. |
| 20:23 |
est31 |
no thats bad |
| 20:23 |
VanessaE |
I can see the case of a modder wanting to create multiple different-salinity nodes and using those in some potions mod or something |
| 20:23 |
est31 |
what stops you from making a "sand percentage" setting for land nodes? |
| 20:24 |
est31 |
or "gold percentage" |
| 20:24 |
est31 |
thats a nice concept |
| 20:24 |
est31 |
but against voxelisatino |
| 20:24 |
VanessaE |
in theory, nothing - one could already do that now. |
| 20:25 |
est31 |
thats the next logical step |
| 20:25 |
VanessaE |
but in this case, someone has already explicitly made the distinction between salt and fresh |
| 20:25 |
est31 |
? |
| 20:25 |
VanessaE |
the two water types. one is salt, one is fresh so you said. |
| 20:25 |
VanessaE |
salinity affect things like buoyancy and corrosive capability |
| 20:26 |
VanessaE |
affects* |
| 20:26 |
est31 |
yea, and how much sand a block of earth contains affects whether its stable or not |
| 20:27 |
VanessaE |
of course - but so does its rock and other minerals content |
| 20:27 |
VanessaE |
but here, two pretty-much-identical nodes have been defined |
| 20:28 |
VanessaE |
the same argument could have been made were there two types of dirt |
| 20:28 |
VanessaE |
or two types of sand |
| 20:28 |
VanessaE |
but there aren't. |
| 20:28 |
est31 |
there are multiple types of land, why not for water too |
| 20:28 |
est31 |
just because water flows |
| 20:28 |
est31 |
and mixes? |
| 20:29 |
VanessaE |
because two types of water is equivalent to two types of *land nodes* of the same category |
| 20:29 |
VanessaE |
the analogy you're making only works if you also include ice |
| 20:30 |
VanessaE |
then you clearly have two categories of water "terrain" |
| 20:30 |
est31 |
why that |
| 20:30 |
VanessaE |
why not? |
| 20:31 |
VanessaE |
any distinction either of us make is gonna be arbitrary to some degree |
| 20:31 |
est31 |
yes |
| 20:32 |
est31 |
I guess this is one of the reasons why engine development makes more fun than mtgame development |
| 20:32 |
est31 |
less preference discussions :) |
| 20:33 |
VanessaE |
heh |
| 20:42 |
Mikeonline |
going to figure that out tomorrow |
| 20:42 |
Mikeonline |
n8 |
| 20:43 |
|
kaeza_ joined #minetest-dev |
| 20:50 |
RealBadAngel |
https://imgrush.com/moR4koK1-aCs.png |
| 20:50 |
RealBadAngel |
hows that? |
| 20:50 |
VanessaE |
looks too rounded. |
| 20:51 |
VanessaE |
the effect is otherwise good |
| 20:51 |
VanessaE |
imho with something like default textures, it should be made possible to make the parallax edges perfectly straight |
| 20:51 |
RealBadAngel |
without rounding the heightmap white pixels get on the sides of the bricks |
| 20:51 |
VanessaE |
ah |
| 20:51 |
VanessaE |
round it less? :) |
| 20:52 |
RealBadAngel |
map is 256x, had to delete 3 pixels around the bricks then smooth it |
| 20:52 |
VanessaE |
is this something you're doing with the generate-normalmaps feature? |
| 20:52 |
RealBadAngel |
to get rid of white |
| 20:52 |
VanessaE |
ohh |
| 20:53 |
RealBadAngel |
im doing now the map manually in gimp |
| 20:53 |
VanessaE |
ok |
| 20:53 |
RealBadAngel |
code couldnt know that mortar (white) should go deeper |
| 20:54 |
RealBadAngel |
still man has better shape recognition abilities than any code ;) |
| 20:54 |
VanessaE |
true :) |
| 20:57 |
RealBadAngel |
well, i managed to make sharper one |
| 20:57 |
|
nore joined #minetest-dev |
| 20:58 |
RealBadAngel |
hi nore |
| 20:58 |
RealBadAngel |
https://imgrush.com/X00tvnJxKcrh.png |
| 20:58 |
RealBadAngel |
any better? :) |
| 20:59 |
VanessaE |
much. |
| 20:59 |
RealBadAngel |
that looks like a good start for default parallax supporting tp |
| 21:00 |
VanessaE |
yep |
| 21:00 |
RealBadAngel |
lets check lower map resolution |
| 21:03 |
RealBadAngel |
https://imgrush.com/E5oXwGQpQS8D.png <- 32x normal map |
| 21:03 |
VanessaE |
too round. |
| 21:03 |
RealBadAngel |
https://imgrush.com/1wUI_lwZxbWt.png |
| 21:03 |
RealBadAngel |
thats 64x |
| 21:03 |
VanessaE |
64x is still a little too round... is the engine smoothing the maps? |
| 21:03 |
VanessaE |
I mean is it interpolating |
| 21:04 |
RealBadAngel |
all filters are enabled, have to be |
| 21:05 |
VanessaE |
why? |
| 21:05 |
RealBadAngel |
https://imgrush.com/PC0gNTQIybxR.png |
| 21:06 |
RealBadAngel |
64x without filtering |
| 21:06 |
VanessaE |
ah, the moire patterns. |
| 21:06 |
RealBadAngel |
i could eliminate them with much more iterations |
| 21:06 |
RealBadAngel |
but filters are cheaper |
| 21:06 |
VanessaE |
just out of curiosity, what happens with a 16x map and no filter? |
| 21:06 |
RealBadAngel |
lol, just forget it |
| 21:09 |
* VanessaE |
waits for a screenshot :P |
| 21:09 |
* VanessaE |
predicts floating brick faces ;) |
| 21:10 |
RealBadAngel |
https://imgrush.com/hz-gt8FqGPOA.png (thats actually 128x, my fav) |
| 21:10 |
VanessaE |
wize ass ;) |
| 21:11 |
RealBadAngel |
huh, im a bit suprised on 16px |
| 21:11 |
VanessaE |
? |
| 21:11 |
|
Yepoleb joined #minetest-dev |
| 21:11 |
RealBadAngel |
code works nicer than i expected |
| 21:11 |
|
selat joined #minetest-dev |
| 21:11 |
VanessaE |
let's see it |
| 21:12 |
RealBadAngel |
https://imgrush.com/XNmWQ127W9wo.png |
| 21:12 |
VanessaE |
heh |
| 21:12 |
VanessaE |
looks like a cartoon |
| 21:12 |
VanessaE |
and 16x without filters? |
| 21:14 |
RealBadAngel |
https://imgrush.com/5U5-Dvvex4og.png |
| 21:14 |
VanessaE |
ok, so as I figured. |
| 21:14 |
RealBadAngel |
if i could eliminate that pattern it could be perfect |
| 21:14 |
VanessaE |
I wonder if that's a rounding issue |
| 21:15 |
VanessaE |
because, why red-grey-red-grey at the edge? |
| 21:15 |
VanessaE |
it should be all the same color, whichever it is |
| 21:20 |
VanessaE |
quality aside, look again at my benchmarks. why does the engine need 4-5 GB more for bumpmaps (+parallax), on top of almost 10 GB already used for the textures? |
| 21:20 |
VanessaE |
'scuse me, 3-4GB more. |
| 21:21 |
VanessaE |
there are only 1825 normalmap images in the texture pack |
| 21:22 |
RealBadAngel |
propably because of overlays |
| 21:22 |
VanessaE |
mmmh |
| 21:23 |
RealBadAngel |
theres shitload of textures generated by mods |
| 21:23 |
RealBadAngel |
such feature shall be strictly forbidden and using it punished badly |
| 21:23 |
RealBadAngel |
;) |
| 21:23 |
est31 |
so that "improvement" is increasing minetest's memory footage by 50%? |
| 21:23 |
VanessaE |
not. |
| 21:23 |
est31 |
or 30 |
| 21:24 |
VanessaE |
est31: in HDX+dreambuilder yes |
| 21:24 |
RealBadAngel |
which improvement? |
| 21:24 |
RealBadAngel |
bumpmapping? |
| 21:24 |
VanessaE |
but only if you turn everything on |
| 21:24 |
est31 |
ok |
| 21:24 |
est31 |
Ive thought you still were discussing the PR |
| 21:24 |
RealBadAngel |
thats sick engine that allow modders to generate shitload of textures freely |
| 21:24 |
VanessaE |
there needs to be some way for the client to only load textures from disk when they're needed. |
| 21:24 |
est31 |
^ |
| 21:25 |
RealBadAngel |
it should be that way: got an ore? make new texture for it |
| 21:25 |
VanessaE |
and UNload them as appropriate too |
| 21:25 |
RealBadAngel |
those overlays are killing the engine |
| 21:25 |
est31 |
yes |
| 21:25 |
est31 |
its the same as the rotation cache |
| 21:26 |
est31 |
"mesh cache" |
| 21:26 |
RealBadAngel |
thats actually very usefull |
| 21:26 |
RealBadAngel |
but when you had thousands of mesecons nodes instead of single defs |
| 21:27 |
RealBadAngel |
cache grows enormously |
| 21:27 |
est31 |
then make a new drawtype |
| 21:27 |
VanessaE |
wait wait |
| 21:27 |
est31 |
cablelike |
| 21:27 |
RealBadAngel |
thats the ONLY way |
| 21:27 |
VanessaE |
stop talking about new drawtypes |
| 21:27 |
est31 |
hehe |
| 21:27 |
RealBadAngel |
sooner or later it will be done |
| 21:27 |
VanessaE |
figure out the memory efficiently first. |
| 21:28 |
est31 |
yes |
| 21:28 |
est31 |
do both |
| 21:28 |
est31 |
:) |
| 21:28 |
RealBadAngel |
with this single change you will save hundreds of megabytes for sure |
| 21:28 |
VanessaE |
doubt it |
| 21:28 |
RealBadAngel |
i can bet |
| 21:29 |
est31 |
a real good cache would be better I think |
| 21:29 |
VanessaE |
mesecons, technic, etc only have a couple dozen relevant textures with no combine/compositing operators being used |
| 21:29 |
est31 |
one that generates upon request. |
| 21:29 |
VanessaE |
exactly. |
| 21:29 |
est31 |
and off-loads if memory is exceeded |
| 21:29 |
est31 |
either through a setting |
| 21:29 |
RealBadAngel |
too complicated to handle |
| 21:29 |
est31 |
or by monitoring the system |
| 21:30 |
VanessaE |
RealBadAngel: it has to be done. |
| 21:30 |
RealBadAngel |
proper drawtypes will reduce mesh cache, nr of nodedefs, nr of textures needed |
| 21:30 |
RealBadAngel |
also it will be hell faster |
| 21:30 |
VanessaE |
meshgen in one thread (if it isn't already), texture loader + compositor in another, rendering in a third, high-priority one. |
| 21:30 |
RealBadAngel |
same goes for those SICK signs |
| 21:31 |
|
Wayward_One joined #minetest-dev |
| 21:31 |
est31 |
yes, signs need engine support |
| 21:31 |
VanessaE |
those signs ARE sick, but they're not the topic here. |
| 21:31 |
RealBadAngel |
its the very same issue |
| 21:31 |
VanessaE |
no |
| 21:31 |
RealBadAngel |
monstrous ram eaters |
| 21:31 |
VanessaE |
there are no high-resolution textures used for those |
| 21:32 |
VanessaE |
the engine needs to have proper cacheing and ref counting |
| 21:32 |
RealBadAngel |
no, it needs the drawtypes |
| 21:32 |
RealBadAngel |
so cache wont be even needed at all |
| 21:32 |
VanessaE |
if you generate a hundred interrim textures with compositing but you only ever display one, that's 99 textures that just sit there soaking up RAM |
| 21:33 |
RealBadAngel |
cache wont help in such developed places like spawn areas on your worlds |
| 21:33 |
RealBadAngel |
because render will DEMAND all of them at once |
| 21:33 |
VanessaE |
why? |
| 21:33 |
VanessaE |
not all of them are used. |
| 21:33 |
RealBadAngel |
well, most of them |
| 21:34 |
RealBadAngel |
thats why game sits down on its ass at your spawns |
| 21:34 |
VanessaE |
at worst, maybe a quarter of the textures in HDX are being used in my spawn areas |
| 21:34 |
VanessaE |
but not in my test world |
| 21:35 |
VanessaE |
at most there are probably a couple hundred unique textures (after compositing) |
| 21:35 |
VanessaE |
there's no reason that my test would should need 10-14 GB of RAM |
| 21:35 |
|
kaeza joined #minetest-dev |
| 21:36 |
VanessaE |
the same is true for any server or world where the user doesn't spend much time near heavily-developed areas. |
| 21:36 |
est31 |
can you worldedit-cut a spawn area from your server? |
| 21:36 |
VanessaE |
sure, gimme a few minutes. |
| 21:40 |
RealBadAngel |
ha! |
| 21:40 |
RealBadAngel |
got it:) |
| 21:41 |
RealBadAngel |
ladies and gentelmen... here goes 16px texture with 16px normalmap and parallax..... aaaand.... https://imgrush.com/Eo-DY4OBQmnx.png |
| 21:41 |
RealBadAngel |
voila! |
| 21:43 |
VanessaE |
est31: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/creative-spawn.we |
| 21:44 |
VanessaE |
this is roughly 100x100 nodes centered on VE-Creative's spawn |
| 21:45 |
VanessaE |
(which is 2-3 times further out than I can normally see) |
| 21:50 |
VanessaE |
brb |
| 21:50 |
|
cib0 joined #minetest-dev |
| 21:56 |
est31 |
only 68 nodes? |
| 21:56 |
est31 |
that cant be |
| 21:56 |
est31 |
my sed script is wrong |
| 21:56 |
est31 |
cat creative-spawn.we | sed -n 's/.*\["name"\] = "\([^"]*\)".*/\1/p' |
| 21:56 |
est31 |
that should extract all names shouldnt it? |
| 21:57 |
est31 |
hrmm somehow it doesmt |
| 21:57 |
est31 |
doesnt* |
| 21:58 |
est31 |
ah yes |
| 21:58 |
est31 |
limited sed line buffer |
| 21:58 |
est31 |
tr , '\n' < creative-spawn.we > cr does it |
| 21:59 |
est31 |
and then doing the cmd on cr |
| 21:59 |
est31 |
now sort | uniq |
| 21:59 |
est31 |
704 |
| 22:00 |
est31 |
so, 704 different node types, of originally 113045 nodes |
| 22:03 |
est31 |
hehe #2 of the most used node is 14640 moretrees:sequoia_leaves |
| 22:03 |
est31 |
#1 is default:stone ofc |
| 22:03 |
est31 |
#3 is 14250 default:dirt |
| 22:03 |
est31 |
so here we are RealBadAngel |
| 22:09 |
VanessaE |
told ya. |
| 22:09 |
VanessaE |
113045 is too high though, should be more like 16k or so |
| 22:10 |
VanessaE |
or is that a total number of nodes in the file? |
| 22:11 |
est31 |
total number of nodes |
| 22:11 |
est31 |
excluding air |
| 22:12 |
VanessaE |
oh ok |
| 22:14 |
VanessaE |
RealBadAngel: the 16px texture with 16px normals looks very good |
| 22:15 |
RealBadAngel |
https://imgrush.com/d_tRF2SiO3Hq |
| 22:15 |
VanessaE |
NICE |
| 22:15 |
VanessaE |
so what'd you change? |
| 22:15 |
VanessaE |
(also, see est's numbers, above)_ |
| 22:17 |
RealBadAngel |
those numbers doesnt say anything about nr of textures generated, nodedefs etc |
| 22:17 |
RealBadAngel |
which i was on my mind |
| 22:17 |
RealBadAngel |
i had |
| 22:18 |
VanessaE |
actually, they do. at worst, there should be 6 * 704 == 4224 textures in use in that clip |
| 22:18 |
VanessaE |
plus the signs, which there really aren't that many. |
| 22:18 |
VanessaE |
est31: how many are there? |
| 22:20 |
est31 |
VanessaE, https://gist.github.com/anonymous/afc7137fffbef1e2d5b4 |
| 22:20 |
VanessaE |
so around 200 |
| 22:20 |
VanessaE |
that's about what I expected. |
| 22:21 |
VanessaE |
202 of them... so worst case scenario, 4426 unique textures |
| 22:23 |
VanessaE |
more likely, I would assume an average of 2 textures per node, not 6, so closer to 2000 unique textures |
| 22:23 |
VanessaE |
and worst case usage there is 1MB per, so under 2GB |
| 22:23 |
|
paramat joined #minetest-dev |
| 22:24 |
est31 |
paramat, read the chat log about the river mapgen errors neoastetic had |
| 22:25 |
paramat |
already have =) i will add river water to minimal then |
| 22:25 |
VanessaE |
minetestmapper should be able to spit out a complete node list for the entire world (if you give it an empty colors.txt so that they're all undefined) |
| 22:25 |
VanessaE |
(I'm curious how many unique nodes are used in the world) |
| 22:26 |
paramat |
the issue is this one https://github.com/minetest/minetest/issues/1840 harmless and hard to fix apparently |
| 22:26 |
paramat |
the biome api node resolver expects certain nodes |
| 22:27 |
RealBadAngel |
https://imgrush.com/NypL48D75WH8.png |
| 22:27 |
RealBadAngel |
what do you think about adding such normals to mt game? |
| 22:32 |
paramat |
looks like air, stone, water and river water are expected, those are the 4 base terrain nodes |
| 22:34 |
paramat |
possibly also dirt and dirt_with_grass |
| 22:34 |
paramat |
https://github.com/minetest/minetest/blob/master/src/mg_biome.cpp#L133 |
| 22:48 |
RealBadAngel |
VanessaE, i tried makin heightmaps auto generate, but thats not so good |
| 22:48 |
RealBadAngel |
those have to be made based on shapes |
| 22:48 |
RealBadAngel |
so hand made only |
| 22:49 |
VanessaE |
that's what I figured |
| 22:55 |
VanessaE |
RealBadAngel: curious. in that 16px test, what happens if you do iterations=1? |
| 22:55 |
RealBadAngel |
layers |
| 22:55 |
RealBadAngel |
irca 3 layers for scale 0.095 |
| 22:55 |
RealBadAngel |
*circa |
| 22:56 |
VanessaE |
but, are they red-grey (in the case of bricks) or just layers of red brick that would show a jagged edge? |
| 23:01 |
RealBadAngel |
layers of bricks |
| 23:01 |
RealBadAngel |
im workin on the solution |
| 23:01 |
VanessaE |
ok |
| 23:02 |
RealBadAngel |
propably i will need to add some ray marching |
| 23:02 |
VanessaE |
I have a feeling that the only solution that'll result in perfect quality would be an extrude feature based off the heightmaps |
| 23:03 |
VanessaE |
not unlike the one used to generate wielditems before kahrl's rewrite |
| 23:03 |
RealBadAngel |
no, raymarching would be enough |
| 23:03 |
VanessaE |
ok. |
| 23:08 |
RealBadAngel |
16px is not enough for bumpmapping |
| 23:08 |
RealBadAngel |
but luckily we do have rdy code for that :) |
| 23:08 |
RealBadAngel |
https://imgrush.com/br08SqViTF2k |
| 23:09 |
VanessaE |
looks nice actually |
| 23:10 |
VanessaE |
gtg |
| 23:10 |
VanessaE |
bbl |
| 23:10 |
RealBadAngel |
cya |
| 23:38 |
kaeza |
Android port is quite usable now. to whoever it may concern, thank you |
| 23:41 |
kaeza |
just one minor suggestion (I couldn't find how to do it if it's already done): add a button to show the console and reduce (or make configurable) the number of lines of on-screen chat |
| 23:42 |
kaeza |
it occupies almost half the screen on my 4' phone |
| 23:54 |
|
Gethiox joined #minetest-dev |
