| Time |
Nick |
Message |
| 01:03 |
|
Guest1160 joined #minetest-dev |
| 02:51 |
|
olliy joined #minetest-dev |
| 02:55 |
|
olliy joined #minetest-dev |
| 02:59 |
|
specing_ joined #minetest-dev |
| 03:00 |
|
Extex joined #minetest-dev |
| 04:55 |
|
v-rob joined #minetest-dev |
| 06:51 |
|
epoch joined #minetest-dev |
| 07:14 |
|
Kimapr joined #minetest-dev |
| 07:28 |
|
olliy joined #minetest-dev |
| 07:34 |
|
tech_exorcist joined #minetest-dev |
| 07:47 |
|
queria joined #minetest-dev |
| 09:13 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:49 |
|
calcul0n_ joined #minetest-dev |
| 09:52 |
|
appguru joined #minetest-dev |
| 10:08 |
MTDiscord |
<appguru> pgimeno: it is possible to generate images from Lua and import them into the engine |
| 10:21 |
|
tech_exorcist joined #minetest-dev |
| 10:24 |
MTDiscord |
<appguru> nfjsfshfjsfsjfs |
| 10:24 |
MTDiscord |
<appguru> sorry my lil bro got ahold of my laptop |
| 10:25 |
MTDiscord |
<appguru> iujü+ |
| 10:26 |
|
Jordach joined #minetest-dev |
| 11:09 |
sfan5 |
how little |
| 11:10 |
celeron55_ |
teach him to code for us |
| 11:11 |
|
twoelk joined #minetest-dev |
| 11:17 |
|
entuland joined #minetest-dev |
| 11:18 |
|
hecks joined #minetest-dev |
| 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:04 |
|
twoelk joined #minetest-dev |
| 12:15 |
MTDiscord |
<appguru> 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 <here> |
| 12:49 |
|
calcul0n__ joined #minetest-dev |
| 13:09 |
hecks |
does the minetest_game B3D player model use more than one material? |
| 13:15 |
|
pgimeno_ joined #minetest-dev |
| 13:18 |
|
book` joined #minetest-dev |
| 13:23 |
MTDiscord |
<Jonathon> 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 |
|
olliy joined #minetest-dev |
| 14:32 |
rubenwardy |
how many SLOC is Irrlicht after that? |
| 14:32 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<Sublayer plank> 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 |
<Sublayer plank> 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 |
<Jordach> 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 |
<josiah_wi> Why aren't we moving our collision and particles and stuff to Irrlicht? Not arguing with the PR, just curious. |
| 14:37 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Jordach> so when do we get our own RGBA defined shaders |
| 14:39 |
MTDiscord |
<Jordach> ie each channel corresponds to a material |
| 14:39 |
MTDiscord |
<Jordach> 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 |
<Jordach> yes |
| 14:40 |
hecks |
i'd rather just provide a shaders api that lets you do whatever you want |
| 14:40 |
MTDiscord |
<Jordach> 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 |
<Jordach> fair |
| 14:41 |
MTDiscord |
<Jordach> 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:52 |
|
olliy joined #minetest-dev |
| 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:01 |
|
specing_ joined #minetest-dev |
| 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 |
<MNH48> 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 |
<Jordach> tl;dr client should just pass the duck test that the network layer expects |
| 15:32 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> it would also mean we could use some form of "launcher" where the client could have a specified network version |
| 15:34 |
MTDiscord |
<MNH48> 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 |
<Jordach> and singleplayer would still be localhosting a server but with the client looking at 0.0.0.0:abcxy |
| 15:35 |
MTDiscord |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> even more platforms are supportable as we'd have a basic network I/O library and the Lua core |
| 15:39 |
MTDiscord |
<Jordach> and we just build our own graphics implementation |
| 15:39 |
MTDiscord |
<Jordach> kinda like the original Doom |
| 15:39 |
hecks |
a thin client would be convenient to build |
| 15:39 |
MTDiscord |
<Warr1024> WebGL MT client you can play right in a browser :-D |
| 15:40 |
MTDiscord |
<Sublayer plank> :O |
| 15:40 |
MTDiscord |
<Jordach> 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 |
<Warr1024> 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 |
<Sublayer plank> does webgl even work with minetest right now? |
| 15:41 |
MTDiscord |
<Jordach> 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 |
<Warr1024> 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 |
<Jordach> even Apple fully supports WebGL and WebGPU since last year |
| 15:42 |
MTDiscord |
<Jordach> (yes it would technically solve the situation on iOS like how xCloud is handled as well) |
| 15:43 |
MTDiscord |
<Warr1024> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Warr1024> Wrapping MT protocol in websockets is pretty trivial |
| 15:44 |
MTDiscord |
<Warr1024> I'd happily run a websocket-to-UDP proxy on my own server at least |
| 15:44 |
MTDiscord |
<Jordach> webassembly lets you use UDP |
| 15:44 |
MTDiscord |
<Jordach> it silently wraps them as websockets |
| 15:45 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> "...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:50 |
|
Extex joined #minetest-dev |
| 15:51 |
MTDiscord |
<Warr1024> That'll work until the Unicode Consortium inevitably does their next insane thing ;-D |
| 15:51 |
|
Extex joined #minetest-dev |
| 15:55 |
MTDiscord |
<Sublayer plank> 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 |
<Warr1024> Ironically a non-insignificant slice of MT's target audience IS schools. |
| 15:56 |
MTDiscord |
<Sublayer plank> oh yeah, well in that case they would probably allow that |
| 15:57 |
MTDiscord |
<Warr1024> 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 |
<Sublayer plank> yeah that's true |
| 15:59 |
MTDiscord |
<Sublayer plank> 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 |
<Warr1024> If they are happy playing it that way I ain't gonna stop tem |
| 16:11 |
MTDiscord |
<Warr1024> 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 |
<Sublayer plank> yeah |
| 16:37 |
Calinou |
you can create a progressive web app to hide the navigation bar |
| 16:38 |
|
tech_exorcist joined #minetest-dev |
| 16:53 |
|
twoelk left #minetest-dev |
| 17:26 |
|
Fixer joined #minetest-dev |
| 17:29 |
|
Alias joined #minetest-dev |
| 18:00 |
|
longerstaff13 joined #minetest-dev |
| 18:33 |
|
Cybille joined #minetest-dev |
| 18:36 |
|
hecks joined #minetest-dev |
| 19:30 |
|
v-rob joined #minetest-dev |
| 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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:18 |
|
hecks joined #minetest-dev |
| 20:20 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> Best troll encoding would have to be UTF-1 |
| 20:27 |
MTDiscord |
<Sublayer plank> huh |
| 20:27 |
sfan5 |
btw irrUString includes surrogate handling for utf-16, this is why emojis already work |
| 20:27 |
MTDiscord |
<Sublayer plank> how would utf-1 work lol |
| 20:27 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<GreenXenith> 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 |
<GreenXenith> That should probably be double checked, but I believe his script is still python2 |
| 20:38 |
MTDiscord |
<GreenXenith> Which is why it just straight up doesnt run on 2.8 |
| 20:38 |
MTDiscord |
<Warr1024> 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 |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> 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 |
<GreenXenith> But you should at least note that mine is a maintained fork |
| 20:46 |
MTDiscord |
<GreenXenith> fair |
| 20:47 |
MTDiscord |
<GreenXenith> 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 |
<GreenXenith> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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:16 |
|
Extex joined #minetest-dev |
| 21:19 |
|
v-rob joined #minetest-dev |
| 21:20 |
rubenwardy |
Lua definitely should only be UTF-8 |
| 21:34 |
MTDiscord |
<Benrob0329> 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:26 |
|
Extex joined #minetest-dev |
| 23:27 |
MTDiscord |
<exe_virus> 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 |
<exe_virus> But we would have to support only the model data, none of this gtlf binary compiled stuff |
| 23:55 |
|
AliasAlreadyTake joined #minetest-dev |
| 23:56 |
pgimeno |
<Warr1024> It takes over 16 kilobytes to represent the poop emoji in UTF-1 <-- not according to https://en.wikipedia.org/wiki/UTF-1 |
