| Time |
Nick |
Message |
| 01:31 |
|
kilbith joined #minetest-dev |
| 01:37 |
|
calcul0n__ joined #minetest-dev |
| 03:31 |
|
olliy joined #minetest-dev |
| 03:33 |
|
Lone_Wolf joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:12 |
|
Extex joined #minetest-dev |
| 04:12 |
Extex |
Hello everyone |
| 04:15 |
MTDiscord |
<Jonathon> Hi |
| 04:22 |
Extex |
Got a bunch of screenshots of the shadows, thought I'd share |
| 04:22 |
Extex |
Village shadows https://cdn.discordapp.com/attachments/555039171744628750/851600997259280405/Village_shadows.png |
| 04:22 |
Extex |
A bug I found but still cool https://cdn.discordapp.com/attachments/555039171744628750/851600996588978197/Scuba_Lights.png |
| 04:22 |
Extex |
Ominous building https://cdn.discordapp.com/attachments/555039171744628750/851600995371712533/Ominous_building.png |
| 04:22 |
Extex |
Village Path https://cdn.discordapp.com/attachments/555039171744628750/851600996319887380/Village_path.png |
| 04:28 |
|
specing_ joined #minetest-dev |
| 06:06 |
|
MTDiscord1 joined #minetest-dev |
| 07:29 |
|
sfan5 joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:59 |
|
queria joined #minetest-dev |
| 09:34 |
|
Fixer joined #minetest-dev |
| 09:43 |
|
entuland joined #minetest-dev |
| 10:00 |
nrz_ |
i just tested shadow in ultra high, i don't understand why on a RX 6800 i'm low fps like this, i have no issue on Horizon Zero Dawn and red dead 2 in ultra ... we may have some optimizations to do |
| 10:00 |
nrz_ |
19 fps on one of the most powerful graphic card is very stange |
| 10:00 |
nrz_ |
sorry 35 fps :) |
| 10:00 |
nrz_ |
turning camera is pretty laggy |
| 10:01 |
nrz_ |
in medium it'sp retty fine, 60 fps |
| 10:02 |
nrz_ |
really great work liso for this |
| 10:24 |
MTDiscord |
<Liso> put F6 3 times and take a look in to the drawcalls |
| 10:24 |
MTDiscord |
<Liso> that's our major bottleneck right now |
| 10:53 |
|
entuland_ joined #minetest-dev |
| 10:56 |
|
thmh left #minetest-dev |
| 12:16 |
MTDiscord |
<exe_virus> Yep, draw calls was the major complaint devsh of the irrlichtbaw fork developer. Hence why they switched to Vulcan. He might have some quick tips to help us optimize low hanging fruit |
| 12:25 |
sfan5 |
pretty sure hecktest already commented on low-hanging fruit in one of the issues |
| 12:26 |
MTDiscord |
<exe_virus> I personally know that we should be offloading our animated mesh skinning to the GPU, but that's a different thing entirely |
| 12:28 |
celeron55 |
definitely look up hecktest's recommendations on that, as far as i've seen lately he had the most clue |
| 12:36 |
MTDiscord |
<Liso> yes. IMHO the "easiest" options are. Texture atlas to batch mapblocks and LOD. |
| 12:37 |
MTDiscord |
<Liso> I'm doing some research about batching with texture atlas right now |
| 13:01 |
sfan5 |
there's also some potential for the extra step for shadows, opaque nodes don't need textures so all those can be merged into a single mesh |
| 13:04 |
|
kilbith joined #minetest-dev |
| 13:25 |
kilbith |
I think far-distance mapblocks can be converted into a giant texture and projected on billboard mesh or something |
| 13:26 |
kilbith |
that was the technique used to optimize GTA 5 iirc |
| 13:45 |
pgimeno |
hecktest worked on something similar |
| 13:47 |
pgimeno |
https://irc.minetest.net/minetest-dev/2019-02-08#i_5491806 |
| 13:48 |
|
CeeGee joined #minetest-dev |
| 13:56 |
pgimeno |
similar but not the same, because it uses the perlin noise instead of the actual mapblocks |
| 14:30 |
|
kilbith joined #minetest-dev |
| 14:34 |
|
kilbith joined #minetest-dev |
| 14:44 |
|
Fixer joined #minetest-dev |
| 14:46 |
|
kilbith_ joined #minetest-dev |
| 14:51 |
|
kilbith joined #minetest-dev |
| 14:59 |
|
kilbith joined #minetest-dev |
| 15:02 |
|
kilbith joined #minetest-dev |
| 15:09 |
|
kilbith joined #minetest-dev |
| 15:22 |
|
kilbith joined #minetest-dev |
| 15:44 |
MTDiscord |
<exe_virus> Yeah I had thought about having mapblocks precalculate their side texture (6 textures) whenever they are saved to disk. So when you view far map blocks only the side you are looking at is rendered. It would lower needed bandwidth to send significantly is the thinking |
| 16:17 |
VanessaE |
isn't that more or less how the far map code (the PR that didn't get merged, not farmesh) worked? |
| 16:26 |
|
specing_ joined #minetest-dev |
| 17:39 |
|
GreenXenith joined #minetest-dev |
| 17:40 |
|
MTDiscord joined #minetest-dev |
| 18:08 |
celeron55 |
not really |
| 18:09 |
celeron55 |
between mine and hecks' attempts i was most impressed by hecks' demo of drawing the horizon according to map noise |
| 18:10 |
celeron55 |
but neither really are a solution to the amount of drawcalls |
| 18:10 |
celeron55 |
they're just ways to draw the very far away stuff that most of the time isn't drawn at all now |
| 18:11 |
celeron55 |
what's needed is a way to make the mid range node-by-node stuff be drawn more efficiently on fast GPUs |
| 18:11 |
celeron55 |
and as accurately as before |
| 18:29 |
|
GreenXenith joined #minetest-dev |
| 18:30 |
|
MTDiscord joined #minetest-dev |
| 18:32 |
VanessaE |
celeron55: to be fair, whether or not the drawcalls issue is fixed, the farmap thing was a good idea -- I mean, more draw distance is always a plus |
| 18:33 |
VanessaE |
just means instead of 500 or so meters like the original implementation could do with the then-current rendering behavior, maybe we'd be able to see out to a few km after such a rework :) |
| 18:33 |
celeron55 |
it definitely needs to be able to draw based on noise though |
| 18:33 |
celeron55 |
nobody's going to want to wait for the actual map data to be generated for kilometers |
| 18:34 |
VanessaE |
true |
| 18:35 |
|
Extex joined #minetest-dev |
| 18:35 |
|
Extex joined #minetest-dev |
| 18:41 |
MTDiscord |
<GreenXenith> Anyone have a saved image of hecktest's fardistance experiments? He doesnt like to use persistent image hosts |
| 18:43 |
VanessaE |
I dunno about hecks' method, but hybriddog had something: https://github.com/minetest/minetest/issues/6323 |
| 18:44 |
VanessaE |
(though I guess he didn't provide any reference code |
| 18:44 |
VanessaE |
) |
| 18:49 |
celeron55 |
well that's not really usable, actually updating a saved rendering that far isn't really feasible at any interval |
| 18:54 |
VanessaE |
definitely not. |
| 18:56 |
VanessaE |
your idea of rending based on perlin has its advantages for sure, but it has the drawback of not being able to, for example, show trees and other large-scale coverage since it would be impossible to know where they should be. |
| 18:57 |
VanessaE |
(which, at distance, would basically amount to a change in the color of the far "landscape") |
| 18:58 |
VanessaE |
now, if you have terrain that could theoretically be displayed out that far (i.e. the world has been in use for a while), surely it would be possible to "fill-in" the far render with real terrain (rendered to an image or something else super simple) as it becomes available |
| 18:59 |
VanessaE |
(you'd only do that if the player's just puttering around within the same few mapblocks, building or mining, so that far away mapblocks could be *lazily* loaded and rendered) |
| 18:59 |
MTDiscord |
<Jordach> just ask the fine fellows over at veloren how the hell they managed their farmap |
| 19:00 |
VanessaE |
or, you know, you could just tell us... |
| 19:00 |
MTDiscord |
<Jordach> i know it has a farmap-like implementation |
| 19:00 |
MTDiscord |
<Jordach> but where it is relative to the codebase? no |
| 19:01 |
VanessaE |
someone's bound to tell me that I don't know wtf I'm talking about, so but I shouldn't say anything more about this. |
| 19:02 |
VanessaE |
-but |
| 19:05 |
celeron55 |
well you can always somewhat guesstimate what the tree coverage would look like, but the ultimate goal would be to render at node level so far that there's no need to even render with color anymore and you could almost get away with something like a blue tinted heightmap |
| 19:05 |
celeron55 |
in practice, not sure |
| 19:05 |
celeron55 |
i'm betting for good performance it's going to be a lot of stylistic choices |
| 19:06 |
MTDiscord |
<Jordach> little tip, veloren doesn't render trees in it's farmap |
| 19:06 |
MTDiscord |
<Jordach> just the flat out world |
| 19:07 |
MTDiscord |
<Jordach> as a LOD |
| 19:07 |
MTDiscord |
<Jordach> my 1080ti can render well over half the entire server world with decent performance |
| 19:08 |
celeron55 |
but it won't render anything player built at big distances, right? |
| 19:09 |
celeron55 |
well given it's an RPG there's probably not much player built anyway |
| 19:11 |
MTDiscord |
<Jordach> actually in the most recent patch you can actually build build |
| 19:11 |
MTDiscord |
<Jordach> in specific designated areas |
| 19:11 |
MTDiscord |
<Jordach> also it doesn't render surface world towns or decorums |
| 19:12 |
MTDiscord |
<Jordach> just the plain landscape |
| 19:12 |
MTDiscord |
<Jordach> instead the distant chunks that are actually "full size" are sort of faded in |
| 19:12 |
MTDiscord |
<Jordach> so you don't notice the swap from LOD to real terrain |
| 19:15 |
celeron55 |
well obviously |
| 19:16 |
MTDiscord |
<Jordach> to tell you the truth however |
| 19:17 |
MTDiscord |
<Jordach> it would be far easier to implement a network only MT client than try and fix the approaching 10 year old technical debts |
| 19:18 |
MTDiscord |
<Jordach> the only winning move is not to play |
| 19:19 |
|
kilbith joined #minetest-dev |
| 19:20 |
|
kilbith joined #minetest-dev |
| 19:43 |
celeron55 |
rewrite being better is usually a fallacy |
| 19:44 |
MTDiscord |
<Jordach> this may be true but since the minetest protocol is basically a glorified duck test |
| 19:44 |
celeron55 |
heavy rework is usually much more efficient |
| 19:44 |
celeron55 |
light rework on the other hand is often inefficient |
| 19:44 |
MTDiscord |
<Jordach> it's like the original Build engine Ace of Spades vs the OpenSpades from scratch client |
| 19:46 |
celeron55 |
i'd have to study those better in order to comment on that analogy |
| 19:59 |
|
kilbith joined #minetest-dev |
| 20:08 |
|
kilbith joined #minetest-dev |
| 20:21 |
MTDiscord |
<Jordach> Build engine was designed by Silverman for Duke 3D type games using its built in voxels |
| 20:22 |
MTDiscord |
<Jordach> OpenSpades is basically a brand new implementation of everything within minus any original technical debt |
| 20:23 |
nrz_ |
Jordach you mean rewrite the whole client and just have a library ? it's not so easy because most of the engines, OSS or not, doesn't have a lua stack in mind |
| 20:27 |
MTDiscord |
<Jordach> Outright a new client only |
| 20:27 |
MTDiscord |
<Jordach> It is simply the multiplayer portion only and contains the IrrMT as the built in server |
| 20:29 |
MTDiscord |
<Jordach> But for the most part acts exactly as a current client would |
| 20:29 |
|
kilbith joined #minetest-dev |
| 20:56 |
|
kilbith joined #minetest-dev |
| 21:02 |
|
kilbith_ joined #minetest-dev |
| 21:05 |
|
Extex joined #minetest-dev |
| 21:13 |
|
entuland_ joined #minetest-dev |
| 21:29 |
|
kilbith joined #minetest-dev |
| 21:39 |
|
Extex joined #minetest-dev |
| 21:45 |
|
kilbith joined #minetest-dev |
| 21:52 |
|
kilbith_ joined #minetest-dev |
| 22:04 |
|
v-rob joined #minetest-dev |
| 22:39 |
MTDiscord |
<exe_virus> Hurm, well at far distances noise can definitely work, but I would argue we could do better, because we might have to do better. like that only works for mapgen v7 |
| 22:42 |
v-rob |
I think an inherent problem with a lot of far-view ideas (say, the farmesh) is that they don't work with Lua mapgens. |
| 22:43 |
MTDiscord |
<exe_virus> Right, ideally we would use a generated world for fargen, but we get into the issue of the world isn't generated yet |
| 22:43 |
MTDiscord |
<exe_virus> Perhaps we could do it with sscsm? |
| 22:44 |
v-rob |
It certainly isn't feasible to wait for the world to generate, especially with slower Lua mapgens. |
| 22:44 |
MTDiscord |
<exe_virus> So each server/game could write their own .Lua fargen? |
| 22:44 |
MTDiscord |
<exe_virus> Because it will have to be tailored to each server's style or game's style |
| 22:45 |
v-rob |
I guess the feasibility of such a thing would depend on the complexity of the far-viewer |
| 22:47 |
MTDiscord |
<exe_virus> Right, I figure each mapgen would just have to publish it's fargen equivalent |
| 22:47 |
MTDiscord |
<exe_virus> Decorations couod be registered with their fargen texture so that fargen knows how to place them |
| 22:49 |
|
loggingbot_ joined #minetest-dev |
| 22:49 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ |
| 22:49 |
MTDiscord |
<exe_virus> The only piece remaining is areas that have been generated before. Those would have a fargen texture cached on each map update (or periodically) and sent to the client. When a client receives a "real texture" they replace that part of their fargen with the texture. |
| 22:49 |
MTDiscord |
<exe_virus> Also, we'd want the fargen textures to only update like every second and just move relative to the player during that time |
| 22:49 |
MTDiscord |
<exe_virus> But that's just my take on it from a high level standpoint |
| 22:55 |
|
kilbith joined #minetest-dev |
| 23:03 |
|
v-rob joined #minetest-dev |
