Time Nick Message 04:12 Extex Hello everyone 04:15 MTDiscord 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 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 put F6 3 times and take a look in to the drawcalls 10:24 MTDiscord that's our major bottleneck right now 12:16 MTDiscord 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 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 yes. IMHO the "easiest" options are. Texture atlas to batch mapblocks and LOD. 12:37 MTDiscord 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: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:56 pgimeno similar but not the same, because it uses the perlin noise instead of the actual mapblocks 15:44 MTDiscord 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? 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: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:41 MTDiscord 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 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 i know it has a farmap-like implementation 19:00 MTDiscord 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 little tip, veloren doesn't render trees in it's farmap 19:06 MTDiscord just the flat out world 19:07 MTDiscord as a LOD 19:07 MTDiscord 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 actually in the most recent patch you can actually build build 19:11 MTDiscord in specific designated areas 19:11 MTDiscord also it doesn't render surface world towns or decorums 19:12 MTDiscord just the plain landscape 19:12 MTDiscord instead the distant chunks that are actually "full size" are sort of faded in 19:12 MTDiscord so you don't notice the swap from LOD to real terrain 19:15 celeron55 well obviously 19:16 MTDiscord to tell you the truth however 19:17 MTDiscord 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 the only winning move is not to play 19:43 celeron55 rewrite being better is usually a fallacy 19:44 MTDiscord 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 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 20:21 MTDiscord Build engine was designed by Silverman for Duke 3D type games using its built in voxels 20:22 MTDiscord 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 Outright a new client only 20:27 MTDiscord It is simply the multiplayer portion only and contains the IrrMT as the built in server 20:29 MTDiscord But for the most part acts exactly as a current client would 22:39 MTDiscord 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 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 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 So each server/game could write their own .Lua fargen? 22:44 MTDiscord 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 Right, I figure each mapgen would just have to publish it's fargen equivalent 22:47 MTDiscord Decorations couod be registered with their fargen texture so that fargen knows how to place them 22:49 MTDiscord 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 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 But that's just my take on it from a high level standpoint