| Time |
Nick |
Message |
| 01:14 |
|
Jordach2 joined #minetest-dev |
| 02:59 |
|
specing_ joined #minetest-dev |
| 06:53 |
|
Extex joined #minetest-dev |
| 08:08 |
|
hecks joined #minetest-dev |
| 08:24 |
|
queria joined #minetest-dev |
| 09:00 |
|
calcul0n__ joined #minetest-dev |
| 09:20 |
|
Wuzzy joined #minetest-dev |
| 10:13 |
|
entuland joined #minetest-dev |
| 10:39 |
|
calcul0n_ joined #minetest-dev |
| 11:19 |
|
hecks joined #minetest-dev |
| 11:40 |
|
hecks joined #minetest-dev |
| 14:24 |
|
twoelk joined #minetest-dev |
| 14:27 |
|
olliy joined #minetest-dev |
| 14:36 |
|
twoelk joined #minetest-dev |
| 15:00 |
|
specing_ joined #minetest-dev |
| 15:30 |
|
hecks joined #minetest-dev |
| 15:57 |
|
Extex joined #minetest-dev |
| 16:12 |
hecks |
just shaved 1.5 MB off the irrlicht binary |
| 16:13 |
hecks |
stupid thing compiles in under a minute now |
| 16:17 |
hecks |
i stripped most file formats, particles (turns out we use our own), ancient pak readers, animators, terrain, octrees, stencil shadows, selectors, lights |
| 16:17 |
hecks |
note that animated meshes do not use "animators", those are an irrlicht misnomer for behavior code i think? but we don't use that |
| 16:19 |
sfan5 |
related: there was a pr to use irrlicht's particle system because it was deemed better #8461 |
| 16:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/8461 -- Reimplement particles using the Irrlicht particle system and improve collision handling by DTA7 |
| 16:21 |
hecks |
i'd rather just fix our own |
| 16:24 |
rubenwardy |
our own is fundamentally flawed |
| 16:24 |
rubenwardy |
but it can be rewritten with a lot of the same external interfaces |
| 16:24 |
hecks |
in what way, the fact that it uses scene nodes? |
| 16:25 |
rubenwardy |
it uses a scene node per particle - so a draw call per particle |
| 16:25 |
hecks |
yeah, but that's an implementation detail honestly |
| 16:25 |
hecks |
as far as api, visuals and behavor go, it doesn't look bad, it just runs like ass |
| 16:26 |
hecks |
i'll have this in mind as i proceed with this opengl mess |
| 16:27 |
hecks |
we can design a new particle renderer once we know what we can get away with |
| 17:09 |
|
longerstaff13 joined #minetest-dev |
| 17:12 |
nrz |
honestly, i'm for removing won't used parts of irrlicht, but also in favor to find a way to re-integrate some MT parts in the graphics engine |
| 17:18 |
twoelk |
no adding more other 3D file formats to minetest that irrlicht supports out of the box? |
| 17:19 |
hecks |
nothing can export all those ancient formats anyway |
| 17:19 |
hecks |
all they do is bloat |
| 17:20 |
twoelk |
collada is still somewhat widespread |
| 17:20 |
hecks |
gltf is the new collada, that's more worth supporting (but needs our own code) |
| 17:21 |
* twoelk |
checks gltf |
| 17:25 |
twoelk |
hm, sounds promissing |
| 17:26 |
sfan5 |
Irrlicht's collada code does not support animations |
| 17:26 |
sfan5 |
and with that it's no better than obj |
| 17:26 |
hecks |
:DD |
| 17:26 |
twoelk |
true |
| 17:26 |
sfan5 |
it went away when I dropped all XML stuff last week already |
| 17:27 |
hecks |
good riddance |
| 17:27 |
hecks |
an obj is smaller at least |
| 17:29 |
hecks |
from animated meshes we basically use b3d and x |
| 17:29 |
hecks |
nothing else has a living exporter anyway from what i know |
| 17:29 |
twoelk |
I'd just like it if we had a few more source tools that can create 3D content than having to pipe everything through Blender |
| 17:30 |
twoelk |
not that I dislike Blender but more variety would be better |
| 17:30 |
hecks |
blender is the best though |
| 17:32 |
twoelk |
well a ferari is good for some stuff but sometimes a bicycle is all I need to get a certain job done |
| 17:33 |
hecks |
blender is a scifi hoverbike though |
| 17:34 |
hecks |
you can write tools that spit out .x if you want, it's a text format |
| 17:35 |
MTDiscord |
<wwar> Wont people always choose ferari to bicycle? If both exist and selecting them is easy i mean |
| 17:35 |
twoelk |
depends on the size of your garage |
| 17:35 |
hecks |
are you having trouble running blender? |
| 17:36 |
MTDiscord |
<Kimapr> blender is heavy |
| 17:36 |
rubenwardy |
3d graphics is heavy |
| 17:39 |
twoelk |
I use blender at work for visuallisation sometimes, no way I can work on them files at home ... but that stuff is beyond what mt uses anyway |
| 17:40 |
hecks |
i literally could not do what i do without blender |
| 17:41 |
specing |
You can't take a ferari on mountain trails |
| 17:41 |
specing |
unless it's a ferari bicycle :P |
| 17:41 |
specing |
(ferrari?) |
| 17:41 |
* twoelk |
gazes at his old pen, ruler and other old drawing utensils |
| 17:42 |
hecks |
you can make obj files with a lot of tools, even a text editor |
| 17:42 |
hecks |
and for animated meshes i seriously wouldn't recommend anything other than blender in any context |
| 17:43 |
twoelk |
but thats more because importing animated meshes from elsewhere is a pita |
| 17:46 |
hecks |
no, because any other 3d animation program i know of is unusable buggy trash |
| 17:46 |
hecks |
and it's seriously hard to design and make a good one |
| 17:46 |
twoelk |
yep |
| 17:47 |
twoelk |
I thought sketchup had an interresting start but that sort of faded away |
| 17:48 |
twoelk |
sadly I often had to explore the limits of sketchup though |
| 17:50 |
twoelk |
It was good to carry around on a portable device and showcase not too complicated stuff at customers places |
| 17:58 |
twoelk |
so I guess the old file format list on the wiki may get somewhat shorter soon (https://wiki.minetest.net/Using_Blender) |
| 18:07 |
nrz |
sfan5, if we find a way to support animations on irrlicht we can massively improve server performance by just asking for animations instead of raw frames <3 |
| 18:08 |
hecks |
uhhhhh wait what |
| 18:08 |
hecks |
anyway the wiki page says we supposedly allow .md2 but is anybody using that? |
| 18:09 |
hecks |
vertex animation is interesting but vertex animated files tend to get really fat |
| 18:09 |
hecks |
also, good luck finding a working .md2 exporter these days |
| 18:10 |
hecks |
for images we likewise support stupid things like pcx, wal, rgb, psd |
| 18:10 |
hecks |
i don't think we need anything beyond png and jpeg (and bmp just because the null driver won't compile without it) |
| 18:11 |
hecks |
these two cover every other format's use case and they're actually suitable for network transfer |
| 18:11 |
twoelk |
had always wondered why wal was supported |
| 18:13 |
hecks |
because irrlicht supports it =] no other reason |
| 18:13 |
hecks |
i couldn't even find a working .wal exporter like 15 years ago |
| 18:20 |
sfan5 |
hecks: here's the whitelist we have https://github.com/minetest/minetest/blob/master/src/server.cpp#L2443 |
| 18:20 |
sfan5 |
we should drop at least wal, rgb and psd (isn't that photoshops' format?!) IMO |
| 18:21 |
hecks |
well i'd kill tga, pcx, ppm, psd, wal, rgb, md2 |
| 18:21 |
hecks |
rgb is an SGI format |
| 18:21 |
hecks |
ancient stuff |
| 18:21 |
hecks |
ppm is a text format and thus too fat |
| 18:21 |
hecks |
tga is redundant with png |
| 18:21 |
sfan5 |
ppm can be easily written from lua so I think it's kinda neat |
| 18:21 |
sfan5 |
nobody is forced to use it too |
| 18:21 |
hecks |
yeah i'm aware of that neatness but |
| 18:22 |
hecks |
i actually use this but |
| 18:22 |
hecks |
because the file size is atrocious, i still magick it to png |
| 18:22 |
twoelk |
aren't pcx and psd somewhat fallback formats? |
| 18:22 |
hecks |
as long as you do that in init (and you have to do it in init), there's no good reason to actually emit ppm as an asset |
| 18:22 |
hecks |
i'd much rather expose api to create png |
| 18:23 |
hecks |
or finally make that [raw pr |
| 18:23 |
sfan5 |
https://github.com/minetest/irrlicht/blob/master/source/Irrlicht/CImageLoaderPSD.cpp#L69 |
| 18:23 |
sfan5 |
https://stackoverflow.com/questions/20518335/why-do-photoshop-files-start-with-8bps |
| 18:23 |
sfan5 |
it's actually photoshop, I don't believe it |
| 18:23 |
twoelk |
is the irrlicht png support actually uptodate? |
| 18:23 |
hecks |
up to date in what way |
| 18:24 |
hecks |
for writing you mean? |
| 18:24 |
hecks |
cause as far as decoding goes, it seems to accept anything you throw at it |
| 18:24 |
twoelk |
hasn't png evolved somewhat? |
| 18:24 |
sfan5 |
no |
| 18:24 |
hecks |
the most advanced feature of png is the predictors and that works in irrlicht |
| 18:24 |
hecks |
beyond those, png is just a zipped bitmap =] |
| 18:25 |
sfan5 |
Irrlicht just uses libpng so no need to wonder about this |
| 18:25 |
hecks |
this is actually one more cause for dropping all those weird format |
| 18:25 |
hecks |
at least something like png uses a tried lib that everyone else is using, there's more eyes on this |
| 18:26 |
hecks |
who knows what lurks in irrlicht's ad hoc decoders for various formats |
| 18:26 |
twoelk |
might be mistaking it but didn't png do some interlacing as well? |
| 18:26 |
sfan5 |
it also supports interlacing yea |
| 18:26 |
hecks |
sure but we do not use that |
| 18:26 |
sfan5 |
but that won't make your file any smaller, on the opposite rather |
| 18:26 |
twoelk |
not faster? |
| 18:27 |
sfan5 |
no |
| 18:27 |
twoelk |
or rather previewish faster |
| 18:27 |
sfan5 |
png's interlacing is useful to render a lower resolution preview while the file is still downloading, no use for us |
| 18:27 |
hecks |
yeah you can preview faster but we do not stream textures that way |
| 18:27 |
hecks |
it's harder to compress an interlaced image so it will be bigger |
| 18:27 |
hecks |
cause it probably has to compress each mip separately |
| 18:29 |
twoelk |
not much gain on them max 32pix textures I use probably |
| 18:29 |
hecks |
there's no gain from interlacing in minetest at all |
| 18:37 |
twoelk |
.ppm might be usefull in educational scenarios |
| 18:39 |
hecks |
so would any image creation API we could make |
| 18:41 |
hecks |
anyway this is a list of the headers we actually use |
| 18:41 |
hecks |
https://paste.uguu.se/?e27793991cefe681#6v8LvWUrBBQs2iLFzxNseELNKTpy8pB7huW8SFDi1Zbp |
| 18:42 |
hecks |
kinda surprised that ILightSceneNode is being included, because we do not create those anywhere in code |
| 18:43 |
hecks |
also there is one evil inclusion of irrlicht.h somewhere in the code |
| 18:43 |
sfan5 |
terrible |
| 18:44 |
hecks |
guiscene.cpp includes lightscenenode but doesn't use it...? |
| 18:44 |
hecks |
let's try without |
| 18:45 |
hecks |
i mean i'm pretty sure it doesn't because i deleted that scene node type entirely already =] |
| 18:46 |
hecks |
the scenenodes we actually use are: mesh, empty, dummy, animated, text, billboard |
| 18:47 |
hecks |
src/client/renderingengine.cpp is where irrlicht.h is being included, also unused |
| 18:48 |
hecks |
so yeah, it compiles without light scene node, you can scratch that one |
| 18:52 |
MTDiscord |
<josiah_wi> I'd have fun helping out with this and learning, but I kind of want to get my current PR merged before starting another one. I also have an archaic PR to the image file extension code which I'm considering maybe reviving. I finished it but it isn't merged or closed either. |
| 18:53 |
hecks |
helping with what, ripping out code? =] no need |
| 18:54 |
MTDiscord |
<josiah_wi> I have fun working on improving code quality. |
| 18:55 |
twoelk |
is MaterialRenderer needed for the shaders? |
| 19:09 |
hecks |
sort of right now i guess but that is the exact part i intend to replace |
| 19:09 |
hecks |
that's what this entire effort is for really |
| 19:09 |
hecks |
239 code files left in source/Irrlicht :o |
| 19:11 |
hecks |
started at 465 |
| 19:11 |
hecks |
once i run out of things to delete i'll start merging the remaining GL drivers |
| 19:13 |
|
Fixer joined #minetest-dev |
| 19:26 |
hecks |
touchscreengui.cpp includes... ISceneCollisionManager.h ??? |
| 19:26 |
sfan5 |
indirectly via the gui? |
| 19:27 |
hecks |
directly |
| 19:27 |
sfan5 |
¯\_(ツ)_/¯ |
| 19:27 |
hecks |
does this get compiled if i'm on mingw? probably not |
| 19:27 |
hecks |
i'd like to remove the line and test it |
| 19:27 |
celeron55_ |
it obviously uses it to detect the collision of the finger to the display |
| 19:27 |
hecks |
:o |
| 19:27 |
sfan5 |
android only but you might be able to easily enable it |
| 19:27 |
hecks |
well here's the thing, the code doesn't actually use anything from that header... |
| 19:29 |
hecks |
wait |
| 19:29 |
hecks |
this file literally doesn't live in any cmakelists.txt |
| 19:30 |
celeron55_ |
you can test removing it in the PR, the android CI build will check if it's needed for some reason |
| 19:31 |
hecks |
i'll just read some existing CI logs |
| 19:32 |
celeron55_ |
touchscreengui.cpp is definitely compiled there |
| 19:32 |
celeron55_ |
but i meant whether ISceneCollisionManager.h is needed |
| 19:32 |
hecks |
i'm pretty sure the collision manager thing is a mistake |
| 19:32 |
hecks |
but uhhh, just for science |
| 19:33 |
hecks |
i wonder where the hell is this file mentioned besides clang-format-whitelist |
| 19:33 |
hecks |
well ok, since the header is included in places it can't be a ghost file |
| 19:34 |
sfan5 |
minetest/android/native/jni/Android.mk:$(wildcard ../../src/client/*.cpp) \ |
| 19:34 |
sfan5 |
minetest/android/native/jni/Android.mk:$(wildcard ../../src/client/*/*.cpp) \ |
| 19:34 |
sfan5 |
one of these |
| 19:35 |
hecks |
ah, .mk |
| 19:35 |
hecks |
let's see if it just compiles on desktop |
| 19:35 |
hecks |
i only want to know if it cares about the collision manager (probably not) |
| 19:39 |
hecks |
it compiled without the include ツ |
| 19:44 |
twoelk |
bye, have fun further dismembering irrlicht |
| 19:48 |
hecks |
clang passed, let's look at gradle |
| 19:49 |
hecks |
touchscreengui.cpp compiled without errors |
| 19:49 |
hecks |
we're probably clear |
| 20:00 |
hecks |
all good |
| 20:04 |
sfan5 |
plan to add more to that PR? |
| 20:05 |
hecks |
not really, i can make another if i find more |
| 20:05 |
hecks |
edited OP, you can review it if you want |
| 20:05 |
hecks |
#11475 |
| 20:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/11475 -- Remove unused header includes by hecktest |
| 20:06 |
hecks |
none of the other headers look very fishy |
| 20:07 |
sfan5 |
nothing to review there ;) |
| 20:07 |
hecks |
what if I snuck in a CR..... |
| 20:07 |
sfan5 |
github shows those? |
| 20:07 |
hecks |
i don't know =] |
| 20:07 |
hecks |
well ok, my text editor wouldn't do that to me |
| 20:08 |
hecks |
thank |
| 20:09 |
hecks |
so yeah, after trimming the fat we're basically left with some scene nodes, gui and rendering |
| 20:10 |
hecks |
i can kill the collision manager in peace now |
| 20:12 |
hecks |
after i patch CTextSceneNode to not use it because it's using it in a bizarre way |
| 20:12 |
sfan5 |
we use that? |
| 20:12 |
hecks |
apparently we use that for text |
| 20:13 |
hecks |
we do spawn text scene nodes, let me search that again |
| 20:13 |
sfan5 |
if it's in CGUITTFont.cpp that's unused to my knowledge |
| 20:13 |
hecks |
hmmmm yeah huh |
| 20:13 |
hecks |
declared but unused |
| 20:14 |
hecks |
ripping time |
| 20:15 |
hecks |
oh i guess it's because this is just some imported code |
| 20:15 |
sfan5 |
yep |
| 20:16 |
hecks |
"Altered source versions must be plainly marked as such" |
| 20:16 |
hecks |
how do we comply with this, just comment "this source file has been altered"? =] |
| 20:17 |
sfan5 |
I guess |
| 20:17 |
sfan5 |
it's already altered so technically we've been violating that for a while |
| 20:18 |
hecks |
I'll leave this to our nonexistent lawyers |
| 20:18 |
hecks |
so other than that, content_cao includes ITextSceneNode and does not use it.. haha |
| 20:22 |
hecks |
ok actually you know what, i don't have to delete this |
| 20:23 |
hecks |
the function actually uses mesh scene nodes, i've been bamboozled |
| 20:24 |
hecks |
#11476 merge ahead |
| 20:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/11476 -- Remove unused ITextSceneNode header by hecktest |
| 20:26 |
hecks |
that takes care of text nodes... and collision |
| 20:39 |
Krock |
you don't need to open PRs for that FYI |
| 20:47 |
hecks |
well that originally had a lot more in it but then i amended the commit to just delete the header |
| 20:47 |
hecks |
cause the other stuff was a red herring |
| 20:47 |
hecks |
273 files changed, 59 insertions(+), 90592 deletions(-) |
| 20:49 |
Krock |
okay yes, that would require a PR :`) |
| 20:49 |
hecks |
haha, well, not that |
| 20:49 |
hecks |
that's the upcoming irrmt pr... |
| 20:51 |
hecks |
i'm deleting stupid things from irrlicht and that means almost all of them |
| 20:53 |
specing |
lmao 90000 deletions |
| 20:55 |
celeron55_ |
postmodern programming |
| 20:56 |
celeron55_ |
instead of developing something from scratch, just take something that has an unimaginable amount of what you don't need, and remove it, leaving the final product |
| 20:56 |
celeron55_ |
creating value in the process |
| 20:56 |
specing |
Btw, have you thought about porting to Torque3D? |
| 20:57 |
specing |
And yes I know it'd be a fuckton of work |
| 20:58 |
celeron55_ |
the answer is probably no, and the question to you is why do you even ask |
| 20:58 |
specing |
Because a libre game dev said that all other libre engines suck :P |
| 21:01 |
Krock |
every engine dev said that about other engine |
| 21:01 |
Krock |
...s because they're developing a new one to supersede them all |
| 21:02 |
Krock |
a classic xkcd 927 situation |
| 21:12 |
|
Extex joined #minetest-dev |
| 21:14 |
specing |
Krock: nah, he evaluated them all |
| 21:15 |
specing |
The game: https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.holarse-linuxgaming.de%2Fsites%2Fdefault%2Ffiles%2F2017-07-21-6690%2Fscreenshot04.jpg&f=1&nofb=1 |
| 21:16 |
specing |
https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fmedia.moddb.com%2Fimages%2Fgames%2F1%2F37%2F36411%2Furban_ruins_preview_05.jpg&f=1&nofb=1 |
| 21:16 |
specing |
sadly I can't run it on my potato PC |
| 21:17 |
hecks |
3683 KB binary now |
| 21:17 |
hecks |
i'm sure you'll all miss features like "create cube scene node" and "make the cube scene node rotate wow!" |
| 21:18 |
celeron55_ |
there's probably a function for creating and displaying a quake map in one go |
| 21:18 |
hecks |
there is |
| 21:19 |
hecks |
BSP scene node |
| 21:19 |
hecks |
well... was |
| 21:20 |
hecks |
285 files changed, 20 insertions(+), 91917 deletions(-) |
| 21:21 |
specing |
:O |
| 21:21 |
hecks |
about 100k lines left |
| 21:22 |
hecks |
which is just about the limit of what one programmer can comprehend |
| 21:22 |
hecks |
it actually looks manageable now |
| 21:22 |
hecks |
roughly as big as MT itself |
| 21:22 |
hecks |
but i'm not done yet, there's a ton of redundancy in the gl drivers |
| 21:23 |
sfan5 |
I would prefer one PR for just deleting stuff at least |
| 21:23 |
hecks |
well this can be it, i'm not doing it in my shaders branch |
| 21:23 |
hecks |
sure, i'll merge GL drivers in another one |
| 21:23 |
|
olliy joined #minetest-dev |
| 21:24 |
hecks |
and you know what, ironically this might slightly improve our current particle performance |
| 21:24 |
hecks |
or at least CAO performance |
| 21:24 |
hecks |
i trimmed some unnecessary bookkeeping from scene nodes |
| 21:27 |
hecks |
we maintain our own b3d exporter that works with new blender right? |
| 21:28 |
sfan5 |
"""""maintain""""" |
| 21:28 |
hecks |
=] |
| 21:28 |
hecks |
i have an equivalent updated .x exporter, we could post that one too |
| 21:29 |
sfan5 |
sounds good |
| 21:31 |
hecks |
though it still has the broken transform issue and i have not fixed it there, i correct it elsewhere |
| 21:31 |
hecks |
it's good as long as someone doesn't try to use attachments |
| 21:32 |
|
olliy1or joined #minetest-dev |
| 21:52 |
hecks |
great, github's political correctness is actually incompatible with git :o |
| 21:52 |
hecks |
how do i delete "main" now |
| 21:52 |
hecks |
after pushing a master |
| 21:53 |
pgimeno |
"main"? |
| 21:53 |
hecks |
never mind i found it |
| 21:53 |
hecks |
new GH repos actually give you a "main" default branch instead of "master" |
| 21:53 |
pgimeno |
ok, three hours late but I have things to comment on... |
| 21:54 |
hecks |
if you forget it and push master from a fresh local repo, you get trouble |
| 21:54 |
MTDiscord |
<Jordach> > try to use attachments |
| 21:54 |
hecks |
i guess we have this now https://github.com/minetest/io_scene_x someone put it on the wiki or something |
| 21:54 |
MTDiscord |
<Jordach> i'm aware of the idiotic left-handed z and right handed z shenanigans inside Irr |
| 21:55 |
hecks |
=] |
| 21:55 |
pgimeno |
1. 3D formats - I know, new dependency and all, but wouldn't it be better to use assimp? |
| 21:55 |
hecks |
the only solution to this is to retransform the whole scene but i can't be bothered to actually fix this exporter now that i'm not even using it |
| 21:55 |
hecks |
too many formats |
| 21:55 |
pgimeno |
lol |
| 21:55 |
hecks |
it would be better to just support gltf |
| 21:55 |
pgimeno |
you have to remain compatible with existing worlds, you know |
| 21:56 |
MTDiscord |
<Jordach> that would mean using blender versions that interfere with workflow |
| 21:56 |
hecks |
reason 1, gltf has insane compression and is meant for network transfer |
| 21:56 |
hecks |
i mean, add gltf on top of x and b3d of course |
| 21:56 |
hecks |
reason 2, blender's gltf exporter is actually good, which is refreshing, those python exporters are usually trash |
| 21:57 |
hecks |
so you can export a fairly complicated scene in a few seconds, not minutes |
| 21:57 |
hecks |
and reason 3 is that it's actually relevant and not a dead format, blender will probably continue supporting it |
| 21:57 |
pgimeno |
when the new fashion in 3D file formats appears, assimp will probably be updated to support it; remember that in 20 years, gltf will be 20 years old |
| 21:58 |
hecks |
so if we added gltf on top of obj, x and b3d we'd be set |
| 21:58 |
hecks |
alternative: adopt my .lsd format which is use internally; it is very similar to gltf except it's lua based, not json |
| 21:58 |
hecks |
which i use internally* |
| 21:58 |
hecks |
it offers comparable export speed and i can give it quantized compression too if i felt like it |
| 22:00 |
pgimeno |
anyway, I thought I'd just mention the idea of using assimp |
| 22:00 |
pgimeno |
https://github.com/assimp/assimp/blob/master/doc/Fileformats.md |
| 22:00 |
hecks |
sure, i just think that an "import everything" kind of library tends to pull in too many formats |
| 22:00 |
hecks |
same reason i wouldn't like using devil for images |
| 22:02 |
pgimeno |
2. PPM supports a binary format, it's not all ASCII (but the headers always are) |
| 22:02 |
pgimeno |
it's not always* ASCII |
| 22:02 |
hecks |
still redundant with png |
| 22:02 |
hecks |
and i'm not sure if irrlicht's ppm importer is aware of the binary representation |
| 22:02 |
hecks |
please don't hoard |
| 22:03 |
hecks |
if nobody is using ppm then it's probably okay to delete it |
| 22:04 |
pgimeno |
is it possible to generate images from Lua and import them into the engine? |
| 22:04 |
hecks |
it is possible to generate images in init, but ppm does not compress and we do not compress assets in transit |
| 22:04 |
hecks |
so it is *strongly* recommended that you convert your generated images to png |
| 22:04 |
hecks |
this is how i generate a world map |
| 22:05 |
hecks |
https://a.uguu.se/1CIIJEmjYUew_map.png |
| 22:05 |
pgimeno |
in fact, 'man ppm' mentions the raw format as the canonical one, with header P6; the text format uses header P3 |
| 22:06 |
hecks |
what matters is what irrlicht does with it |
| 22:06 |
hecks |
once again, redundant with png |
| 22:06 |
pgimeno |
but can we do that from Lua currently? |
| 22:07 |
hecks |
do what exactly? |
| 22:07 |
pgimeno |
generate a PNG |
| 22:07 |
hecks |
i do it indirectly, i generate a ppm but then magick it to png |
| 22:07 |
hecks |
i'd rather just make some api that exposes png writing |
| 22:07 |
pgimeno |
yuck |
| 22:08 |
pgimeno |
by the way, I want to advocate for TGA. It offers a perfect mix of simplicity and versatility. |
| 22:08 |
hecks |
irrlicht does come with a png writer so it won't be hard |
| 22:08 |
hecks |
TGA compresses very poorly |
| 22:08 |
hecks |
RLE only |
| 22:08 |
hecks |
no palette support |
| 22:08 |
hecks |
redundant with PNG :p |
| 22:08 |
pgimeno |
what? |
| 22:08 |
pgimeno |
no palette support in Irrlicht? |
| 22:08 |
hecks |
no palette support in TGA |
| 22:08 |
pgimeno |
wrong |
| 22:09 |
hecks |
really, never heard of indexed TGAs |
| 22:09 |
pgimeno |
maybe you didn't, but I have written them routinely :) |
| 22:09 |
hecks |
at the very least no program has ever offered me this option |
| 22:09 |
pgimeno |
in gimp, if you save an indexed image, it's saved as an indexed TGA |
| 22:10 |
hecks |
interesting. but it still loses to png |
| 22:10 |
pgimeno |
TGA is basically uncompressed PNG |
| 22:10 |
hecks |
that's oversimplifying; it's true that png is a zipped bitmap but tga has its own lousy compression, RLE |
| 22:10 |
pgimeno |
I don't consider the TGA compression worth being called compression, I've always used raw TGAs |
| 22:11 |
pgimeno |
RLE is not mandatory, it can be disabled with a bit in the header |
| 22:11 |
hecks |
anyhow minetest sends textures over the network a lot and we'd probably do everyone a favor by disallowing formats that don't compress well |
| 22:11 |
pgimeno |
same for the bottom-up; you can also write TGAs in top-down order |
| 22:14 |
pgimeno |
and last point was about the licensing, yes we need to modify the headers. See for example what I did for this project: https://notabug.org/pgimeno/Gspot/src/master/Gspot.lua |
| 22:15 |
hecks |
i ended up not touching that text related file, it was a red herring |
| 22:23 |
hecks |
that's enough deleting for today, let me just run around some server to see if anything breaks |
| 22:33 |
|
Extex joined #minetest-dev |
| 22:34 |
|
Extex joined #minetest-dev |
| 22:54 |
hecks |
merging 11476 if anyone cares |
| 23:06 |
|
Alias2 joined #minetest-dev |
| 23:25 |
|
ssieb joined #minetest-dev |
| 23:29 |
|
hecks joined #minetest-dev |
| 23:51 |
|
ssieb joined #minetest-dev |
| 23:56 |
|
AliasAlreadyTake joined #minetest-dev |
