Time Nick Message 10:08 MTDiscord pgimeno: it is possible to generate images from Lua and import them into the engine 10:24 MTDiscord nfjsfshfjsfsjfs 10:24 MTDiscord sorry my lil bro got ahold of my laptop 10:25 MTDiscord iujü+ 11:09 sfan5 how little 11:10 celeron55_ teach him to code for us 11:44 hecks great, more light and shadow PRs 11:48 twoelk hi hecks, added your script to the import-export section on the wiki page at https://wiki.minetest.net/Using_Blender 11:49 twoelk you may want to check it if I described your script correctly 11:51 hecks i guess but the bit about transforming the model is a little advanced 11:51 hecks it's fine because there's only really two .x users i know of and i'm one of them 12:02 hecks someone give me an account on that thing, i'll clean up this page a little 12:15 MTDiscord celeron55_: I tried, he's not interested 12:40 twoelk help on that wiki page would be great, especially from people that use blender on a more regular basis than me ;-) 12:41 twoelk calinou usually grants access to the wiki 12:42 Calinou hecks: PM me your email address and desired username (note that the username must start with an uppercase character, due to MediaWiki limitations) 12:42 Calinou /msg Calinou 13:09 hecks does the minetest_game B3D player model use more than one material? 13:23 MTDiscord I dont think so, 3d_armors does 14:31 hecks https://github.com/minetest/irrlicht/pull/48 14:31 hecks −93,450 14:31 rubenwardy jesus 14:32 rubenwardy how many SLOC is Irrlicht after that? 14:32 MTDiscord Why are we deleting all these features? 14:33 rubenwardy Once it starts to get below Minetest and we know all of it, there's an argument that it could be added to the main repo to making building easier 14:33 hecks i don't know but it's uhhhh about 200k newlines down to about 100k, half the files gone 14:33 hecks yes rubenwardy that's my plan actually 14:33 hecks chop it down enough until it can be absorbed 14:33 rubenwardy Irrlicht: "haha I'm in danger" 14:33 hecks but if not, at least rebuilding isn't a chore anymore, it builds from a make clean to under a minute now 14:34 hecks the fairy is on a diet 14:35 MTDiscord I can rebuild full Irrlicht in 30 seconds because I don't make clean. 14:35 hecks well a rebuild is now a few seconds 14:35 MTDiscord yoo ? 14:35 hecks we're deleting the features because we're literally not using them, we actually implement a lot of this stuff ourselves 14:36 hecks we have our own: collision, particles, lighting, text, skybox, and mostly our own scene manager 14:36 MTDiscord I don't know but I just like it when a program can accomplish the same it could do previously but with less code behind it 14:36 MTDiscord at this point we might as well not call it irrlicht 14:36 hecks all of our clientside stuff is implemented as custom scene nodes too 14:36 hecks it's irrmt not irrlicht 14:37 hecks since i also ripped the bandaid on non-GL renderers we basically use it as a somewhat fatter openGL shim and gui/events library 14:37 MTDiscord Why aren't we moving our collision and particles and stuff to Irrlicht? Not arguing with the PR, just curious. 14:37 MTDiscord Deleting half of a source tree with no loss in functionality: beautiful. 14:37 hecks because we're an engine using an engine, and irrlicht's code is terrible 14:37 MTDiscord I was once on a project that gained functionality while dropping 70% of its weight, but you don't get to see those everyday :-D 14:38 hecks rest assured the deletions will continue 14:38 hecks this was the easy stuff 14:38 hecks the rest will require editing code - but this exercise has actually just forced me to learn how the whole thing is structured 14:38 hecks next is unifying GL drivers, that should be a -20k 14:38 hecks oh and removing crap like "parallax normal mapped material" 14:39 hecks that is all of the hardcoded irrlicht shaders 14:39 hecks to replace with our own hardcoded shaders of course =] 14:39 MTDiscord so when do we get our own RGBA defined shaders 14:39 MTDiscord ie each channel corresponds to a material 14:39 MTDiscord SSR, specular etc 14:39 hecks uhhhhhhh 14:40 specing when you port to torque3d and cut off all the phone users 14:40 hecks do you mean a packed pbr material? 14:40 MTDiscord yes 14:40 hecks i'd rather just provide a shaders api that lets you do whatever you want 14:40 MTDiscord that works too 14:40 hecks also jordach, packed materials aren't necessarily smart 14:40 hecks have you considered that your roughness map might not need to be the same size as your specular map? 14:41 hecks it's better to use a single channel texture if you're not starved for samplers 14:41 MTDiscord fair 14:41 MTDiscord i mean nobody was also stopping you from scaling the packed material to 1x1 either 14:42 hecks in one of my older projects, the packed albedo-gloss on one material was 2048 while specular rgb was 256 14:42 hecks because it was a dielectric organic material and it didn't really matter 14:57 nrz i think first we should remove the compat code (if not already done), DX8 for example, old models, and non minetest pertinent code 14:58 nrz for the particles, using the irrlicht onecan be a great improvement 14:58 nrz for ITextScene node, i know we don't use it currently, but there can be useful things on some games for that 15:07 hecks we do not use ITextSceneNode 15:08 hecks D3D and software renderers were already disabled, I just mopped up the remains 15:08 hecks as for particles, while it is true that our system needs improvement, taking on extra dependency on irrlicht for this is a step in the wrong direction 15:10 hecks remember that irrlicht is a dinosaur and does a lot of things in naive, slow ways, and is necessarily unaware of driver specific optimizations 15:10 hecks using irrlicht particles might bring a small perf boost for in exchange a whole load of tech debt and suck 15:10 hecks in exchange for* 15:11 hecks and on our own end, it wouldn't be hard to improve either - our particle issue with scene nodes is pretty trivial to solve 15:12 hecks aside from the scene node instantiation blunder, our particle system is relatively concise and probably cheaper 15:13 hecks and delivers surprisingly good results, this is why i didn't know that we're not using irrlicht particles until now 15:14 MTDiscord anyone know what would need to be done to add support to currently broken locale so that they would not be broken anymore? https://github.com/minetest/minetest/blob/a049e8267fabd101cb5c6528b3270214cb0647f0/src/CMakeLists.txt#L680 15:19 hecks those locales probably have issues with text rendering or input 15:20 celeron55_ https://github.com/minetest/minetest/issues/4638 15:20 celeron55_ the reasons are described on the issue mentioned in the comment 15:26 nrz i'm fine to remove broken/unused things, but we also need to publish to irrlicht some of our classes, i'd like to see our client to become a client using a GL library instead of putting may crap inside because irrlicht only has abstracts, and let the client just be a client :D 15:27 hecks uhhhhhh 15:28 hecks i think you'll have to type that out again, i'm a bit confused 15:31 MTDiscord tl;dr client should just pass the duck test that the network layer expects 15:32 MTDiscord ie it could be built from anything, while the server could be built from legacy components 15:32 hecks the server already doesn't depend on irrlicht a whole lot, just for vector types i believe 15:32 hecks it only needs the headers 15:32 MTDiscord basically it means you could just rip everything out of the client barring multiplayer and it'd be a real minetest client™️ 15:32 hecks maybe shared concerns between the client and the server can be carved out into a libMT 15:33 MTDiscord it would also mean we could use some form of "launcher" where the client could have a specified network version 15:34 MTDiscord the linked issue there point to #4637 and it suggested that it was an irrlicht issue, so what could be done to add support now that Minetest use its own fork? 15:34 ShadowBot https://github.com/minetest/minetest/issues/4637 -- Minetest doesn't support RTL languages (Hebrew) 15:34 MTDiscord and singleplayer would still be localhosting a server but with the client looking at 0.0.0.0:abcxy 15:35 MTDiscord it means mainmenu doesn't have to be built from the pile of hacks that is formspecs 15:36 hecks i could see the following working; shared libMT, server executable, client executable 15:37 celeron55_ there's barely any benefit to any of that 15:37 hecks there is a bit 15:37 MTDiscord basically the only thing i really care about is basically the client being more or less not technically bound to 10 year old bad openGL decisions 15:38 hecks divorcing irrlicht would take care of the bad GL 15:38 MTDiscord it could also mean if we instead standardise a network protocol and Lua API rather than bundle it all together as a barely working piece of meat 15:38 MTDiscord even more platforms are supportable as we'd have a basic network I/O library and the Lua core 15:39 MTDiscord and we just build our own graphics implementation 15:39 MTDiscord kinda like the original Doom 15:39 hecks a thin client would be convenient to build 15:39 MTDiscord WebGL MT client you can play right in a browser :-D 15:40 MTDiscord :O 15:40 MTDiscord its not like webassembly makes that shockingly easy 15:40 hecks that too 15:40 hecks and yeah, why aren't we making webgl builds already... 15:40 MTDiscord heh, not even joking. Being able to give someone a URL that takes them right into the action is a pretty cool way to introduce someone to something instead of having to walk them through a bunch of download and install stuff. 15:40 hecks the client model of minetest where it downloads all the assets is perfect for this sort of thing 15:41 hecks ideally there should just be a thin client on minetest.net that you can just use anywhere 15:41 MTDiscord does webgl even work with minetest right now? 15:41 MTDiscord i've always mentioned a minetest client that while it connects like any other minetest client, doesn't actually depend on minetest itself 15:41 MTDiscord Given how at least some people have machines so sickeningly overpowered that it would make even webgl run pretty smoothly... 15:41 hecks i'm not sure if it works *right now* but i don't see any big obstacle 15:41 MTDiscord even Apple fully supports WebGL and WebGPU since last year 15:42 MTDiscord (yes it would technically solve the situation on iOS like how xCloud is handled as well) 15:43 MTDiscord Haha, if only the browser on iDevices wasn't so stunted, WebGL could put the MT-on-iPhone thing to bed once and for all :-D 15:43 MTDiscord i mean i only need to find where the ES drivers are located in the SDK and it'd take me a day to get it all built 15:43 hecks also think about all the poor kids stuck on school chromebooks where they can't install anything worth a damn 15:44 MTDiscord it's not like i already have the secrets needed to build it under arm64 macOS 15:44 sfan5 >why aren't we making webgl builds already... 15:44 sfan5 no UDP network layer in browser 15:44 MTDiscord Wrapping MT protocol in websockets is pretty trivial 15:44 MTDiscord I'd happily run a websocket-to-UDP proxy on my own server at least 15:44 MTDiscord webassembly lets you use UDP 15:44 MTDiscord it silently wraps them as websockets 15:45 MTDiscord in fact I actually have a UDP-over-websockets wrapper I use to forward wireguard on public wifi that only lets you do HTTPS :-D 15:46 MTDiscord websockets will work as well as UDP would like 90% of the time, which is more than you could say about the webassembly/webGL stuff anyway, so that's not really an obstacle. 15:46 sfan5 @MNH48 relevant comment, at least one of these things will have to be depending on language https://github.com/minetest/minetest/issues/11455#issuecomment-883810565 15:46 sfan5 oh also second reason: unless I missed it irrlicht only supports webgl1 15:47 sfan5 not that it doesn't work (android still uses it by default) but it's not ideal 15:47 MTDiscord "...we act as though a single 16-bit character is a whole character..." this is by FAR not an MT-specific problem. In fact I'd say this mistake is pretty much industry-standard. 15:47 sfan5 Linux must not be part of the industry then as sizeof(wchar_t) == 4 on here ;) 15:51 MTDiscord That'll work until the Unicode Consortium inevitably does their next insane thing ;-D 15:55 MTDiscord you can actually run minetest on a chromebook using the linux container functionality, but you'd be hard pressed to be allowed that on a school-issued chromebook or whatnot 15:56 MTDiscord Ironically a non-insignificant slice of MT's target audience IS schools. 15:56 MTDiscord oh yeah, well in that case they would probably allow that 15:57 MTDiscord Not necessarily; a teacher may want to use it but not have enough political pull to get an exception in the IT policy governing chromebooks for the whole school. A webGL no-install version would still have value. 15:58 MTDiscord yeah that's true 15:59 MTDiscord to be fair to the IT admins, opening up the linux functionality would open it up fully, not only for playing minetest 16:02 celeron55_ being able to play in a web browser could actually be a killer feature 16:02 sfan5 remember java applets? ;) 16:02 celeron55_ there's a certain other game that hasn't supported it in 12 years 16:10 celeron55_ i mean, it would be crazy to play that way, but definitely less crazy than playing on a phone 16:10 celeron55_ inb4 50% of the userbase would then play the web version, but on a phone 16:11 MTDiscord If they are happy playing it that way I ain't gonna stop tem 16:11 MTDiscord It seems to fit in with a broader "make MT more useful for non-power users" vision 16:35 hecks how would they play the web version on a phone, do browsers expose a touch api of some sort? 16:36 Calinou yes, they do 16:37 MTDiscord yeah 16:37 Calinou you can create a progressive web app to hide the navigation bar 19:34 hecks man I'm getting carried away with this blender page 19:34 hecks it's gonna turn into a pretty big tutorial 20:01 MTDiscord Is there some sane reason why minetest.get_current_gamename() isn't a thing? 20:06 v-rob Likely because nobody thought of it 20:08 MTDiscord Also would be really nice to actually treat games as games instead of as just handfuls of mods. Things like being able to know whether a mod is part of a game or not, and mods being able to have at least read access to the rest of the game that contains them. 20:09 v-rob A note: Linux uses a 4-byte wchar_t, and that's a little better than Windows, but I'd oppose using UTF-32 all the same. Too many people believe that UTF-16 is a full character, and too many people also believe that UTF-32 is a full character. Neither is true, and UTF-32 is only marginally better. It's better to use UTF-8, save memory, and force people to understand what Unicode characters really are and not do it wrong. 20:12 MTDiscord UTF-16 may still have advantages over UTF-8 for some users, e.g. non-Latin scripts. UTF-32 however would only actually be useful for people who e.g. communicate using nothing but emoji. 20:17 v-rob UTF-16 can have memory advantages in a few situations, but UTF-8 is much nicer for many reasons, e.g. compat with ASCII, Lua strings are 8-bit, no conversion in general, etc. To really save memory, ZIP your files :) 20:20 MTDiscord I could accept UTF-8 as a strategy, assuming people who live in the non-ASCII parts of the world didn't have some real protest about it. 20:25 v-rob Technically, it's actually my choice. I'm in charge of the UI, and that includes almost everything in Minetest that uses text, so I have to figure out how to plan Unicode out. Which means, I have the power to choose the encoding. UTF-EBCDIC for everyone, bwa ha ha! 20:25 sfan5 "too many people also believe that UTF-32 is a full character" all of the encodings work on codepoints, does it matter? 20:26 MTDiscord Best troll encoding would have to be UTF-1 20:27 MTDiscord huh 20:27 sfan5 btw irrUString includes surrogate handling for utf-16, this is why emojis already work 20:27 MTDiscord how would utf-1 work lol 20:27 MTDiscord It takes over 16 kilobytes to represent the poop emoji in UTF-1 20:30 v-rob That's my point, since the encoding doesn't mean much (codepoints are basically worthless, things like grapheme clusters are much more important), then why use UTF-32 or UTF-16? They just make people believe that they're doing it right when they aren't and have the only benefit of sometimes saving memory. 20:30 v-rob However, I have no plans to touch any of Minetest's existing wstring code, at least for now. 20:32 v-rob I'd really have to learn some Unicode libraries properly if I want to really whip Minetest's Unicode support into shape. 20:32 rubenwardy I prefer to use UTF-8 and then convert to APIs when needed 20:32 rubenwardy But when we define our own text handlijg APIs, that becomes not so clear 20:32 MTDiscord Even if you used UTF-1 and had horrible text handling, you'd still be competing against the image and texture handling for the memory leak trophy anyway... 20:33 MTDiscord The difference between UTF-16 and UTF-8 is probably pretty moot in the grand scheme of things. MT doesn't really deal with large TEXT files all that much as I understand it. 20:34 v-rob Right, but think of Lua. That's where it counts 20:34 v-rob I'd rather not expose a UTF-16 library to Lua, where UTF-8 would make a lot more sense 20:34 hecks https://wiki.minetest.net/Using_Blender how's this looking 20:35 MTDiscord I sort of assumed Lua would sort of naively use UTF-8 and there wasn't much we could do about that anyway, no matter what kind of encoding the C++ side used :-P 20:35 v-rob I guess, in the end, what encoding we use is whatever encoding the Unicode libraries we choose use. 20:36 MTDiscord My B3D exporter is a fork of joric's. His does not work at all on 2.8 IIRC even though it claims to. 20:37 hecks so it's a 2.7x script? I'll correct that 20:37 hecks i didn't write that section 20:37 MTDiscord That should probably be double checked, but I believe his script is still python2 20:38 MTDiscord Which is why it just straight up doesnt run on 2.8 20:38 MTDiscord hecks: for model optimization, there are some tools out there like https://github.com/ExeVirus/Compress-Obj that might be worth mentioning 20:40 MTDiscord Ok I dont think its python2, I think there was just some faulty : <-> = swaps that prevented it from working. Seems like he didnt even bother testing it when updating it. 20:40 hecks so it's just broken? 20:44 MTDiscord Just tested on 2.83, it works as long as something is selected. Otherwise it fails. 20:45 hecks well the wiki just logged me out and broke 20:46 MTDiscord So I guess joric's "works" but its shoddy at best 20:46 hecks i suppose we don't need it 20:46 hecks we have a 2.7x version and yours 20:46 MTDiscord But you should at least note that mine is a maintained fork 20:46 MTDiscord fair 20:47 MTDiscord Still awaiting the day a modern format gets implemented and I can drop support for b3d 20:49 hecks either gltf or roll our own 20:49 MTDiscord rolling our own means supporting exporters and whatnot, so gltf pls 20:51 sfan5 @Warr1024 Lua inherited C's qualities of "string functions perform on ASCII but otherwise strings are binary blobs" 20:51 hecks well if we were to adopt my format (lua based), you'd get support for free 20:52 hecks it's very similar to gltf in spirit but would cost a lot less code to use 20:52 hecks it already works; i use it as an intermediate representation that i later convert to .x 20:58 hecks here's minetest sam as an .lsd file: https://paste.uguu.se/?301c185bb79d5cdc#FyuMju4oQRGCij7uDVkf8a94AvTDPa4YfSphYvxZwA9t 20:59 hecks it can be deserialized just by executing it with an empty setfenv 21:04 MTDiscord Heh, those 1.04999998 things suggest rounding errors that really could stand to be optimized out :-) 21:05 hecks that's sam's fault 21:05 MTDiscord Unless they're something even worse like purposeful offsets to avoid z-fighting 21:05 hecks possibly 21:05 hecks my plugin would not do this with integers 21:05 hecks and it already has quantization settings 21:06 hecks https://a.uguu.se/Plngh1gDtEl7_settings.png 21:06 MTDiscord gltf has the advantage of not being maintained by someone who is developer on a game engine project that is somewhat famous for making people ragequit :-) 21:08 hecks no, but instead someone would have to maintain the importer on the engine side... same deal 21:08 hecks at least mine is just 1k lines 21:09 hecks gltf does compress better though, it does bit level quantization 21:10 hecks using gltf with draco compression you could really stretch the current limit of 8 megs per model 21:10 hecks and the exporter is luckily high quality, it's as fast as a blender exporter can physically be (i tested that too...) 21:20 rubenwardy Lua definitely should only be UTF-8 21:34 MTDiscord Lua's standard lib is ASCII, but newer versions come with UTF-8 functions and match cases 21:46 Cybille As MS say we stay UTF-8, the Emperor Asia with Madarin(700+ Smiley Basic 4000+ Extendend) make 1000 Black Copy "Fabric" of Windws ... Now wie have UTF-???, Unicode and LTR / RTL to improve the Chaos ... 23:27 MTDiscord Speaking of gltf I did some preliminary work, I expect it would take 10 hours of concerted effort to make an importer for minetest 23:28 MTDiscord But we would have to support only the model data, none of this gtlf binary compiled stuff 23:56 pgimeno It takes over 16 kilobytes to represent the poop emoji in UTF-1 <-- not according to https://en.wikipedia.org/wiki/UTF-1