Time Nick Message 12:10 MTDiscord but again, hasnt storage become very cheap over the years 12:12 MTDiscord A lot of folks have invested quite a bit in learning it + there are tons of tutorials that will get you started with it quickly 12:12 MTDiscord Try doing that on a piss poor connection + unified inv 12:14 MTDiscord and userd by most of the world? so you ave ready made documentation (to an extant + a lot of tutorials) 13:03 MTDiscord note: message 1 repiles to > > Full HTML/JS would probably 30x the download size of Minetest, would be crazy 13:03 MTDiscord message 2: > Seeing as we are already developing our own markup (formspecs) and styles (formspec styling), we probably shouldn't move to web stuff 13:04 MTDiscord message 3: > until then, forms aren't that bad 13:04 MTDiscord message 4: > the only reason for using these is that they are "standard" 13:06 MTDiscord webdev is bad 13:06 MTDiscord but its what turns the world 13:06 MTDiscord hell, i hate it too 13:06 MTDiscord > A lot of folks have invested quite a bit in learning it + there are tons of tutorials that will get you started with it quickly > and userd by most of the world? so you ave ready made documentation (to an extant + a lot of tutorials) If you argue this way, we can directly go full Minecraft 13:07 MTDiscord well 13:07 MTDiscord > hell, i hate it too Then it is time to reinvent the wheel! 13:07 MTDiscord but why? 13:07 MTDiscord it works, its open source 13:07 MTDiscord There is no issue with replacing JS with Lua for instance 13:07 MTDiscord its well documented 13:07 MTDiscord ye 13:07 MTDiscord lua rocks 13:07 MTDiscord but again 13:07 MTDiscord and then there's no issue with replacing HTML + CSS with better standards 13:08 MTDiscord I'm thinking SVG-like 13:08 MTDiscord arent svg's vector art? 13:09 MTDiscord or am i horribly misnformed/mistaken 13:12 MTDiscord oh 13:12 MTDiscord looks like i was half informed 13:16 pmp-p anything but with proper bidi/ltr/kerning/diacritics support and differential updates (vdom) 13:17 pmp-p or it will be a giant wheel to reinvent 13:17 MTDiscord so some sorta react for mt? 13:21 pmp-p i don't know what react, but a good gui should be asynchronous, updating cost minimal with draw calls batched and should support all types of scripts 13:22 pmp-p and ideally it should compile out of the box in less than 5 minutes 13:24 MTDiscord https://reactjs.org/docs/react-dom.html 13:24 MTDiscord btw, compilation is largely cpu specific 13:25 pmp-p i was more thinking of something ultra-light and C/C++ish like https://lvgl.io/demos 13:27 pmp-p also +1 for markdown instead of html 13:28 MTDiscord you do realise that markdown normally transpiles into html? 13:28 MTDiscord and that you can use raw html in md 13:32 pmp-p html rendering add useless complexity for both machine and human reader, simplistic md rendering should be enough for most use cases http://pmpp.ddns.net/paste/screen/shot-2020-12-08_1607454094.png 13:33 MTDiscord m, and forms? 13:34 rubenwardy using markdown for UI is a terrible idea - markdown is for documentation but you want structure for GUIs 13:35 rubenwardy would be good to get a matrix for existing GUI solutions 13:35 pmp-p excuse me gui is widget stuff, markdown is text display, and the textedit widget is a whole problem on its own 13:36 MTDiscord looks at luacontrollerCode IDE 13:37 pmp-p if you mix all that then that's not a wheel to implements, but a wheelS + the whole vehicule over it 13:37 rubenwardy for GUIs you want to be able to build a tree of UI elements 13:38 rubenwardy a tree because it's easier to layout and structure, and build things from reusable components 13:38 MTDiscord that are ideally client side 13:38 rubenwardy maybe I misunderstand "markdown instead of html" 13:39 pmp-p what i mean is html is a mess because it mixes text + ui widgets 13:39 MTDiscord dont think so, or i do too 13:39 MTDiscord > what i mean is html is a mess because it mixes text + ui widgets so you want model-view-controller to be more seperated? 13:40 rubenwardy oh right 13:40 rubenwardy yeah, I'd like to have data and layout more separate 13:40 rubenwardy MVVM is much nicer than MVC 13:40 MTDiscord huh 13:40 MTDiscord moment 13:41 pmp-p ideally you should have localized text identifiers as numbers , then send you ui widget tree pointing those 13:41 rubenwardy MVVM is when your UI knows about a view model (ie: the data), but the data doesn't know about the view 13:41 pmp-p this way you know what lentgh you have before rendering widgets 13:41 pmp-p and if cesure is required 13:41 MTDiscord ah i see, thanks 13:42 rubenwardy so your UI changes to match the data rather than writing a controller to change the UI 13:42 pmp-p yep that's less network traffic 13:42 rubenwardy however, it's possible to set up MVVM from MVC so this is probably something for later 13:43 MTDiscord hm, i see, i often use php for my web dev, so i am all for tigt integration of view-controller 13:51 rubenwardy My job is writing WPF (with MVVM) and I previously an Android dev (using MVC then MVVM) 13:51 rubenwardy MVVM is so much cleaner to write and much easier to test 13:51 rubenwardy but modders don't care about unit testing 13:54 MTDiscord ah i see 13:54 MTDiscord also 13:55 MTDiscord in an aside 13:55 MTDiscord is it possible to get screen resolution via the api? 14:04 MTDiscord not yet# 14:05 MTDiscord oh, there is something in the works? 14:05 rubenwardy what's your usecase? 14:06 rubenwardy There's debates over how it should be done, just having screensize may not be especially helpful 14:06 rubenwardy for things like showing less detailed GUIs on phones, there could be a boolean field 14:06 rubenwardy also, phones have massive screen resolutions but small screens - so DPI is important 14:07 rubenwardy well, screen res on phones vary a lot 14:07 MTDiscord I have a usecase for it 14:07 MTDiscord HUDs 14:07 MTDiscord say you want an image with 10vh height and 10vh width 14:08 MTDiscord currently impossible without using pixel sizes 14:08 MTDiscord > also, phones have massive screen resolutions but small screens - so DPI is important or you can astract that with rem 14:08 MTDiscord so you shouldnt care about display size/dpi 14:08 MTDiscord player:get_screen_info() returning {width, height, dpi} 14:09 rubenwardy except you should care about display size - there's not much different between two phones of different resolutions, they tend to make GUIs bigger in pixels to be the same size 14:09 MTDiscord but does the client even send the scren data? 14:09 rubenwardy no 16:13 hecks I don't know what you guys are talking about but please do something about the crappy item sprite scaling when you have the chance. 16:51 MTDiscord Regarding phone resolutions: They vary so much that you can still buy smartphones from 2019 with a resolution of 480x854 16:54 MTDiscord Oops mixed up the 2 numbers haha 17:04 lhofhansl !tell hecks to have a look at https://sourceforge.net/p/irrext/code/HEAD/tree/trunk/extensions/scene/IMesh/ 17:04 ShadowBot lhofhansl: O.K. 17:06 hecks lhofhansl: no dice, this only helps with stuff I did in my branch already 17:07 hecks we should look for some more specialized, voxel aware solution 17:08 hecks I think atlasing is going to help us the most if it can be pulled off 17:11 lhofhansl I'm looking for something simple or existing first, that we can get in quickly - like your batching code. 17:11 hecks did you miss the part where all the surrounding issues were eating any gains from it? 17:11 lhofhansl Perhaps :) 17:12 hecks stupid things like cracko(verlay) triggering remeshes 17:13 hecks I already wrote helpers to clobber meshes together efficiently so that's not a problem 17:13 hecks the problem is that it still has a cost and we want to do it as rarely as possible 17:13 hecks any frivolous remesh will hurt ten times as much on a batching branch 17:14 hecks lastly I would really like to try atlasing before merging blocks, it would cull a lot better 17:15 hecks of course it still requires mesh batching code, but perhaps a few extra clever things can be done in this special case 17:15 celeron55 regarding texture atlases, did you know MT had them at a point in time? 17:15 hecks I recall such a thing 17:15 lhofhansl Would need to be done lazily on a separate thread - like meshgen. 17:15 hecks tell me, how were they implemented? 17:16 celeron55 then they were removed because of... i don't even remember why, probably rotten code and nobody wanting to fix it 17:16 lhofhansl Is it still in the git history? 17:16 hecks okay, well, I think I got a plan to do them right, checkout the "optimize map rendering" issue for details 17:16 celeron55 lhofhansl: for sure 17:17 hecks I want to use RTTs and hardware accelerate as much of the process as possible 17:17 celeron55 the TileSpec and such classes were designed to carry texture atlas information with them 17:17 celeron55 it shouldn't be very difficult to implement 17:17 hecks interesting 17:17 hecks I can also utilize the fact that everyone has shaders now, even android clients 17:17 hecks use fragment shader texcoord windowing instead of tessing the geometry to make it work 17:21 celeron55 https://github.com/minetest/minetest/commit/8161ab573fd6f8a45b3986278ce7fc1596140526 17:21 celeron55 for any historians out there 17:22 MTDiscord I think a mode like whitelist must be on default 17:22 MTDiscord That can be needed for new players who will host a server and it makes the game looks... more orginazed? 17:27 celeron55 https://irc.minetest.net/minetest-dev/2013-02-27#i_2901090 17:27 celeron55 ah found something written by no other than myself 17:27 celeron55 hecks: ^ 17:28 celeron55 that's completely irrelevant now of course 17:29 lhofhansl Sorting by material reduces the number of the draw calls for sure! 17:29 celeron55 but it looks like at the time the atlas wasn't useful anymore 17:30 lhofhansl Still... I instrumented that part and using large viewing_ranges can easily lead to 10-15k drawcalls per frame. 17:31 celeron55 well these days people are wanting much larger render distances so there's more importance in optimizations 17:31 lhofhansl Yep... I've been looking at that on both client and server. 17:32 lhofhansl For me it was eye-opening to just compile with MAP_BLOCKSIZE of 32 and see my FPS triple in many cases. And the only difference is fewer drawcalls. I had no idea it's that important. 17:33 rubenwardy > Compiling with MAP_BLOCKSIZE set to 32 (instead of 16) doubles or triples my FPS, and my card it at least 50% busy. (But MAP_BLOCKSIZE is also the unit of map loading/generation so it needs to stay small). 17:33 rubenwardy The map is loaded in chunks, you could reduce that to 2 blocks 17:33 rubenwardy for faster generation 17:33 celeron55 over the years GPUs haven't gotten any faster processing a drawcall, but anything inside the drawcall is much faster now 17:33 rubenwardy also, won't that be a network breaking change 17:33 rubenwardy I guess you could have clients have their own unit of map 17:34 lhofhansl rubenwardy: I tried chunksize=3 but it hardly made a difference. 17:34 rubenwardy like, they could combine MapBlocks into a larger unit for rendering 17:34 rubenwardy could it be the network? 17:35 lhofhansl Doesn't look that way. The loadtime of the map is the same (even with chunksize=5), it 17:35 lhofhansl 's just more choppy. 17:36 lhofhansl And yes, I think client and server could have different block sizes. But that's in the end batching, and atlasing is likely more effective. 17:37 celeron55 decoupling the disk and render sizes should be done on the client anyway i think 17:37 lhofhansl Agreed. 17:38 celeron55 regardless of why or what the sizes should be 17:39 celeron55 but mostly because changing the network protocol doesn't really benefit us, and that already makes batching to be the client's responsibility 17:39 lhofhansl So that we have two different knobs to tweak. One for map loading/generation/network and one for rendering. 17:40 lhofhansl right now they have opposite goals :) 17:40 celeron55 well i'm still going to be the grumpy old man and tell you hardcoded 16 is fine right until rendering 17:40 celeron55 and a good idea 17:40 lhofhansl Oh I agree. 17:41 celeron55 but even if it's not so, the client will want to convert between sizes 17:42 lhofhansl And all interaction on the client would still be on 16-node blocks I assume. Just rendering would batch more into larger blocks (or smarter batching) 17:42 celeron55 also in reality converting those for rendering doesn't necessarily mean almost anything in terms of how the data is laid out in memory, if it can only use multiples of disk mapblocks 17:43 celeron55 the mesh generator is simply fed all the individual blocks it needs and then it puts out a mesh representing all of them at once 17:43 celeron55 and that's enough for reducing drawcalls as much as one likes 17:44 celeron55 if you configure the meshgen to make one mesh of the entire world, then you get only as many drawcalls as there are materials 17:44 celeron55 and stupidly slow mesh generation speed 17:45 lhofhansl IMHO that qualifies as a "simple solution". Although the details looks tricky. Need to update the large batches when one block changes, etc. Hecks solved part of this in the batching branch, but said there also were issues. 17:45 celeron55 but still in memory the mapblocks are laid out like before and yes, interaction would happen like before 17:46 celeron55 it's a many-to-one relationship from mapblocks to mapblock meshes then 17:48 celeron55 or maybe many-to-many if you also store the non-combined meshes for various situations where you might want to use them (eg. if a mapblock updates, you might want to drop the bombined mesh, generate a mesh for only the updated mapblock and put the combined one into a less prioritized background queue) 17:48 celeron55 combined* 17:49 lhofhansl many-to-one seems fine as long as the meshes are updated in the meshgen thread, I think. 17:49 celeron55 well, lots of details of course 17:49 hecks okay I'm back, let me catch up on a couple things 17:49 lhofhansl :) 17:50 hecks so doing meshgen as we're doing right now is fine, even with atlasing or batching 17:50 hecks batching meshes for atlasing in particular can involve more move operations or small gaps in the vertex buffer 17:51 hecks it's okay to have a few unused vertices not indexed by any primitive if it makes a rebatch faster 17:52 celeron55 so you intend to do the batching by combining the already generated small meshes? 17:52 hecks yup, there's little benefit to having an atlased path for the mesher 17:52 celeron55 makes sense for sure 17:53 hecks if the work is broken up into smaller portions, mesher updates should block less 17:53 celeron55 ...for that exact reason 17:53 hecks integrating the individual meshes into the batch must be done as lazily as possible 17:54 lhofhansl and not on the render thread 17:54 hecks yeah, I suppose another thread would be responsible for receiving the mesher output and integrating it 17:54 celeron55 if it's fast enough, then why not in the render thread. but what exactly has to be done? 17:55 hecks there is an advantage to doing it in the render thread actually 17:55 hecks you want to gather all possible mesh updates and integrate them in one go 17:55 hecks so maybe scratch that thread part 17:55 lhofhansl is this different in principle from the meshing done in the meshgen thread? 17:56 lhofhansl that used to cause a lot of client stutter 17:56 celeron55 think more like cutting and pasting the already generated meshes as-is into larger batches 17:57 hecks I'm just afraid that a series of remeshes can trigger a series of rebatches when it could be done in one rebatch 17:57 lhofhansl I'm running out of my depth here... Don't need to need to translate the meshes to be in the same coordinate system? 17:57 hecks no, nothing gets translated 17:57 hecks not ever since I destroyed the camera offset translation 17:58 hecks every block mesh is in the block's space and that's it 17:58 hecks this is precisely why the batching branch had that in the first place 17:58 lhofhansl so each mesh has its own model matrix? 17:58 hecks each block 17:58 hecks all meshes in a block currently share the model matrix 17:58 hecks which is just the block's position * BLOCKSIZE * BS 17:59 lhofhansl right, so how do you combine meshes from multiple blocks without translating the vertices? (as I said, out of my depth) 17:59 hecks ok so in that case you apply the offset, local to the batch 17:59 hecks but as I've said, I want to ditch the idea of merging blocks in favor of atlasing 18:00 hecks in any case the offset can be done on the fly while blitting the vertex data because you have to do that anyway 18:00 celeron55 what kind of atlasing do you intend to do? 18:00 celeron55 atlas per block? 18:00 hecks yes 18:00 celeron55 and then you have one drawcall per block, always 18:00 hecks shared between some blocks if possible but generally very dynamic 18:00 hecks assembled just-in-time, hardware accelerated 18:01 hecks maybe not one per block, closer to one per block per material type 18:01 hecks one for opaque, one for alpha 18:01 celeron55 how many drawcalls per block per material type are there currently? 18:01 celeron55 as many as there are textures? 18:01 hecks yes 18:01 hecks + soft overlays 18:01 hecks this is why we have 4 thousand drawcalls on a pretty normal scene 18:02 hecks a "sane" game's metric would be closer to 400 18:02 celeron55 so it depends on the map data a lot 18:02 celeron55 but in any varied situation there are quite many 18:02 celeron55 i mean if you have a grass field, you might have just 1 or 2 textures 18:02 hecks yup, another reason why my batching sucked - mall servers still chugged, it was good in minimalist games but underperformed in a real scenario 18:03 celeron55 of you have a jungle or an urban environment, then who knows 18:03 hecks atlasing handles this much better 18:03 celeron55 if* 18:03 hecks I also want to do another thing 18:03 hecks exclude very sparse nodes from meshing entirely, draw them as objects 18:04 hecks one vending machine, nyancat block, table, whatever does not deserve the overhead of being "meshed" 18:04 hecks it can just be culled and rendered as an individual thing 18:04 hecks or dynamically batched if there are a few in the frustum 18:04 celeron55 well, usually they are also interacted with a lot 18:04 hecks exactly, and they change materials, which triggers more remeshes 18:04 hecks again, a typical "mall server" or busy city or however you call it has a lot of these inside buildings 18:05 hecks being able to cull them individually would help a ton 18:05 hecks probably a lot more than attempting to treat them as normal nodes 18:05 celeron55 but for this you need some kind of list of such nodes, either based on a heuristic or measured dynamically 18:05 celeron55 or listed manually 18:05 hecks just a metric of a node count per block 18:05 hecks say, more than 4 instances in a block deserves a meshing 18:06 hecks and lua_api overrides could be possible 18:06 hecks like always mesh or never mesh 18:06 celeron55 preferably it should work fine enough without manual tuning 18:07 celeron55 people will misuse any manual stuff and then complain 18:07 lhofhansl ^ that 18:07 hecks this would really be obscure 18:07 hecks I doubt anyone would even dare touch a property like meshing_hint 18:07 hecks since it's controlled by the game developer, he shouldn't complain 18:08 lhofhansl (comes back to my gripe about all the distance options you'd have to configure just to increase the viewing_range past the default) 18:08 celeron55 of course MT is full of settings that people misuse and then complain so what am i to say this 8) 18:08 lhofhansl :) 18:08 hecks well that's a good argument to not make the heuristic a .conf entry 18:09 hecks but a per-node property to set it would be fine 18:09 celeron55 anyway this sounds fine, feel free to stop talking and start coding 18:09 lhofhansl every time I want to remove the config option and derive the value, someone complains 18:09 hecks meshing_hint = [number], "always" or "never 18:09 lhofhansl *a* config option 18:10 hecks every time anyone wants to do anything wise, people complain 18:10 hecks this is why developers have the final word 18:10 celeron55 to any end user, i'd describe this optimization as not helping much in a natural environment, but helping a lot in a built-up environment 18:11 hecks I cannot imagine a user ever wanting to globally tweak the meshing threshold 18:11 hecks let's talk about something else 18:11 hecks greedy meshing and how it actually causes a ton of remeshes 18:12 hecks if greedy meshing wasn't a thing, a simple light update wouldn't cause a remesh 18:12 hecks because the vertex color could be updated by itself 18:12 hecks greedy meshing isn't very greedy in the first place and doesn't save us a ton of geometry 18:12 hecks is there a chance we could just kill it? 18:12 celeron55 yeah greedy meshing is probably a thing of the past when vertex counts mattered more 18:13 lhofhansl tangentially... If someone could look at #10715. It helps a lot with slow map saving (and the server stalls resulting from it) 18:13 ShadowBot https://github.com/minetest/minetest/issues/10715 -- Allow configuring block disk and net compression. Change default disk level. by lhofhansl 18:13 hecks all it does is merge plain node faces into strips no longer than 16, along one axis per face 18:14 lhofhansl hecks: Meaning we should kill fastfaces? 18:14 celeron55 of course benchmark before removal but i'm fairly certain if removal of it helps adding new optimizations, it can be removed 18:14 hecks kill it and use the opportunity to make light updates cheaper, and to use lookup tables and blitting more in meshing 18:15 lhofhansl Someone tried that a while back (numberZero?) and it did hurt performance. 18:15 celeron55 can you find the numbers 18:15 lhofhansl #6903 18:15 hecks it would be nice to know which part it hurt, time spent meshing, render time, or mesher I/O 18:16 ShadowBot https://github.com/minetest/minetest/issues/6903 -- [Experimental] Drop fast faces by numberZero 18:16 lhofhansl Maybe time to try again. 18:16 hecks note that liquids no longer use this anyway 18:16 hecks now that they have perlin waves 18:16 lhofhansl I disabled it, but only when "waves" is enabled. 18:16 hecks at around 0.4 water still used greedy meshing 18:17 lhofhansl It still does when "waves" is off. 18:17 hecks okay, well, I'm just looking at a typical scene and I barely see any faces being merged 18:17 hecks https://a.uguu.se/EefcXKMdnFTP_scene.jpg 18:17 lhofhansl As I commented in 6903 I'd love to get rid of all that code. 18:18 hecks it seems to kill faces pointing at +Y the most 18:18 hecks because they are the least likely to have a light gradient on them 18:19 lhofhansl there isn't much flat in that scene 18:19 hecks and is there a lot of flat in most scenes? 18:19 lhofhansl I saw of lot of artifacts when I played with the sphere mapping of MT. Ended up just turning fastfaces off. 18:20 hecks it's true that I use more noise octaves 18:20 lhofhansl If it makes atlasing/batching easier, let's kill fastfaces. 18:21 hecks I have no idea if it will make that easier 18:21 hecks it will actually increase the amount of data to copy around 18:21 hecks it would however kill light-only remeshes 18:21 hecks I got another idea: hierarchical remesh 18:22 hecks where the mesher caches the block in a tree structure, like an octree, and only actually remeshes parts that have been touched 18:22 hecks and only copies the rest 18:22 hecks pretty much the same idea as merge-batching - but all the way to single node level 18:22 hecks oh but this conflicts with fastfaces too 18:23 celeron55 it might not make sense to have a very deep hierarchy 18:23 celeron55 but maybe splitting to 8x8x8 nodes would make sense 18:23 hecks who knows? maybe making the map out of huge octrees is just what the doctor ordered 18:24 celeron55 when you go smaller, the borders require extra processing 18:24 celeron55 the smaller the batch, the more surface per volume you get 18:24 hecks ah, square cube 18:24 celeron55 and in my experience surface is a bit of a problem when meshing 18:24 celeron55 it needs extra care 18:24 celeron55 i mean voxel volume surface 18:25 celeron55 but who knows 18:25 celeron55 what about the extreme, meshing each node individually? that certainly wouldn't make sense 18:25 celeron55 it means there's a lower limit 18:25 celeron55 for what makes sense 18:26 hecks would it not? on a single node level, you can just crunch out a lookup table for all the ways a node may be used 18:26 celeron55 well maybe if you can efficiently process nodes with no visible faces 18:27 hecks 6 bit lookup table (64 elements) 18:27 hecks where the bits are neighbor presence 18:27 celeron55 so each mapblock would have a list of nodes with visible faces, and for each of those a lookup table index for what the mesh looks like 18:28 celeron55 or what 18:29 hecks each mapblock would be swept in the three dimensions to determine neighbor information for each node (that 6 bit number), stashing that into a buffer 18:29 celeron55 i think that wouldn't be very useful when rendering, maybe as a cached processing step 18:29 hecks then another pass would do the lookup 18:30 celeron55 so basically splitting mesh generator into two steps, the first one which can be cached? 18:30 celeron55 on a per-node basis 18:30 hecks it's like 18:30 hecks a nodedef has this [64] lookup for possible meshes generated (for normals, just one shared lut is needed) 18:30 hecks then, when we mesh, the first pass computes indices into this lookup 18:31 hecks the second pass does the substitution and actual mesh 18:31 hecks meshing 18:31 hecks this is highly, and I mean highly parallelizable 18:31 hecks but... no greedy meshing 18:31 hecks also cacheable at any granularity, so if you wanted to stash 8x8x8 results, you could 18:31 celeron55 the thing about greedy meshing is, on any dedicated GPU you get basically no benfit, but on basically all integrated GPUs you kind of want it 18:31 celeron55 +e 18:32 hecks maybe it can be done as a postprocessing step 18:32 hecks as a pure mesh operation, unaware of voxels 18:32 hecks just weld vertices that contribute nothing 18:32 celeron55 altough once people see how much lighter updates can be... maybe it's worth the loss in FPS anyway 18:33 hecks steady 60 fps is better than stuttery 80 fps 18:33 celeron55 i'd certainly like to see this 18:33 hecks it would be a cool experiment 18:34 celeron55 already forgot what problem we were trying to solve though 18:34 hecks =] 18:34 hecks minimizing remeshes to make batching viable 18:35 hecks the part that really stinks is how 3D textures aren't universally supported 18:35 hecks that would eliminate the concern about light 18:36 celeron55 well, you always need to navigate the opengl version jungle 18:36 hecks but oh right, some people have talked about lightmapping as a solution to this 18:36 hecks and you know 18:36 hecks technically slicing a 2D texture can crudely emulate a 3D one 18:36 hecks for a blocksize 16... 18:37 lhofhansl Hey... Going to merge #10721 in a few. 18:37 ShadowBot https://github.com/minetest/minetest/issues/10721 -- Revert "GUIFormSpecMenu: Shift+Click listring workaround for MacOS" by SmallJoker 18:37 hecks a 64x64 texture will do 18:37 hecks that can contain the whole 3D "lightmap" of a block 18:38 hecks at the cost of one lerp and one extra tex2d in the fragment shader to simulate bilinear filtering on the Z axis 18:38 celeron55 makes sense 18:40 celeron55 well 18:40 celeron55 in cases where nodes touch only at edges, it can get nasty 18:41 celeron55 but with current code it's not very well handled anyway 18:41 lhofhansl Let 18:41 celeron55 or was it fixed? eh, i should know 18:42 lhofhansl Let's start with something simple and not boil the ocean. 18:43 celeron55 well 18:43 celeron55 first you remove someone else's complexity, then add your own complexity 18:43 celeron55 simple 18:44 celeron55 at this point anyone who considerably improves MT's rendering will be considered a legend 18:45 celeron55 so there's a lot at stake here! 18:45 hecks just kill some drawcalls, what could possibly go wrong.... 18:46 celeron55 let's just drop 50% of them at random 18:46 celeron55 who cares if you don't see everything on every frame 18:46 hecks block_send_optimize_distance and our lousy culling already do that 18:46 celeron55 :D 18:47 celeron55 i guess 18:47 hecks actually, do proper culling and you'll see at least 20% of them gone 18:47 hecks you can't fly around in wireframe mode without the urge to ask "why is this being drawn" 18:49 hecks https://a.uguu.se/ENJdOYJCOonN_quality.jpg 18:49 sfan5 doesn't irrlicht even support occlusion queries 18:49 hecks occlusion queries suck 18:49 hecks but we can definitely do better 18:51 hecks dungeons are always fun https://a.uguu.se/zo6VilCVAO3p_culling.jpg 18:51 sfan5 you can go and tweak the values of the current occlusion code but it'll fail on your fast because it's very inaccurate 18:51 sfan5 and the current fix for that is pretty much "just render everything within 48 (or more?) nodes" 18:52 hecks it has some interesting false positives going on too 18:52 hecks who hasn't seen blocks just blink in and out of existence for no reason 18:53 celeron55 there can only be a finite number of rays for occlusion culling 18:53 hecks which is why I don't want to use rays for this 18:53 celeron55 so you always get false positives and false negatives 18:53 hecks I want to straight up software render some cubes 18:53 hecks do what occlusion queries do but without the lag 18:54 hecks you don't even have to render cubes, just hexagons that form the outline of those 18:55 celeron55 i at some point was thinking if it would be possible to precalculate whether a mapblock can be seen through in each direction and stop doing any node-level rays but instead do them at the mapblock level 18:55 hecks you're thinking of hierarchical culling 18:55 hecks you can definitely do an early hit/miss on a whole mapblock before considering its contents 18:56 hecks better yet, use octrees, they're wonderful for this 18:57 hecks oh wait 18:57 hecks I know what you mean now 18:57 celeron55 for most mapblocks that you shouldn't see through you can't even run a pathfind from the front face to back face 18:57 hecks you can possibly precompute this 18:58 hecks the planes bounding a box divide space into 27 regions including itself 18:58 hecks but uh, no, not like that 18:59 lhofhansl I tried to improve the current occlusion culling a while back - remember that? Didn't go that well. 18:59 hecks actually I think that sort of precomputation would be too expensive to perform 19:00 hecks it would take a nontrivial amount of time to determine if a mapblock is tight for all the possible ray combinations 19:02 hecks here's some very esoteric WIP culling code for anyone interested https://github.com/hecktest/minetest/blob/batching/src/client/culling.cpp 19:02 lhofhansl I remember reading an article about how minecraft does it. They use a flooding model. 19:07 hecks flooding wouldn't be too tight, so screw it 19:07 celeron55 generally mapblocks have 8 corners, one of which you are always the closest to, and you will be generally seeing 1, 2 or 3 mapblock faces that touch the corner. for you to see through the mapblock, there has to be a path through the mapblock from any of the 3 faces to any of the opposing 3 faces. if there is not, you can't see through the mapblock and any mapblock behind it can always be culled 19:07 hecks celeron55: does this account for perspective? 19:07 celeron55 there could of course be a path through it that you can't see through 19:08 celeron55 that's true even with perspective 19:08 celeron55 of course you'll get only partial culling with this 19:09 celeron55 it's just a way that came into mind that would give zero false positives 19:09 celeron55 of course it requires a fast enough pathfinder, i don't know if that exists 19:10 hecks any thoughts on my rasterizing approach? 19:10 celeron55 it can (or should) be a ray based pathfinder that requires a straight path 19:10 celeron55 but it has to check all possible paths 19:10 hecks I basically wanted to rasterize [n] layers of 1-bpp stencils, in 8x8 tiles because each fits into a u64 19:10 hecks and then use bitops to do everything 19:11 hecks https://github.com/hecktest/minetest/blob/15d573d7182abbf1f31b7767d8318e99387342d0/src/client/culling.cpp#L36 19:12 celeron55 well, does it work? 19:12 hecks no idea :DDD I didn't finish it 19:12 hecks but rasterization using tiles was fast 19:14 celeron55 it's still a node level raycast, right? 19:15 hecks no, I was straight up rasterizing boxes to do software occlusion queries 19:16 lhofhansl https://tomcc.github.io/2014/08/31/visibility-1.html 19:18 celeron55 i can't really imagine how fast it would be 19:20 lhofhansl I actually hacked it into MT once and it was very slow :) 19:20 lhofhansl (But I didn't make a great effort either - and didn't keep the branch) 19:23 lhofhansl The way that it is described, the caching, etc, I can envision this is being fast... And it is accurate. 19:23 hecks check out these bleeding edge realtime 3D graphics https://a.uguu.se/4TXBOF0nStIK_raster.jpg 19:25 celeron55 lhofhansl: that's fairly similar to what i described 19:25 lhofhansl Yep 19:28 hecks let's maybe try to look for obvious things to fix that would make batching easier 19:28 hecks I nominate cracko, that one is low hanging fruit 19:28 hecks also #10714 19:28 ShadowBot https://github.com/minetest/minetest/issues/10714 -- Keep mapblocks in memory if they're in range by hecktest 19:28 celeron55 occlusion culling certainly isn't one. we have it, it mostly works in real use 19:28 lhofhansl (not a fan of 10714 - as you know) 19:29 celeron55 i think #10714 makes sense 19:29 ShadowBot https://github.com/minetest/minetest/issues/10714 -- Keep mapblocks in memory if they're in range by hecktest 19:30 hecks because you still think that those things should be (incorrectly) based on the view frustum? 19:30 lhofhansl yes 19:30 hecks and that the server should just immediately send us mapblocks using tachyons if we turn the camera? 19:31 lhofhansl If you didn't look that way for 10 minutes... Yes. 19:31 hecks no, because 19:31 hecks as it is, every time a client unload happens - be it every 10 minutes or 10 seconds (and 10 seconds is MUCH preferrable) 19:31 hecks all the blocks behind me go poof 19:32 hecks and just because I didn't look that way for 10 minutes 19:32 hecks who's to say I won't do it 10 minutes and one second later? 19:32 hecks it looks broken, it is broken, it ruins a superior memory management strategy 19:32 lhofhansl As I also said somewhere... If we change the logic of the cache it's fine. As is it sorts all cached blocks by time and then expires the older ones. 19:33 hecks did you actually test it? 19:33 lhofhansl Maybe two caches. One that keep the sphere always. No sorting. And some extra cache. 19:33 hecks that's fine too 19:33 hecks but as a quick fix, isn't this good enough? 19:33 hecks it basically does this 19:33 hecks it always keeps the sphere 19:33 hecks and the clock only starts ticking for things outside of it 19:34 hecks also somewhat relevant https://github.com/minetest/minetest/issues/10683#issuecomment-739557347 19:35 hecks I encountered similar stutter to this guy and I narrowed it down to client data unloads 19:35 hecks cranking up the unload rate helps because there's less stuff to dump at once, but to make that viable, 10714 is needed 19:35 lhofhansl I suppose that we release the HW buffers (#10501) it's more acceptable. 19:35 ShadowBot https://github.com/minetest/minetest/issues/10501 -- Periodically release all mesh HW buffers to avoid an Irrlicht bottleneck by lhofhansl 19:35 lhofhansl now that... 19:38 lhofhansl It's 3x as many blocks to keep in the cache. Relevant for large viewing ranges. 19:38 lhofhansl (at fov = 72) 19:38 hecks eeee hold on a second 19:39 hecks those blocks, we should've been keeping them from the beginning 19:39 hecks and fov is irrelevant because nobody just stands around staring at one spot 19:39 hecks those blocks get loaded anyway 19:40 hecks only they get dropped for a stupid reason 19:40 hecks and then they get loaded again 19:42 hecks you're trying to preserve an optimization that does more harm than good, and doesn't even save that much ram 22:35 sfan5 merging #10152 in 10 minutes 22:35 ShadowBot https://github.com/minetest/minetest/issues/10152 -- Semi-transparent background for nametags by Zughy 22:38 MTDiscord sweet 23:38 MTDiscord I just hope this will look good with already transparent name tags too cause that is what I use on my server 23:39 MTDiscord By transparent I mean alpha set to half 23:39 sfan5 those are entities aren't they? 23:40 MTDiscord No, I use the builtin name tags with alpha set to half plus different colors